SQL-Injection wird mal wieder ignoriert
Sonntag, 25. Dezember 2011, 12:59 Uhr
Eine SQL-Fehlermeldung bedeutet nicht, dass es auch eine Möglichkeit für SQL-Injection gibt. Anders herum bedeutet das Fehlen einer Fehlermeldung nicht, dass es keine Lücke gibt. Ein einfacher Test mit and 1=1 und and 1=2 zeigt, ob eine Injektion möglich ist. Wurde eine Lücke identifiziert, prüft man die Anzahl der Tabellenspalten, wobei es auch hier eine hilfreiche Fehlermeldung gibt. Hat man die korrekte Anzahl der Tabellenspalten gefunden, sieht man in der Regel die injizierten Ziffern, die man dann mit den Systemvariablen user(), database(), version() ersetzten kann. Für einen Proof of Concept reicht dies meist aus, um dem Seitenbetreiber die Schwachstelle zu demonstrieren.
In diesem Beispiel sollen die Zugangsdaten ausgelesen werden, daher wird einfach nach ‘pass’ in der Datenbank gesucht. Hier werden die Hochkommata nicht so einfach übernommen, weshalb die Anfrage in Hexcode umgewandelt wird. Es gibt drei Tabellen in denen offensichtlich Passworte gespeichert werden: login, login_secured und users. In der Tabelle login wir nun nach den Bezeichnungen der Tabellenspalten gesucht, um im letzten Schritt die Zugangsdaten auslesen zu können: Das meistbenutzte Passwort ever!
Das Passwort wird hier im Klartext in der Datenbank gespeichert. Meist wird man aber einen Hash (MD5, SHA1) finden, für den man dann noch die Entsprechung, also das Passwort, herausfinden muss. Dank fehlendem Salt und einfachen Passworten, ist auch dies meist relativ schnell erledigt.
Mit den richtigen Werkzeugen lässt sich dies alles auch bewerkstelligen ohne zu verstehen was SQL ist — am Ende fallen nur die Zugangsdaten aus dem Tool.
In dem Beispiel wurden Daten nur ausgelesen, es ist natürlich auch möglich diese zu ändern, zu löschen oder komplett neue Datensätze hinzuzufügen.
Abhängig davon wie ein Angreifer vorgeht, wird der Seitenbetreiber nichts von dem Angriff mitbekommen. Erst wenn tausende von Kundendaten abgeflossen sind, diese missbraucht wurden, Kunden eindeutig feststellen können “Nur Shop-X hat meine Daten.” und sich beschweren, erst dann wird der Seitenbetreiber aufmerksam.
Wie man sieht, ist ein Angriff per SQL-Injection sehr einfach durchzuführen. Auch minderbegabte Scriptkiddies können hier großen Schaden anrichten, weshalb es mich immer wieder wundert, wie ignorant und leichtfertig Seitenbetreiber mit entsprechenden Hinweisen umgehen. Wenn dann mal wirklich eine Reaktion auf eine meiner Hinweise kommt, dann wird auch nur darauf geschaut, dass genau mein Beispiel nicht mehr funktioniert, dass aber an vielen anderen Stellen die gleiche Lücke besteht, wird außer Acht gelassen. Es wird immer nur an den schlimmsten Bugs geflickt und auch nur wenn man befürchten muss, dass dies öffentlich wird.
Ich habe noch immer die Hoffnung, dass es irgendwann eine Stelle gibt, denen man Sicherheitslücken melden kann und die, mit den richtigen Sanktionsmitteln ausgestattet, sich mit dem Seitenbetreiber auseinandersetzen und am Ende dafür sorgen können, dass die Lücke oder die Website geschlossen wird.
Die verfremdeten Screenshots gehören nicht zu dem ignoranten Seitenbetreiber. Es gibt so viel Unrat im Netz, da fand ich schnell eine Seite für mein Beispiel.
Thema: SQLi | Kommentare geschlossen
