Tag: "security"
New Permissions in SQL Server 2014: IMPERSONATE ANY LOGIN, SELECT ALL USER SECURABLES, CONNECT ANY DATABASE and the old CONTROL SERVER
Apr 26th
(DE) |
(EN) |
Class Desc. |
Permission Name |
Type |
Parent Covering Permission Name |
DATABASE |
ALTER ANY DATABASE EVENT SESSION |
AADS |
ALTER ANY EVENT SESSION |
DATABASE |
KILL DATABASE CONNECTION |
KIDC |
ALTER ANY CONNECTION |
SERVER |
CONNECT ANY DATABASE |
CADB |
|
SERVER |
IMPERSONATE ANY LOGIN |
IAL |
|
SERVER |
SELECT ALL USER SECURABLES |
SUS |
Und wofür und wie können wir diese neuen Berechtigungen auf Server Ebene verwenden?
IMPERSONATE ANY LOGIN
Erinnert Ihr Euch an das Problem mit CONTROL SERVER? Das größte Problem war, das dieses Recht auch die Impersonifizierung eines jeden Kontos, inklusive der Privilegien Erweiterung zum sysadmin erlaubte. Die Details und auch andere Probleme mit CONTROL SERVER habe ich hier umfassend dokumentiert:
SQL Server 2014 gibt uns mit der Einführung der IMPERSONATE ANY LOGIN-Berechtigung Munition, dieses Problem anzugehen. - Diese Berechtigung erlaubt es, jeden Login und User zum impersonieren(!).
Wenn wir dieses mit einem DENY gegenüber dem Principal mit CONTROL SERVER Recht verwenden, verhindert es diesen, irgendeinen Login direkt zu impersonifizieren. (Warum sage ich “direkt”? – Das sehen wir ein Stück weiter unten.) |
So, what for and how can we use those permissions on Server level?
IMPERSONATE ANY LOGIN
Do you remember the problem with CONTROL SERVER?
Now in SQL Server 2014, by introducing the permission IMPERSONATE ANY LOGIN, gives us ammunition to tackle this problem. - This Permission permits to impersonate any Login and User(!).
If we DENY this to the Principal with CONTROL SERVER permission, it prevents him from impersonating any Login directly. (Why do I say “directly”? – We’ll see a bit further down.) So let’s see how to prevent a Login with CONTROL SERVER from elevating privileges by impersonating another login with help of the new permission: |
USE [master]
GO
CREATE LOGIN DBA_TheDude WITH PASSWORD=N'www', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
CREATE SERVER ROLE [Role_DBA]
ALTER SERVER ROLE [Role_DBA]
ADD MEMBER DBA_TheDude
GRANT CONTROL SERVER TO [Role_DBA]
GO
DENY IMPERSONATE ANY LOGIN TO [Role_DBA]
GO
CREATE DATABASE ControlServer_Schema_Demo
GO
-- ====================
-- === Test
EXECUTE AS LOGIN = 'DBA_TheDude'
-- Attempt impersonation:
EXECUTE AS LOGIN = 'sa';
-->
Msg 15406, Level 16, State 1, Line 9
Cannot execute as the server principal because the principal "sa" does not exist, this type of principal cannot be impersonated, or you do not have permission.
//
Die Ausführung als Serverprinzipal ist nicht möglich, weil der Prinzipal 'sa' nicht vorhanden ist, für diesen Typ von Prinzipal kein Identitätswechsel möglich ist, oder Sie nicht die erforderliche Berechtigung haben.
USE ControlServer_Schema_Demo
EXECUTE AS USER = 'dbo';
-->
Msg 15517, Level 16, State 1, Line 15
Cannot execute as the database principal because the principal "dbo" does not exist, this type of principal cannot be impersonated, or you do not have permission.
//
Die Ausführung als Datenbankprinzipal ist nicht möglich, weil der Prinzipal 'dbo' nicht vorhanden ist, für diesen Typ von Prinzipal kein Identitätswechsel möglich ist, oder Sie nicht die erforderliche Berechtigung haben.
Hurra!(?) Privilege-Escalation-Risiko: Wirklich? Immer noch? |
Hooray!(?) Privilege-Escalation-risc: Really? Still?
Still we are running under the context of DBA_TheDude: |
USE master;
CREATE LOGIN UtilizeMe WITH PASSWORD=N'www', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
GRANT CONTROL SERVER TO UtilizeMe
GO
Wir können den Login “UtilizeMe” nicht impersonifizieren, aber wir können und einfach mit seinem Passwort anmelden! - Nebenbei ein weiterer Grund, SQL Authentifizierung nicht zu verwenden, da er ansonsten die Credentials eines validen Windows-Login’s finden müsste – viel schwieriger, als einfach seinen eigenen Backdoor-account anzulegen. |
We cannot Impersonate the “UtilizeMe” Login, but we can just Log On using his password! - Another reason to not use SQL authentication by the way, as he would then need to find a valid Windows-Login’s Credentials – much harder to just creating his own backdoor-account.
|
Um also unseren Administrator wirklich daran zu hindern, seine Privilegien zum Sysadmin zu erweitern, müssen wir auch mit DENY ALTER ANY LOGIN und ALTER ANY SERVER ROLE arbeiten. |
So in order to further prevent our Administrator from elevating privileges to sysadmin, we also need to work with DENY ALTER ANY LOGIN and ALTER ANY SERVER ROLE. |
Und kann DANN CONTROL SERVER endlich sicher verwendet werden? NEIN!
Tatsächlich gibt es noch ein paar andere Dinge, die man tun kann, um die Berechtigungen von einem CONTROL SERVER-berechtigten Konto zu erweitern. Etwas trickreicher vielleicht, aber ein Angreifer mit einem guten Wissen über SQL Server (ich spreche also nicht von „Raketenwissenschaft“), wird in der Lage sein soetwas durchzuführen. Mir ist bewusst, dass das “Separation of Duties in SQL Server 2014”-Whitepaper (Enthalten im Microsoft® SQL Server® 2014 Product Guide) die Kombination von GRANT CONTROL SERVER + DENY IMPERSONATE ANY tatschlich als Best Practice listet, aber dennoch…
Also, empfehle ich die Verwendung in irgendeiner Weise? Leider ist es jedoch weit davon entfernt, perfekt zu sein, und in Sicherhit-belangen, alles, was nicht lupenrein ist, ist ein Risiko. Wer das also anstelle von sa/sysadmin verwendet, verdient dennoch Applaus, da es zeigt, dass man sich kümmert und es wagt, Berechtigungen einzuschränken. |
Can we THEN finally use CONTROL SERVER completely safely?
NO!
In fact there are a few other things one can do to elevate permissions from a CONTROL SERVER-permitted account. More tricky in a way, but an attacker with some good knowledge about SQL Server (note, I am not saying “rocket-scientist”) will be able to do that. I am aware that the “Separation of Duties in SQL Server 2014”-Whitepaper (Contained in the Microsoft® SQL Server® 2014 Product Guide) does in fact list the combination of GRANT CONTROL SERVER + DENY IMPERSONATE ANY LOGIN as a best practice, but yet…
So do I recommend using it in any way? That is a hard question for me personally, as I would like to see much less people using/granting sa/sysadmin for daily tasks, and this permission had the potential to make an end to it. Unfortunately it is far from perfect, and in security-terms, anything not flawless, is a risk. But in terms of getting people away from using the highest privileges from the very beginning, I do see it as a step, since many may just not have the time and skills to break out of it. I do recommend using it in combination with some solid Auditing and alerts in place. |
SELECT ALL USER SECURABLES
Was sicherer ist, ist die Verwendung für eine Art Auditor, der ALLE Daten lesen (aber nicht ändern) können soll – ohne den Aufwand, in sämtlichen Nutzerdatenbanken Benutzer und Rechte zu vergeben. |
SELECT ALL USER SECURABLES
What’s more safe, is the use for an Auditor that needs to read ALL data, but not change it - without the effort of creating users and permissions in all user databases. |
CONNECT ANY DATABASE
Diese Berechtigung kann gut für Logins verwendet werden, die sich im Wesentlichen mit jeder Datenbank verbinden können and zum Beispiel Code Reviews durchführen sollen – indem man diese mit der VIEW ANY DEFINITION Berechtigung kombiniert. |
CONNECT ANY DATABASE
This permission can be used quite well for having logins that can basically connect to any database and for example do code reviews - by combining it with the VIEW ANY DEFINITION permission. |
Happy “Server controlling”,
Andreas
DISABLE and DENY LOGIN, DENY USER & Effect on Impersonation and Permissions
Mar 7th
DISABLE und DENY LOGIN, DENY USER & Effekt auf Impersonierung und Berechtigungen
(de) |
(en) |
Immer mal wieder kann man beobachten, dass Logins oder Usern die Connect-Berechtigung verboten bekommen wurde, oder ein Login deaktiviert wurde. Die richtige Erwartung und Verständnis kann daher kritisch sein. Sehen wir uns also eine einfache Demo an: |
Every once in a while one can observe that Logins or Users have been denied the Connect permission or a Login has been disabled. Therefore a correct expectation and understanding can be critical. So let’s see a simple demo: |
Ich deaktiviere also das sa-Konto ebenso wie das „DeniedLogin“-Konto – letzterem verbiete ich außerdem die Connect-Berechtigung (Erinnern wir uns daran: „Berechtigungen können nicht für sa, dbo, Entitäts-Besitzer, information_schema, sys oder für den Benutzer selbst erteilt, verweigert oder aufgehoben werden.“) Der Datenbank-User „SQLUser“ bekommt die Connect-Berechtigung auf die Datenbank verboten. |
So I am disabling the sa-account as well as the “DeniedLogin”-Account – the latter I also Deny the Connect permission (Remember we “Cannot grant, deny, or revoke permissions to sa, dbo, entity owner, information_schema, sys, or yourself.”) The Database-User “SQLUser” gets denied the Connect permission on the database. In the GUI the result looks like this: |
Nun führen wir 4 Tests durch: |
Now let’s run 4 tests. |
Was diese Abfragen im Wesentlichen machen, ist, zu versuchen, den entsprechenden Login oder User zu impersonieren – und den Erfolg dadurch belegen, dass sie die dann jeweils aktiven Rollen-Mitgliedschaften zurückgeben. |
So essentially what those queries do, is trying to impersonate the respective Login or User – and proofing success by returning the then respective active role-memberships. Results: |
DeniedLogin: Impersonierung funktioniert + kein Verlust an Berechtigungen. |
DeniedLogin: Impersonation works + No loss of permissions. |
Dasselbe gilt für den sa: Impersonierung funktioniert + kein Verlust a Berechtigungen. Im Folgenden ein Test für den User, dem die Connect-Berechtigung auf die Datenbank entzogen worden ist – und nicht als Login verwendet werden kann. |
Same applies for sa: Impersonation works + No loss of permissions. In the following test for the User which has been denied the Connect-permission onto the database – and cannot be used as a Login. |
Ergebnisse: |
Results: Msg 15517, Level 16, State 1, Line 3 Cannot execute as the database principal because the principal "DeniedLogin" does not exist, this type of principal cannot be impersonated, or you do not have permission. Msg 916, Level 14, State 1, Line 3 The server principal "S-1-9-3-4049223906-1289824279-1154161590-488313048." is not able to access the database "ImpersonateLogin" under the current security context. |
Das Ergebnis ist für beide Datenbank-User effektiv das gleiche. Die GUID repräsentiert keinen reellen Server-Prinzipal, denn der User SQLUser hat keinen entsprechenden Login. Der Unterschied für den 2. User ist, dass dieser User nur innerhalb der Datenbank existiert, aber zugleich expliziert verboten wurde, sich mit ihr zu verbinden Das hat im Endeffekt dasselbe Resultat, wie ihn zu deaktivieren – genau wie der Guest-User es ist. |
The GUID does not represent a real server-principal, because the User SQLUser does not have a matching Login. The difference for the second user is, that this user only exists inside the database but at the same time has been explicitly denied to connect to it. This has essentially the same result as “disabling” it – just as the guest-user is. |
Damit wäre gezeigt, dass das Deaktivieren von Logins keinerlei Sicherheit gegenüber Angriffen von Innen gibt. Und sogenannte Privilegien Erweiterung findet in aller Regel z.B. von innen heraus statt. Auch der alte „Trick“, die Standard-Datenbank des Logins zu löschen, ist da keine Hilfe. Für Datenbank-User hat es durchaus Effekt und verhindert das Anmelden an der jeweiligen Datenbank – auch „von Innen heraus“.
|
Thereby it is shown, that disabling of Logins does not give any security against attacks from inside. And so-called privilege elevation (/-escalation) usually takes part from internal. Also the old “trick”, to drop the default-database of a Login, is of little help. For database-users is indeed does have an effect and prevents logon/connect to the respective database – also “from inside”. |
Konsequenterweise bleiben alle Berechtigungen (natürlich abgesehen von dem jeweiligen Deny) der jeweiligen Logins und User absolut unbeeinflusst von einer Deaktivierung jeglicher Weise. Das gilt auch im Zusammenhang mit „External Access“-Berechtigung für Logins basierend auf asymmetrischen Schlüsseln. ALTER LOGIN ist auch hier in BOL erklärt: technet.microsoft.com/en-us/library/ms189828.aspx
Ich hoffe, diese Dinge erklären einiges und speziell Empfehlungen in Sicherheits-Aspekten. |
Consequentially all permissions (besides the one denied of course) of the respective Login and User stay totally unaffected by and method of deactivation. This is also true in the context of “external access”-permission for Logins based on asymmetric keys. ALTER LOGIN is also explained in BOL here: technet.microsoft.com/en-us/library/ms189828.aspx
I hope those things clarified some things and especially recommendations in security-matters |
Happy securing
Andreas
SQL Server Row- and Cell-Level Security – Disclosure vulnerability // Schwachstellen in Zeilen-basierter Sicherheit
Jan 16th
(de) |
(en) |
Im Folgenden werden wir ein recht verbreitetes Szenario sehen, wie Sicherheit auf Zeilenebene / Row-Level Security (und auch Zellenebene/Cell-Level Security) implementiert werden kann. Die Architektur ist recht einfach: |
In the following we will see a quite common scenario of how Row-Level Security (and also Cell-Level Security) can be implemented. The architecture is quite simple: Of course there are also more complex designs with intermediate tables and multi-role-memberships/permissions, but it all comes down sharing the same vulnerability which I am about to demonstrate. First of all here's a diagram of the high-level architecture: |
Sehen wir uns das ganze also an. |
So let’s see it in action. |
Die Spalte „Role“ wird von der Sicht verwendet, um die jeweilige Zeile, unter Verwendung der IS_MEMBER()-Funktion nur Mitgliedern der jeweils hinterlegten Datenbankrolle durchzureichen. |
The column “Role” is used by the view to return the respective row by using the IS_MEMBER()-function only to members of the respectively stored database-role. |
Benutzer, Rollen und Berechtigungen: |
User(s), Roles and Permissions: |
Erinnern wir uns, was die Tabelle enthält: |
Now, remember what our table contains: |
In einer heilen Welt, vor dem Sündenfall, wäre dies ausreichend. |
So in an innocent world, before the fall of mankind, this would be sufficient. |
- Natürlich wird die Funktion User_Name() nur für Demo-Zwecke eingesetzt. |
- Of course the function User_Name() is only used for demo-purposes. |
Angriff |
Attack |
Und das Ergebnis ist: |
And the result is: |
Nicht „schön“, aber wir haben, was wir wollten: die „geschützten“ Daten. Der bereits geschulte Leser erkennt diese Form des Angriffs vielleicht aus einem anderen Bereich wieder: SQL Injection. |
Not exactly “pretty”, but we got what we want: the “protected” data. The well-educated reader may remember this kind of attack from a different area as well: SQL Injection. |
Einigen kommt das Bild vielleicht schon bekannt vor :-) Stellt sicher, dass das nicht Euer "Vorgarten" ist! Wo wir davon reden: |
To some, this picture may already look familiar :-) Make sure it’s not your "front-yard"! Speaking of which: |
Schutzmaßnahmen Was kann man gegen solche Angriffe tun? 1) Einsatz von gespeicherten Prozeduren, die alle Fehler abfangen, oder, wenn man unbedingt mit Sichten Arbeiten möchte, der Einsatz einer dazwischengeschalteten Multi-Statement-Tabellenwertfunktion 2) Datenverschlüsselung (Nicht TDE!) 3) Ähnlich wie 1, Aufbau einer Mittelschicht in der Anwendung, die derartiges unterbindet. Und schlussendlich sollte man für kritische Daten auch über eine Überwachungslösung nachdenken. |
Security-measures What can prevent such forms of attack? 1) The use of stored procedures which catch all errors, or, if one really wants to use views for some reason, using of a multi-statement table valued function which will be put between. 2) Data encryption (Not TDE!) 3) Similar to 1, implementation of a mid-tier in the application which prohibits such actions. Finally one should also think about an Auditing solution for critical data. |
Die hier gezeigte Technik der Row-Level Disclosure ist nicht wirklich etwas Neues, wird aber gerne immer mal vergessen. |
The technique of Row-Level Disclosure shown above isn’t really new, but frequently forgotten about. |
Implementing Row- and Cell-Level Security in Classified Databases Using SQL Server 2005
Happy securing,
Andreas
Wer sich ermuntert fühlt, nun einmal richtig in das Thema „Sicherheit mit SQL Server“ einzusteigen, für den habe ich auch 3 erstklassige Trainings im Angebot: |
If you now feel encouraged to really dive into the subject of “Security with SQL Server”, I do have 3 first-class Trainings on offer: |
Für Beginner, die hier einen guten Überblick erhalten und Grundlegende Kenntnisse erlernen: |
For Starters, who gain a good overview and learn essential knowledge in the basics: |
(SES) SQL Server Security Essentials for Developers & Administrators (1 day) |
|
Für Administratoren, die fortgeschrittene Sicherheitskonzepte umsetzen müssen: |
For Administrators that have to implement advanced security concepts: |
(SIA) Securityworkshop for SQL Server Administrators (advanced) (1 day) |
|
Für Entwickler, die fortgeschrittene Sicherheitskonzepte umsetzen müssen: |
For Developers that have to implement advanced security concepts: |
(SID) Securitysworkshop for SQL Server Developers (advanced) (1 day) |
Security-Check-Script & Survey: SQL Server Security - Database-Owners, critical Permissions and role membership / Sicherheitsprüfungs-Script & Umfrage: SQL Server Datenbankbesitzer, kritische Rechte und Rollenmitgliedschaft
Dec 27th
(de) Dabei interessieren vor allem bestimmte serverweite Berechtigungen nicht nur des verwendeten Logins selber, sondern auch, falls er Mitglied einer (custom) Server Role ist, bestimmte, kritische Rechte dieser Rolle. Wer meine Vorträge zum Thema „Sicherheit in SQL Server“ in den letzten Jahren, und insbesondere der im Sommer 2013 gestarteten Reihe „SQL Server Attacked“ verfolgt hat, wird sich vielleicht hat erinnern, wie ich dort auch gezeigt habe, wie man aus einer Datenbank ausbrechen und volle Systemrechte erlangen kann („Privilegien Erweiterung“) – basierend auf einer Kombination von Datenbankbesitzer, -Konfiguration und Impersonierung. Hier stelle ich nun einen T-SQL Script zur Verfügung, welcher
Und hier ist der Script: |
(en) In this instance, particular server-wide permissions both of the used account as well as, in case of membership of a (custom) Server Role, critical permissions of that role, are of interest. Those who have followed my presentations on the topic “Security in SQL Server” in the last years, and especially the „SQL Server Attacked“ series launched in the summer of 2013, may remember how I had also demonstrated there how to break out of a database and be granted full system rights (“Elevation of privileges”), - based on a combination of database owner, configuration and impersonation. Here, I am providing a T-SQL Script which
Here you can find the script: |
Server 1: http://j.mp/13_SQL_DBO_Survey
Server 2: gallery.technet.microsoft.com/scriptcenter/Database-Owners-role-3af181f5/
- Er sollte auf allen SQL Servern ab der Version 2005 funktionieren (getestet 2008-2014). Zum Zwecke der Umfrage bitte ich Euch, die anonymisierten Ergebnisse (am Besten in Excel-Format) an die Email survey@SarpedonQualityLab.com zu senden, oder auch hier in den Kommentaren zu posten. Hier seht ihr ein Beispiel-Ergebnis: |
- It should be working on all SQL Servers since the 2005 version (tested: 2008-2014). For the purpose of the survey, I would like to ask you to send the anonymized results (preferably in excel-format) to the email survey@SarpedonQualityLab.com, or as well post them here in the comments. For anonymization purposes, you can simply leave out the last three columns from the result set – these are not of use to a data collection and only meant for your internal usage :-). Here, you can see a sample result: |
-> click to enlarge
Mehrere Einträge für dieselbe Datenbank entstehen, wenn der Datenbankbesitzer – oder seine Serverrolle(!) über mehrere, der von mir als sicherheitskritisch klassifizierten Rechte verfügt. Diese stehen dann in der Spalte login_permission bzw. role_permission. Hinter den Kürzeln verbergen sich: Die Inhalte der Spalten DatabaseNo, database_owner und external_owner sind absichtlich allgemein gehalten – die exakten Namen sind wie gesagt in den letzten 3 Spalten zu finden. Die Spalte db_owner_valid zeigt an, ob die Datenbank einen gültigen Besitzer hat. In diesem Fall besteht ein match zwischen dem „externen Besitzer“ und dem in der Datenbank selber hinterlegten. In der Spalte external_owner steht nur ob dieser „externe Besitzer“ sa ist oder nicht – der genaue Login steht dann in *External_Owner.Der Script speichert keine Daten dauerhaft im System ab und beseitigt seine temporären Zwischenergebnisse selbst. Ich hoffe, ihr findet die Auswertung hilfreich – und ich hoffe, ihr könnt die (anonymisierten) Ergebnisse mit der Community teilen. Ich werde keine Email speichern oder verwenden, sondern nur die anonymisierten Abfrageergebnisse. Ich bedanke mich für eure Teilnahme und Unterstützung der Community! |
Multiple entries for the same database occur when the database owner – or his serverrole(!) possess multiple of the permissions which I classified as security-wise critical. These are listed in the column login_permission respectively role_permission. The codes stand for: The contents of the columns DatabaseNo, database_owner and external_owner are left general on purpose – the exact names can be found in the last 3 columns s mentioned above. The column db_owner_valid indicates, whether the database has a valid owner. In this case there is a match between the „external owner“ and the one stored within the database itself. The column external_owner only shows whether that „external owner“ is sa or not –the exact Login is shown in *External_Owner. The script does not permanently save any data in the system and removes its temporary intermediary results by itself. I hope you find the report useful and I hope you can share the (anonymized) results with the community. Thank you in advance for your participation and support of the community! |
Andreas
Where are the scripts to the session „SQL Attacked/Hacking SQL Server“ ? ;-)
Nov 27th
Wo sind die Scripte zu dem Vortrag „SQL Attacked/Hacking SQL Server“ ? ;-)
(de) |
(en) |
Der Hintergrund, das ich die dafür entwickelten Scripts nicht veröffentliche, ist eigentlich recht einfach: ich zeige darin unter anderem Angriffsvarianten und Techniken, die so noch nicht dokumentiert oder in der „Szene“ bekannt sind(?). Und da ich die frei verfügbaren SQL-Injection- und allgemein „Hacking“/DoS -Tools ein wenig kenne, möchte ich vermeiden, denjenigen, die diese entwickeln, neue Ideen zu geben um Server in die Knie zu zwingen. Das bringt keinem (aus der SQL Server Community) etwas (- höchstens "Auftragshackern", aber "leider" habe ich da keine Aktien drinnen ;-) ). - Die meisten SQL-Injection-Varianten sind übrigens auch wirklich gut im Netz dokumentiert, und eine einfache Suche wird eine Vielfalt an Code-Beispielen zutage bringen. Es macht kaum einen Unterschied, welche Vorlage man verwendet, man muss so und so noch Anpassungen vornehmen. ;-) Im Gegensatz zu landläufiger Meinung, glaube ich nicht daran, dass jeder alle „Hacking“-Techniken selber durchführen können muss. Ich denke das ist häufig ein Vorwand, sicherheitsbedenkliche Aktionen pauschal zu rechtfertigen. Ich bin der Ansicht, dass es genügt, zu wissen/gesehen zu haben, wo man angreifbar sein kann, und das es wichtiger ist, die Zeit darauf zu verwenden, die Skills für die Sicherung zu entwickeln. Um selber zu „Hacken“, ist das übrigens eine gute Voraussetzung (und der Unterschied zum sogenannten „Script-Kiddie“). Nur das man dann einfach noch mehr Kenntnisse benötigt. In aller Regel sehe ich jedoch eher einen Mangel an Kenntnissen über die Zusammenhänge in der Sicherheitsarchitektur von SQL Server, auf den ich mich naturgemäß fokussiere, sowie natürlich dem darunterliegenden Windows-Server und der Domain-Architektur allgemein. |
The background to why I don’t make public the scripts developed for this purpose is actually quite simple: in the scripts, I am showing attack variants and techniques, among others, which have not been documented or are not known within the “scene” (?). And since I am a little familiar with the discretionary SQL injection and “Hacking”/DoS tools in general I would like to avoid giving those parties developing these tools new ideas for bringing servers down. This wouldn’t be of use to anyone (from the SQL Server community) (- except maybe to “contract hackers,” but I’m “afraid” I don’t hold any stocks in there ;-)). - By the way, most of the SQL injection variants are very well documented in the internet, and a simple search will spill out a variety of code examples. It will hardly make a difference which template one is using, as one will need to make adaptions anyway. ;-) In contrast to general opinion, I do not believe that everyone needs to be able to carry out all “hacking” techniques by themselves. I think this is often used as a blanket pretext for justifying security-wise questionable actions. I am of the opinion that it is sufficient to know/have seen where one can be vulnerable, and that it is more important to invest the time into developing skills for protection. And this is a good prerequisite for “hacking” oneself (and the difference to the so-called “script kiddie”). Only that even more knowledge will be required then. In principle, however, I am rather observing a lack of knowledge of the correlations in the security architecture of SQL Server on which I am by nature focusing, as well as, of course, the Windows Server beneath it and the domain architecture in general. To be able to “hack” alone is of no avail. Once one has covered everything known, one can still get to that. If this is necessary, one will end up in the grey area of “penetration testing.” |
Das eigentliche Ziel meiner Vorträge/“Shows“(?) ist die "Awareness/Wahrnehmung", und Verbesserung der Sensibilität für das Thema Sicherheit im Sinne von: „Habe ich das alles schon einmal bedacht?“ „Könnte ich doch noch Lücken haben und ein leichtes Angriffsziel sein, ohne es bislang gemerkt zu haben?“ Nicht: "Um meine SQL Server Umgebung sicherer zu machen, möchte ich mich selber im „Hacken“ versuchen." Ich hoffe das macht Sinn für Euch :-) In jedem Fall ist eine offene Diskussion zu diesem Thema durchaus in meinem Sinne. |
The actual goal of my lectures/ “shows” (?) is the “awareness/perception,” and the enhancement of sensitivity for the topic of security in the sense of: “Have I taken all this into consideration?” “Could I still have gaps and be an easy target without having noticed up to now?” Not: “In order to make my SQL Server environment more secure I would like to dabble in ‘hacking.’” I hope this makes sense to you J Either way, an open discussion on this topic is absolutely along my lines. |
Happy securing
Andreas
PS: Aus diesem Grunde biete ich ja schon seit einigen Jahren immer wieder den Security Essential für die PASS Deutschland an – aber wie wir wissen, zieht das Thema „Sichern“ einfach weniger als „Hacken“ ;-) Und für diejenigen, die die Grundlagen schon beherrschen, aber komplexere Anforderungen oder kritischere Umgebungen haben, kommen dann die Master-Classes zum Thema Sicherheit: www.sarpedonqualitylab.com/SQL_Master-Classes.htm |
PS: For those who already know the basics, but have more complex requirements or critical environments, there are the Master-Classes on Security: en.sarpedonqualitylab.com/SQL_Master-Classes.htm |