{"id":3534,"date":"2009-09-11T20:17:05","date_gmt":"2009-09-11T18:17:05","guid":{"rendered":"http:\/\/www.glorf.it\/blog\/?p=3534"},"modified":"2009-09-16T19:54:13","modified_gmt":"2009-09-16T17:54:13","slug":"sentrigo-veroeffentlicht-sicherheitsproblem-des-sql-servers","status":"publish","type":"post","link":"http:\/\/www.glorf.it\/blog\/2009\/09\/11\/sql-talk\/sql-server\/sentrigo-veroeffentlicht-sicherheitsproblem-des-sql-servers","title":{"rendered":"Sentrigo veröffentlicht Sicherheitsproblem des SQL-Servers (Update)"},"content":{"rendered":"

Frisch aus dem Urlaub zurück überraschte mich bei Heise<\/a> 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.<\/p>\n

Welche Tragweite hat das Problem? <\/strong>
\nHat 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).<\/p>\n

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<\/a>, den Hauptspeicher nach den Passwörtern durchsuchen. Sentrigo<\/a> hat nun das kostenlose Werkzeug Passwordizer<\/a> gebaut, dass diese Passwörter findet und mit Schrott überschreibt. Hier ein Beispiel:<\/p>\n

C:\\WINDOWS>E:\\temp\\Passwordizer\\passwordizer\\x86\\passwordizer.exe 2212
\nProcess is 32bit
\nDATA section found at 27cf000
\nExe name is C:\\Programme\\Microsoft SQL Server\\MSSQL.1\\MSSQL\\Binn\\sqlservr.exe
\nMSSQL Server version is 90000 10820000
\nScanning for sessions table (Can take up to several minutes)
\nSession table found at 27e6fe8
\nGetting user passwords for MSSQL Server 2005
\nSession id: 51
\nUsername: sa
\nPassword: k******9
\nPassword cleared from memory<\/p>\n

Sentrigo Passwordizer process completed successfully
\n1 passwords removed from memory<\/p><\/blockquote>\n

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. <\/p>\n

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<\/a> der dazu nötige DBCC-Befehl aus anderen Gründen entfernt. Im Securosis Blog<\/a> 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<\/a>, alle anderen gibt es dort weiterhin.<\/p>\n

Meine Einschätzung:<\/strong> Ich sehe keine realistische Gefahr für die SQL-Server-Kunden, aber Microsoft hat einen peinlichen PR-Gau erlebt.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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. <\/p>\n

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… \ud83d\ude09<\/p>\n

Update 16.9.2009:<\/strong><\/p>\n