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

Der verantwortungsvolle Umgang mit Sicherheitslücken

Dienstag, 1. November 2011, 12:32 Uhr

Sicherheitslücken bei Hersteller von Smartphone-Apps” (gulli.com)

Die eigentlich aufgelösten AnonyPwnies – eine Splittergruppe des Onlinekollektivs Anonymous – wollen es noch einmal wissen und veröffentlichen einen letzten Leak. Dieser betrifft die Die Firma “appia.com”, die Shoplösungen für Smartphone-Software programmiert. Diese Shoplösungen weisen offenbar erhebliche Sicherheitslücken auf und ermöglichten den Pwnies das Kopieren großer Mengen sensibler Daten.

“LEAKS NEED THIS MUCH VOLUME – BY: ANONYPWNIES” http://pastebin.com/1HkZxwS4

2 Wochen lang blieb eine Reaktion auf eine SQL-Injection aus:

http://www.sicherheit-online.org/Aktuelle-Themen/Sicherheitslucke-bei-mobile2day.de-wird-ignoriert.html

Als wir das lasen, entschieden wir uns selbst nach der Lücke zu suchen und kamen mit 40GB SQL Backups, 2 GB PHP Scripten, 2 Rootserver Passwörtern, 2 Paypal Accounts und rund 100 GB Android/Windows Mobile/Symbian Apps zurück…


Sicherheitslücke bei mobile2day.de wird ignoriert” (sicherheit-online.org)

…nicht mit einem Erfolg zu verzeichnen.

Bitte was? “von Erfolg gekrönt” heißt es.

Wir bedauern, dass es zu diesen Übergriffen kommen musste.

Es musste nicht, aber wer Skriptkiddies Dreck in die Hand drückt, darf sich nicht wundern, wenn damit auch geworfen wird.

Der Verlauf vom ersten Hinweis bis zum heutigen Tag aber, zeugte mehr von Imkompetenz und Ingoranz, sowie von unprofessioneller Hinhaltetechnik von…

sicherheit-online.org ist inkompetent? Dies sehe ich genau so. Übrigens heißt es “Hinhaltetaktik”.

In dieser Nachricht wurde behauptet, dass keine Warnmeldung von Sicherheit-Online dort angekommen sei.

Wenn keine Bestätigung des Empfangs einer E-Mail versendet wurde, ist es nicht möglich, zweifelsfrei festzustellen, ob eine E-Mail empfangen und gar gelesen wurde.

Man wollte uns die Schuld daran geben, dass diverse “Scans” auf das Portal erfolgten und man behauptete, dass wir mit unserem Beitrag einen 0day Exploit veröffentlicht haben.

sicherheit-online.org hat die Schuld, wenn nun Kundendaten verbreitet werden und finanzielle Schäden bei den Kunden eintreten.

Zudem haben wir darauf hingewiesen, dass der Beitrag – sofern es keine Reaktion mehr geben sollte – wieder online geschalten und ein entsprechendes Update veröffentlicht wird.

Mit anderen Worte: Es wurde versucht eine Reaktion zu erzwingen, um nicht zu sagen, zu erpressen.

Die Verantwortlichen bei

sicherheit-online.org

sollten sich für den Vorgang – ernsthaft – schämen.

Dem ist nichts hinzuzfügen.

Uns trifft hier sicherlich keine Schuld, zumal ein Kontaktversuch stattgefunden hat.

Doch! sicherheit-online.org trifft die Schuld, dass die Skriptkiddys die Büchse öffneten, Daten kopierten und diese nun veröffentlichen werden. Wenn einem eine Lücke und die Schließung dieser wichtig ist, dann greift man auch mal zum Telefon, wenn per E-Mail keine Reaktion zu erhalten ist.

Wir möchten an dieser Stelle die “AnonyPwnies” bitten, Abstand davon zu halten, Kundendaten zu veröffentlichen…

Was für ein lächerlicher Appell. Und, im Straßenverkehr sollte man Abstand halten, ansonsten wird von einer Aussage oder Handlung Abstand genommen.


Wer in der IT-Sicherheit ernsthaft arbeitet, muss auch ein Gespür dafür haben, welche Lücken wie schwerwiegend sind. Eine SQL-Injection gehört eindeutig in die Kategorie von Lücken, die man nicht veröffentlicht, da damit Angriffe und irreparable Schäden provoziert werden. Die Domain und ein Screenshot, auch wenn etwas geschwärzt, reichen schon vollkommen aus, um dem Hinweis nachzugehen und in kürzester Zeit die Lücke zu finden. Das was sicherheit-online.org hier getan hat, ist einfach nur verantwortungslos.

Thema: Sicherheit, SQLi |  4 Kommentare