SQL Server Sicherheitslücke

Stellen Sie sich vor: Ein Anwender, der keine Berechtigung in ihren Datenbanken besitzt stoppt ihren SQL Server oder löscht wichtige Datenbanken!

Das kann auf Ihrem Server nicht passieren?

Falls Ihr Server im gemischten Sicherheitsmodus läuft, sollten Sie weiterlesen:

Die Falle

Der SQL Server 7.0 wartet mit zwei sehr mächtigen neuen Funktionen auf: OPENROWSET und OPENQUERY. Beide Funktionen ermöglichen den Aufbau zu einem anderen (oder auch dem gleichen) Server mittels OLEdb. Dabei werden die Funktionen einfach als Argument in einem SELECT aufgeführt. Während für OpenQuery explizit ein sogenannter "Linked Server" eingerichtet werden muß, können mit OpenRowset direkte adhoc-Abfragen ausgeführt werden. Als Parameter können dabei der Name des OLEdb-Providers und eine Verbindungszeichenfolge angegeben werden. Die im dritten Parameter festgelegte Anweisung wird schließlich ausgeführt und das Ergebnis als Resultset zurückgeliefert.

In der Online-Dokumentation finden Sie dazu das folgende kleine Beispiel zum Ausprobieren:

USE pubs
GO
SELECT a.*
FROM OPENROWSET('SQLOLEDB','myServer';'sa';'MyPass',
    'SELECT * FROM pubs.dbo.authors ORDER BY au_lname, au_fname') AS a
GO

Dieses Beispiel funktioniert problemlos; es wird hier jedoch ein Kennwort direkt im SELECT hinterlegt. Eleganter wäre da doch die Option die Anmeldeinformationen des aktuellen Benutzers einfach weiterzureichen. Nach einigem Suchen in der Dokumentation fand ich den entscheidenden Hinweis: Die Verbindungszeichenfolge muß so aussehen:

'Trusted_Connection=yes;Data Source=myServer;'

Die Einstellung "Trusted_Connection=Yes" veranlasst den SQL Server eine vertraute Verbindung aufzubauen (also nicht wie im Beispiel oben eine Verbindung über die Standard SQL Server Sicherheit mit Benutzername und Kennwort).

Mit dieser Methode können übrigens nicht nur Ergebnisse aus einer SELECT-Anweisung zurückgegeben werden, sondern auch aus gespeicherten Prozeduren:

SELECT * FROM
OPENROWSET('SQLOLEDB', 'Trusted_Connection= yes;Data Source=meinServer;', 'EXECsp_validatelogins') As result

So weit, so gut.

Eine Überraschung

Die Überraschung kam, als ich eines Tages die OpenRowset-Methode für eine Prozedur aufrief, für die ich als angemeldeter Benutzer eigentlich keine Berechtigung besaß. Um Herauszufinden, was auf dem Server passiert, verfolgte ich den Sitzungsverlauf mit dem SQL Server Profiler. Dabei wurde schnell klar, daß für "normal" angemeldete Benutzer die vertraute Verbindung nicht unter dem eigenen Konto aufgebaut wird, sondern unter dem Konto des SQL Servers .

Mit Hilfe der folgenden Anweisung können Sie das leicht selber ausprobieren:

SELECT result.*
FROM OPENROWSET('SQLOLEDB', 'Trusted_Connection=yes;Data Source=IDCMUC;', 'SELECT SUSER_SNAME() ') as result

Wenn man sich den Ablauf dieser Abfrage im SQL Profiler ansieht, wird schnell klar was passiert:

1. Die SELECT-Anweisung wird ausgeführt. Der Benutzer ist beim SQL Server als Benutzer "danger" und unter NT als Benutzer "svenh" angemeldet.
2. Auf dem SQL Server wird eine neue Verbindung unter dem Konto des SQL Servers aufgebaut.
3. Die "inneren" SELECT-Anweisungen (Parameter der OpenRowset-Funktion) werden unter dem Konto des SQL Servers ausgeführt.

Das sieht auf den ersten Blick nicht allzu bedrohlich aus - denn damit wäre scheinbar nur der Zugriff mittels SELECT auf ansonsten "verbotene" Tabellen und Sichten möglich. Mit einem kleinen Trick (den ich hier (noch) nicht verraten möchte)  lassen sich jedoch alle Transact-SQL Anweisungen (wie z.b. xp_cmdshell oder DROP DATABASE) über solch eine Verbindung ausführen.

Ist Ihr Server betroffen?

Das beschriebene Verhalten tritt nur auf, wenn sich Benutzer über die SQL Sicherheit mit Benutzername/Kennwort am Server anmelden. Wenn Sie vertraute Verbindungen verwenden, werden die Anmeldeinformationen so wie erwartet übernommen. Der folgende Trace-Mitschnitt zeigt das:

Auch hier wird eine neue Verbindung zum Server aufgebaut (2), aber dieses Mal werden die Anmeldeinformationen des Benutzers (in diesem Fall 'svenh') für die neue Verbindung übernommen. Somit werden für den "inneren" SELECT die Berechtigungen des angemeldeten Benutzers verwendet (3).

Was Sie tun können 

Microsoft hat sehr schnell einen Hotfix bereitgestellt, der das Verhalten der OPENROWSET-Funktion verändert. Ist das Hotfix installiert, so erhalten Benutzer, die über eine nichtvertraute Verbindung eine Adhoc-Abfrage mittels OpenRowset starten, eine Meldung, dass diese Funktion deaktiviert ist. Dieses Verhalten erreichen Sie übrigens auch, wenn Sie in den Registrierungseinträgen des SQL Servers einige kleine Änderungen vornehmen. Eine genaue Beschreibung dieser Änderungen finden Sie unter http://www.microsoft.com/technet/security/bulletin/fq00-014.asp .

sven hammesfahr , märz 2000

Weitere Informationen:

Problembeschreibung auf der Microsoft Sicherheits Seite:

http://www.microsoft.com/technet/security/bulletin/ms00-014.asp

Hotfix/Patch zum Herunterladen:

http://www.microsoft.com/downloads/release.asp?ReleaseID=19132

FAQ (häufig gestellte Fragen) zu diesem Problem:

http://www.microsoft.com/technet/security/bulletin/fq00-014.asp