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!