SQL-Injection legt Newsletter lahm

Die Sache begann sehr alltäglich: Im Zuge einer Wohnungssuche hatte ich mich irgendwann beim Immobilienmakler Immosky [1] für dessen Newsletter angemeldet. Als ich einige Zeit später eine Unterkunft gefunden hatte, wollte die nunmehr überflüssigen Empfehlungsschreiben wieder abbestellen. Ein Abmelden-Link im Newsletter führte mich zur Webseite des Schweizer Unternehmens. Die gab sich überraschend gesprächig: Offensichtlich für Debugging-Zwecke zeigte sie das SQL-Statement an, das meine Newsletter-Zusendung eben deaktiviert hatte.

Die Debugausgabe auf dem Produktivsystem lässt mich aufmerken werden: Webprogrammierer, denen so was egal ist, haben bestimmt noch Leichen im Keller. Auf mich wirkt die Debugausgabe wie eine Einladung zum Angriff. Sie hilft mir beim Einstieg, denn sie zeigt genau das SQL-Statement, das der Datenbankserver später abarbeiten wird. So sehe ich, welche Get- oder Post-Parameter wo in der Anfrage landen, ob die Webapplikation die Eingabe filtert und ob sie Sonderzeichen richtig schützt. Wer die Fehlermeldungen aus Abbildung  1 studiert, erfährt, dass Immosky einen Windows-Server mit PHP benutzt, der mehrere virtuelle Webserver anbietet und ohne Passwort per ODBC-Treiber aus PHP auf eine lokale MySQL-Datenbank zugegreift. Per Firebug [2] findet der Angreifer ferner aus den HTTP-Headern heraus, dass der Anbieter PHP  4.2.2 auf einem IIS  6.0 einsetzt – beide nicht aktuell und womöglich für bekannte Exploits empfänglich.

Abbildung 1: Die überflüssigen Fehlermeldungen verraten weitere Informationen über den Server – eine prima Einstieghilfe für Hacker.

Meine Neugier auf fremden Webseiten zu befriedigen, versuche ich sehr sorgfältig zu organisieren. Lehne ich mich zu weit aus dem Fenster, droht Strafe wegen Ausspähens von Daten (siehe Kasten "Gesetzeslage"). Zwar ist das nur dann illegal, wenn die Daten besonders gesichert sind. Doch schreiben die StGB-Kommentare, dass es mehr auf den Wunsch des Betreibers nach Sicherung als auf deren tatsächliche Güte ankommt.

Das Injizieren eigener Daten in Richtung Server passiert wie beim Cross-Site-Scripting über die HTTP-Parameter der Webseite-URL [3]. Serverseitig arbeitet ein CGI-Skript, das die Parameter entgegennimmt und zu einem Select-Statement in SQL umarbeitet. Und genau dabei lauern die Fallstricke.

Erstmal Anpiksen

Einen Schaden soll der erste Test aus juristischen, aber auch aus taktischen Gründen nicht anrichten – Hacker versuchen unterm Radar zu bleiben. Das gelingt, wenn ich die in der URL übergebenen Datenbankparameter um ein neutrales Element ergänze, also eines, dass das Ergebnis der Abfrage nicht verändert. So ergibt »A OR FALSE« wieder »A« . Der Debugcode in Abbildung  2 beweist, dass ich die Anfrage geeignet modifiziert habe.

Abbildung 2: Die SQL-Injection funktioniert offenbar. In diesem Beispiel bleibt der Angriff bewusst ohne Auswirkung auf die Datenbank.

Ein Cracker hätte die Bedingung im Parameter um »OR TRUE« ergänzt, was logisch immer »TRUE« ergibt. Praktische Folge: Die Immosky-Website hätte alle ihre Newsletterabonnements gekündigt. Den Erfolg erkennt der böswillige Angreifer an der möglicherweise höheren Laufzeit der Abfrage, wenn die Datenbank in allen Datensätzen ein Feld ändert.

Eigene Daten reinströmen lassen

Ich darf annehmen, dass die Immobiliendatenbank keinen Schaden nimmt, wenn ich versuche, mehr Datensätze zu sehen, als die aktuellen Suchkriterien eigentlich hergeben. Eine breiter angelegte, vom Anbieter vorgesehene Suche zeigt diese Daten nämlich ebenso an.

Beim Testen hilf mir der Trick mit »OR TRUE« : Akzeptiert das darunterliegende Skript die Injection, darf ich auf eine umfangreichere Ausgabe hoffen. Falls durch den Angriff ein Syntaxfehler entsteht, kommt entweder eine hilfreiche Fehlermeldung oder gar keine Ausgabe. So finde ich durch Versuch und Irrtum heraus, welche Parameter in das SQL-Statement eingehen und welche für andere Zwecke gedacht sind. Tatsächlich zeigt sich auch die Suchfunktion anfällig diesen Vorstoß, wie Abbildung  3 beweist.

Abbildung 3: Die offensichtlich unsinnigen Angebote beweisen: Auch die Suche ist angreifbar.

Durch Experimente und in Kenntnis der booleschen Rechenregeln kriege ich sogar heraus, wie die einzelnen Suchparameter geklammert sind. Bei Immosky bietet sich an, zwei Suchparameter in der Suchmaske zu setzen und dann nur einen mit »OR TRUE« zu erweitern. So lassen sich SQL-Injections verfeinern.