SQL Server & BI Blog by Andreas Wolter

(de)
Es ist Zeit für einen weiteren Artikel zum Thema Sicherheit.
Und durch einen Forum Thread zu „Datengesteuerter Sicherheit“ mittels der IS_MEMBER(), USER_NAME(), SUSER_SNAME() – Funktionen kam ich auf die Idee, ein kurzes Beispiel zu zeigen, wie sich solche Konstrukte leicht umgehen lassen und die geschützten/verborgenen Daten offengelegt werden können, wenn sie nicht mit weiteren Mitteln gesichert werden.
Sehen wir uns ein Beispiel an.

(en)
It’s time for another post on security matters.
And through a forum-thread on data-driven security by the means of views using the IS_MEMBER(), USER_NAME(), SUSER_SNAME() – functions, I came up with the idea of giving a short example how such constructs can easily be circumvented and the protected/hidden data become disclosed, when not being secured by further means.
So let’s look at an example.

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:
Eine Tabelle enthält Datenzeilen, von welchen einige von einer bestimmten Gruppe Personen gelesen werden darf, und andere Zeilen von anderen Personen – jeweils exklusiv.
Um das zu erreichen, wird eine Sicht angelegt. Diese Sicht muss natürlich denselben Besitzer haben, so dass der Prinzipal Berechtigungen auf die Sicht alleine erhalten kann, und durch die Besitzerkette an die Daten gelangt.
Innerhalb der Sicht ist eine Where-Klause, die einen Filter auf ein bestimmtes Attribut in der Tabelle enthält, durch das der Benutzer der aktuellen Sitzung erkannt wird und ausschließlich die Daten zurückgeliefert werden, die seiner Rollen-Mitgliedschaft entsprechen.
Natürlich gibt es auch komplexere Designs mit Zwischentabellen und mehrfachen Rollenmitgliedschaften/Rechten, aber am Ende teilen alle dieselbe Schwachstelle, die ich demonstrieren werde.
Im Folgenden zunächst ein Diagramm der Architektur.

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:
A table is holding rows of data, some of which are supposed to be readable by a certain group of people, and other rows by other people – in each case exclusively.
In order to achieve this, a view is created. This view naturally must have the same owner, so the principal can be granted permissions on nothing but the view and get to the data by means of the ownership-chain.
Within the view there is a Where-clause which contains a filter on a certain attribute in the table, by which the user of the current session is detected and returned solely the data which matches his role-membership.

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.
Die Einrichtung Tabelle und der Sicht, inklusive 2er Beispieldatensätze:

So let’s see it in action.
The Setup of the Table and the View including 2 sample data rows:

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.
(Nachdem wir uns als „Andreas“, der Mitglied der Datenbankrolle RoleAlpha ist, einloggen) würden unsere Abfragen wie folgt aussehen, und lediglich die Zeilen zurückliefern, die der RoleAlpha „gehören“:

So in an innocent world, before the fall of mankind, this would be sufficient.
(After logging in as “Andreas”, who is member of the RoleAlpha database-role) our queries would look like this and only return the rows which “belong” to RoleAlpha:

- Natürlich wird die Funktion User_Name() nur für Demo-Zwecke eingesetzt.
Ergebnis:

- Of course the function User_Name() is only used for demo-purposes.
Result:

Angriff
Aber Andreas spielt nicht fair. Er ist neugierig, was sonst noch in der Tabelle stehen könnte.
Also schreibt er eine Abfrage wie diese:

Attack
But, Andreas does not play nice.  He is curious on what else might be in the table.
So he crafts a query like this:

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.
Es ist eine Form des alten Freundes „Error Based Attack“ oder „Error Disclosure“, die auch bei schlecht geschriebenen Webanwendungen zum Zuge kommt. Das habe ich u.a. 2013 auf diversen Konferenzen gezeigt (Vortragsreihe).
Der Kontext ist ein wenig anders, aber die Idee dahinter ist dieselbe.

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.
It’s a form of the old fried “error based attack” or “error-disclosure”, which can also be used for badly written web-applications. I have also shown that amongst others in 2013 at several conferences (series of sessions).
The context is a little bit different, but the idea is the same.

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?
Im Wesentlichen stehen einem 3 bekannte Möglichkeiten zur Verfügung:

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?
Essentially there are 3 well-known methods at hand:

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.
Nachlesen kann man darüber zum Beispiel auch in diesem (alten, aber immer noch zutreffenden) Whitepaper:

The technique of Row-Level Disclosure shown above isn’t really new, but frequently forgotten about.
One can read about this, for example, in this (old, but still applicable) whitepaper:

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)
3. April 2014 in Düsseldorf

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)
4. April 2014 in Düsseldorf

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)
24. April 2014 in Düsseldorf

(de)
Ok, dieses Jahr wird das bei Weitem aktivste in Sachen Sprecher auf internationalen Konferenzen sein:
Nach 6 Konferenzen letztes Jahr, inklusive SQL Rally Nordic, die mir sehr gefallen hat, musste ich mich entscheiden zwischen noch einmal SQL Rally Nordic, SQL Rally Amsterdam oder gar beiden.
ich habe mich für die SQL Rally Amsterdam entschieden, da diese neu ist, und weil ich dem holländischen Chapter Leader versprochen habe, eine Session einzureichen. Daher dieses Jahr keine SQL Rally Nordic.

-           Da ich dieses Jahr auf bereits 7 Konferenzen gesprochen habe, inklusive 1,5 Tagen PreCon (www.andreas-wolter.com/sql-conferences/sql-conferences-2013.htm ) + 3 noch aufkommende Konferenzen (PASS Summit Charlotte USA, TechNet Berlin Germany, PASS Camp Darmstadt Germany), sind 11 Konferenzen 2013 wirklich eine Menge. Auch wenn man bedenkt, dass meine Kunden doch hin und wieder ganz froh sind, wenn ich Zeit für sie habe :-).

(en)
Alright, this is going to be the by far most active year in terms of speaking at international conferences:
After 6 conferences last year, including SQL Rally Nordic, which I really liked a lot, I had to decide between SQL Rally Nordic again or SQL Rally Amsterdam or even both.
I decided for SQL Rally Amsterdam, because it is new, and because I promised the Dutch Chapter leader, to hand in a session. So this year no SQL Rally Nordic.

-           Having spoken at already 7 conference this year, including 1.5 days of PreCon (www.andreas-wolter.com/sql-conferences/sql-conferences-2013.htm ) + 3 more coming up (PASS Summit Charlotte USA, TechNet Berlin Germany, PASS Camp Darmstadt Germany), 11 conferences in 2013 really is a lot. Also considering once in a while my customers are actually happy if I have time for them :-).

SQL Rally Amsterdam bietet eine Auswahl von 5 (!) hochwertigen PreCons am 6. Nov. und 3 parallelen Vortrags-Tracks am 7.-8. Nov. an: BI Platform Architecture, Development and Administration, Enterprise Database Administration and Deployment, Database and Application Development mit vielen bekannten internationalen Sprechern, MCMs und MVPs.

Ich selber werde “SQL Attack(ed)” – SQL Server Under Attack präsentieren. Ein demo-geladener Sicherheits-Vortrag mit 2 neu-entwickelten Privilegienerweiterung und DoS-Attack Techniken, ausgeführt via SQL-Injection, in den Hauptrollen, die ich persönlich diesen Sommer in Vorbereitung auf den SQLSaturday Germany/Rheinland entwickelt habe und auch schon auf dem SQLSaturday in Istanbul gezeigt habe.

Wer also einige Gründe, Sicherheits-Maßnahmen ernst zu nehmen, live und in Aktion sehen möchte: schaut vorbei!

SQL Rally Amsterdam offers a choice of 5 (!) real high quality PreCons on Nov. 6th and 3 parallel session tracks on Nov. 7th-8th.: BI Platform Architecture, Development and Administration, Enterprise Database Administration and Deployment, Database and Application Development with many well-known international speakers, MCMs and MVPs.

I will be presenting “SQL Attack(ed)” – SQL Server Under Attack. A demo-loaded security session featuring 2 newly developed privilege elevation and DoS-attack techniques, executed via SQL-Injection, that I personally developed this summer in preparation of SQLSaturday Germany/Rheinland and also shown at SQLSaturday in Istanbul.

So if you want to see some reasons for taking security measures like permissions serious, live and in action, check it out!

(DE)

Auf dem diesjährigen SQLSaturday in Deutschland habe ich wieder einmal einen meiner Sicherheitsvorträge gehalten, in denen ich mich auf „Angriff“ konzentriere. Für mich eine gute Gelegenheit, mich wieder einmal intensiv mit SQL Server Sicherheit und einigen Penetrationstest-Tools auseinanderzusetzen, und SQL Server auf Fallstricke in Sachen Sicherheitskonfiguration zu untersuchen. Am Ende hatte ich eine lange Liste an möglichen Demonstrationen, worunter auch eine von mir frisch entwickelte DoS-Attacke via SQL Injection zählt (zumindest habe ich nirgends einen Hinweis auf eine Beschreibung dieser Art Angriff gefunden oder auf meine Nachfragen erhalten), sowie eine „privilege elevation“(Privilegienerweiterung)-Attacke, die in dieser Form auch noch unbekannt zu sein scheint. – Alles jedoch unter Ausnutzung von angepassten Einstellungen, und keine Schwächen in der Engine(!).

Da es speziell zu SQL Server kaum nennenswerte Sessions in Deutschland zu diesem Thema gibt (selbst auf den Summits in den USA war ich damit meist recht allein unterwegs), und mir das Thema in dieser Tiefe natürlich auch besonders Spaß macht, habe ich mich entschieden, hier meine möglichen Themen zu sammeln. Ich werde sie nicht nur auf weiteren kommenden Konferenzen in Europa oder USA präsentieren, sondern auch den Regionalgruppen der deutschen PASS anzubieten – die sich hier sozusagen im „Menü“ bedienen können :-)

An einem Abend schafft man vermutlich maximal ein Drittel der möglichen Themen. – Und damit wälze ich nun die Qual der Wahl auf die Kollegen RGVs ab ;-)

(EN)

At this year’s SQLSaturday in Germany I have shown one of my sessions again, in which I concentrate on “attack”. For me a great opportunity to dive deep into SQL Server Security and several penetration-test-tool, and to explore SQL Server for pitfalls and security configuration. At the end I had a long list of possible demonstrations. Among them a just recently developed DoS-attack via SQL Injection (at least I did not find any clue on a description for this kind of attack anywhere or got an answer on my inquiries), as well as a “privilege elevation”, which in this form seems to be quite unknown as well. – Everything is just done by exploiting customized settings and not by weaknesses in the engine (!).

Since there are barely any nameable sessions on this topic specifically for SQL Server in Germany (even at the Summits in the US I tended to be quite alone with my sessions on security), and I enjoy this topic in this a lot, I have decided to collect all possible topics here.
I will not only present them on upcoming conferences in Europe or the US, but also I am offering these to the regional chapter leaders in Germany  – “serve yourself” - style :-)

Session Beschreibung:

SQL Server kann als "secure by default" gelten, aber da das am häufigsten erfolgreich angegriffene Ziel die Daten, die in der Datenbank liegen, sind, möchte ich in dieser Session für das Thema sensibilisieren.
Die meisten der ausgenutzten Schwachstellen in einer SQL Server Umgebung sind auf Miss-konfiguration, schwache Sicherheitseinstellungen oder ungenügende Programmierpraktiken zurückzuführen.

In dieser rein Demo-basierten Session werden verschiedene Angriffsszenarien auf verschiedenen Ebenen gezeigt. Auf speziellen Wunsch auch einige Advanced SQL-Injection Beispiele. Des Weiteren zeige ich, wie eine „privilege elevation“ aufgrund einer nicht unüblichen Einstellung möglich ist und die Ausnutzung von Rechten mit einem Datenbank-Rootkit durch einen "Insider".

In dieser Art Vortrag gebe ich natürlich keine Anleitung "wie man hackt", sondern ich beleuchte häufige Schwachstellen - "Was kann unter welchen Umständen passieren".

Session Description:

SQL Server is considered "secure by default", but one of the most often successfully attacked targets is the data that resides in a Database Server.
Most of the exploited weaknesses in a SQL Server environment are due to misconfiguration weak security settings or inadequate coding practices.

In this purely demo-based security session, I am showing several attack scenarios on different layers. Due to special request this includes some special SQL Injection types. Furthermore I show how an evaluation of privileges attack is possible due to a not uncommon configuration as well as an “insider-exploit” with a database root kit.

Note that in this kind of session I do not give instructions on “how to hack” but rather I am highlighting common weaknesses - “what can happen and under which circumstances”.

(Web)Application Layer

• Mein Formular und die WAF lassen nichts durch – oder doch?
  • Standard SQL Injection
  • Blind / Error-based /Time-based SQL Injection, Encoding Injection
  • 2nd Order SQL Injection
  • Privilege Escalation über SQL Injection und trustworthy
  • Automatisierte Attacken mit Tools, weitere „Features“ (sqlmap,...)
  • “Der Fall der nicht-terminierbaren Transaktion“ -  DoS Attack über SQL Injection (von mir "erfunden" für den SQLSaturday Germany 2013)

• Schwachstellen in Zeilen-basierter Sicherheit
• XML Bomb
• Spaß mit Zeichensätzen
  • Tabellen ohne Namen? – Oder überhaupt keine Tabellen?
    „Garantiert eindeutige Objektnamen“ ;-)

(Web)Application Layer

• My form and the WAF don’t let anything pass through – or do they?
  • Standard SQL Injection
  • Blind / Error-based /Time-based SQL Injection, Encoding Injection
  • 2nd Order SQL Injection
  • Privilege Escalation via SQL Injection and trustworthy
  • automated attacks using tools, further “features” (sqlmap,...)
  • “case of the unkillable transaction” - DoS Attack via SQL Injection ("invented" by me for SQLSaturday Germany 2013)

• SQL Server Row- and Cell-Level Security – Disclosure vulnerability
• XML Bomb
• A bit of fun with collation
  • Tables without a name? Or no tables at all?
    “guraranteed unique object names” ;-)

Innerhalb des Netzwerk

• Aufklärung: Erkennen von SQL Server Instanzen
• SQL Authentifizierung
• Beobachten von SQL Traffic (Login + Select)
• Automatisierte brute-Force Attacke gegen sa-Passwörter

Inside the Network

• Reconnaissance: Detecting SQL Server Instances
• SQL authentication
• Watching SQL Traffic (Login + Select)
• Automated brute-Force Attack against sa-passwords
  

Server & Datenbank-Ebene – Angriffe von Innen, Teil 1: der böse Consultant

• SQL Authentifizierung
  • Cracken von Passwörtern – möglich? Wie?
  • Auslesen von Passwörtern aus dem Arbeitsspeicher
• Was ein Consultant so hinterlassen kann
  
  • Automatisierte Einrichtung eines SQL Server Rootkits
• „Wenn der Gast die Party wechselt“
  • Umgehen von Denies durch „guest-guest-impersonation“ – erstmalig gezeigt auf dem PASS Summit 2010 in Seattle :-)

Server & database-Level – attacks from inside, Part 1: evil Consultant

• SQL authentication
  
  • Cracking Passwords – possible? How?
  • Reading passwords from memory
• What a Consultant may leave behind
  
  • Automated install of a SQL Server rootkit
• „When the guest switches the party“
  • Circumventing denies by “guest-guest-impersonation“
    – first shown at PASS Summit 2010 in Seattle :-)

Server & Datenbank-Ebene – Angriffe von Innen, Teil 2: der böse Entwickler

• „Kenne Deine Rechte“
  • "Transfer-Schema Attack"
    – erstmalig gezeigt auf dem PASS Summit 2010 in Seattle :-)

• „Alles meins“ – oder nicht?
  • Datenbankbesitzverkettung
  • Db_owner unterschätzt & ausgenutzt
  • Schema-ownership-chaining

Server & database-Level – attacks from inside, Part 2: evil Developer

• „Know your rights“
  • "Transfer-Schema Attack"
    – first shown at PASS Summit 2010 in Seattle :-)
• „Everything belongs to me“ – does it?
  • Database-ownership-chaining
  • Db_owner underestimated & exploited
  • Schema-ownership-chaining