Frisch aus dem Urlaub zurück überraschte mich bei Heise die Nachricht, dass eine mir bisher unbekannte Firma ein Sicherheitsproblem am Microsoft SQL-Server entdeckt und veröffentlicht habe. Sie meldeten das Problem Ende 2008 an Microsoft und die signalisierten, dass das aus deren Sicht keine relevante Lücke sei und nicht behoben wird. Sentrigo schrieb daraufhin ein Tool, dass diese Lücke ausnutzt um sie zu beheben. Dazu muss man das Tool aber regelmäßig immer wieder aufrufen. Erst heute kam ich dazu mal die Hintergründe zu recherchieren.
Welche Tragweite hat das Problem?
Hat jemand Windows-Admin-Rechte an dem Computer auf dem der SQL-Server läuft, dann kann der Windows-Admin die Passwörter der angemeldeten Benutzer im Klartext lesen, weil sie in einer internen Tabelle pro Datenbank-Verbindung gespeichert werden. Das betrifft alle aktuellen Systeme: SQL Server 2000, SQL Server 2005 und SQL Server 2008 (die Betas von R2 daher vermutlich auch).
Während in der Login-Tabelle nur der Hash des Passwortes gespeichert ist, werden die Informationen zu angemeldeten Benutzern unverschlüsselt im Hauptspeicher gehalten. Ein Administrator kann nun mit geeigneten Werkzeugen, z.B. OllyDbg, den Hauptspeicher nach den Passwörtern durchsuchen. Sentrigo hat nun das kostenlose Werkzeug Passwordizer gebaut, dass diese Passwörter findet und mit Schrott überschreibt. Hier ein Beispiel:
C:\WINDOWS>E:\temp\Passwordizer\passwordizer\x86\passwordizer.exe 2212
Process is 32bit
DATA section found at 27cf000
Exe name is C:\Programme\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\sqlservr.exe
MSSQL Server version is 90000 10820000
Scanning for sessions table (Can take up to several minutes)
Session table found at 27e6fe8
Getting user passwords for MSSQL Server 2005
Session id: 51
Username: sa
Password: k******9
Password cleared from memory
Sentrigo Passwordizer process completed successfully
1 passwords removed from memory
Im Output steht eigentlich alles was man wissen muss, insbesondere die Adresse an der die Informationen gefunden werden können. Natürlich ist die bei jedem Start anders, aber damit kann man sich das Problem mal aus der nächsten Nähe ansehen, weil man ja jetzt genau weiß wo man suchen muss.
Aber auch remote kann man die Passwörter lesen, wenn man am SQL-Server SysAdmin-Rechte hat. Das geht aber nur am SQL-Server 2000 und 2005, ab 2008er wurde laut Heise.de der dazu nötige DBCC-Befehl aus anderen Gründen entfernt. Im Securosis Blog verrät ein Sentrigo-Mitarbeiter, dass man "DBCC BYTES" dazu verwenden kann. Das ist aber kein großes Geheimnis, denn nur DBCC Bytes ist im SQL Server 2008 nicht mehr vorhanden, alle anderen gibt es dort weiterhin.
Meine Einschätzung: Ich sehe keine realistische Gefahr für die SQL-Server-Kunden, aber Microsoft hat einen peinlichen PR-Gau erlebt.
Warum? Die Sicherheitslücke ist schon sehr exotisch. Man muss schon zuerst mal Windows-Admin oder wenigstens SQL-Server-SysAdmin sein, um die Lücke ausnutzen zu können. Und dann sieht man nur die Passwörter derjenigen die sich aktuell über SQL-Authentifizierung angemeldet haben. Wenn man die von Microsoft empfohlene Windows-Authentifizierung verwendet, sieht man gar nichts. Was kann der Windows-Admin, der immer auch zugleich SysAdmin ist, mit den SQL-Server-Passwörtern anfangen? Gute Frage. Er darf alles tun, was er ohnehin schon als SysAdmin darf: sich als dieser Benutzer ausgeben und am SQL-Server Dinge in dessen Namen tun.
Die Gefahr besteht also lediglich darin, dass der Anwender SQL-Authentifizierung nutzt und das gleiche Passwort auch für sein Online-Banking, E-Bay oder dergleichen verwendet. Das könnte ein krimineller Windows-Admininistrator mal ausprobieren und ggf. dann tun was er möchte. Die Lücke ist in meinen Augen eher eine Kleinigkeit, da Administratoren auch auf viel einfachere Weise die Passwörter Ihrer Kollegen ausspähen könnten. Dennoch ist es natürlich eine Lücke und eine peinliche noch dazu.
Aber für die bisher weitgehend unbekannte Firma Sentrigo war das der PR-Boost schlechthin. Sie haben Microsoft so richtig vorgeführt, weil Microsoft danach schrie. Natürlich hätte Microsoft das ernst nehmen müssen. Man speichert einfach keine Passwörter im Klartext. Warum auch? Ich habe keine Ahnung wie aufwändig die Behebung gewesen wäre, aber da nun mal alle Mitarbeiter mit dem R2 beschäftigt waren, blieb für solche Dinge wohl keine Zeit mehr. Und damit hat sich Microsoft so richtig blamiert.
Vermutlich werden sie es nun doch beheben müssen, sonst müssen sie sich immer vorwerfen lassen, dass sie eine nicht behobene Sicherheitslücke haben. Und diese Diskussionen mag doch keine Firma gerne… 😉
Update 16.9.2009:
- Ja, es geht mittels DBCC BYTES, das wurde schon im Frühjahr im Vortrag "SQL SERVER Anti-Forensics" von Cesar Cerrudo (Folie 18) veröffentlicht.
- Heute bekam ich eine Mail von Firma Sentrigo, die sich für den Download des Tools "Passwordizer" bedankte und fragte an welchen Lösungen von ihnen ich denn Interesse hätte. Hallo? Am Passwordizer natürlich. Ich bereue bei der Angabe der persönlichen Daten ehrlich gewesen zu sein…
