Category Archives: SQLi

SQL-Injection für Scriptkiddies

Bei den in den letzten Wochen gehäuft aufgetretenen Einbrüchen in Datenbanken mit Kundendaten (LinkedIn, eHarmony, Last.fm, Yahoo Voice Yahoo! Contributor Network, etc.), könnte man auf die Idee kommen, dass da Fachleute am hacken waren — dem muss aber nicht so sein. Auch DAUs kommen leicht per SQL-Injection (und dem richtigen Werkzeug), an Zugangsdaten — und dies ohne jegliche Kenntnisse, wie eine SQLi-Lücke konkret ausgenutzt werden kann.


Das Video zeigt WordPress mit einem Plugin, welches für SQL-Injection anfälligen ist.

Als erstes sieht man den Firefox (mit der HackBar). Wird ein Hochkomma an die 1 von postID gehängt, so wird eine Fehlermeldung ausgegeben. Diese Fehlermeldung ist noch kein Beweis für eine SQL-Injection, aber ein Hinweis darauf, dass hier die Benutzereingaben nicht ausreichend gefiltert werden. Das ausbleiben einer Fehlermeldung wäre hingegen kein Indiz dafür, dass keine Schwachstelle vorliegt, denn Fehlermeldungen können auch generell unterdrückt werden.

Dass das and 1=1 keine Fehlermeldung ausgibt, aber ein and 1=2, ist dagegen schon ein deutlicher Beleg für ein Schwachstelle.

Die weiteren Schritte im Video zeigen nicht die Details einer manuellen SQL-Injection, sondern das Werkzeug Havij, welches den Angriff automatisch durchführt. Es muss nur noch ausgewählt werden welche Daten Havij auslesen soll.

Wie im Video zu sehen ist, gibt es neben der Datenbank “havijdemo” noch weitere Datenbanken. Dies alles ist eine XAMP-Installation in die ich einmal WordPress mit dem für SQLi anfälligen Plugin installiert habe und eine nackte WordPress-Installation. Wer also auf seinem System, und sei es auch nur zum Testen, etwas installiert, worin eine SQL-Injection zu finden ist, der kompromittiert alle Datenbanken auf dem System. Dies sagt uns: Nur weil die Daten aus dem VoIP-Dienst Yahoo Voice Yahoo! Contributor Network stammen, bedeutet dies nicht, dass genau dieser Dienst auch Anfällig für SQL-Injection ist bzw. war, es könnte auch eine vollkommen andere Anwendung auf dem Server angegriffen worden sein.


Was will ich jetzt hiermit verdeutlichen? Das nicht jeder Hack von hochspezialisierten Cyberkriminelle durchgeführt wurde und der Cyberwar nicht vor der Tür steht, nur weil sich dies in den Medien besser verkaufen lässt. Was in den letzten Wochen und Monaten an Zugangsdaten nach oben geschwemmt wurde, geht wahrscheinlich eher auf das Konto der pickligen 15-jährigen DAUs, die entsprechende Tools im Netz entdeckt haben…

15-jähriger Hacker knackte PCs von 259 Firmen” (futurezone.at)

Ein 15-jähriger Hauptschüler aus Niederösterreich soll einen groß angelegten Hackerangriff gegen die Wirtschaft geführt haben. Insgesamt knackte er Computer von 259 Firmen, darunter befanden sich auch 30 österreichische. Der Jugendliche wurde von einer Spezialeinheit des Bundeskriminalamts aufgespürt und angezeigt.



Update: 13.07.2012 – 14:05 Uhr

Es tropfte nicht aus Yahoo Voice, sondern aus dem Yahoo! Contributor Network, siehe: “Yahoo bestätigt Passwort-Leck” (heise.de)

Statisches HTML gegen SQL-Injection

Vor einigen Wochen stieß ich eher per Zufall in einer Seite auf Cross-Site Scripting und SQL-Injection. Wie es so meine Art ist, verschickte ich entsprechende Hinweise, inkl. Beispiel, damit die Fehlersuche und -behebung einfacher wird. Die XSS-Lücke wurde sehr schnell behoben, aber die SQL-Injection war auch nach 4 Wochen noch möglich.

Nur weil es eine bekannte Seite ist, die sich auch dem Thema IT-Security verschrieben hat, erwähne ich dies hier. Ich könnte nun weiter ausholen und darlegen, warum mir diese Seite wichtiger ist als andere, aber damit würde ich den Seitenbetreiber evtl. in eine peinliche Lage bringen und Spott von Dritten braucht er nun ganz sicher nicht, es reicht vollkommen aus, wenn dieser von mir kommt. ;O)

Am Montag habe ich nachgefragt, worauf man denn warten würde und ob da erst ein Angreifer kommen muss, um diesen “bösen Hackerangriff” dann medienwirksam ausschlachten zu können. Ich weiß, eine provokante Frage, aber wer das Thema IT-Security auf seine Fahnen schreibt, der sollte auf Hinweise auch zügig reagieren und ggf. auf freche Fragen von mir gefasst sein. Mir geht es um die Sache, also die Sicherheit der Besucher der Seite, weshalb ich da auch gerne mehrfach nachhake, bis die Lücke geschlossen wird.

Die Antwort fand ich dann doch etwas befremdlich:

Das CMS wurde von einem Kollegen, der nicht mehr im … aktiv ist, selbst gebaut. Kosten der Einarbeitung und “Absicherung”: ca. 7 MT. Daher ist der Plan eine funktionsfähige statische Kopie zu ziehen und die dynamische Seiten abzuschalten. Allerdings müssen noch manche Inhalte eingepflegt werden. Im Anschluss werden die Inhalte auf ein anderes System, auf dem auch die http://www… läuft, gehoben.

Sieben Manntage, um eine Variable gegen SQL-Injection abzusichern? Es werden nur zwei Variablen verwendet und nur eine davon ist vulnerable. Wenn man eh auf ein etabliertes und vielfach bewährtes System umsteigen will, dann braucht man keine Einarbeitung in das alte CMS. Man braucht nur in dem Quellcode nach der entsprechenden Variable und deren Weiterverarbeitung fahnden. Wenn ich in einem CMS solch eine Lücke schließen soll, dann muss ich im schlimmsten Fall den kompletten Quellcode runter laden, um darin automatisiert suchen zu können und der Download dauert sehr viel länger, als die entsprechenden Stellen zu finden und zu fixen. In diesem Fall wäre der Fix recht einfach, da die Variable nur eine ein- oder zweistellige Zahl ist.

Da man wohl von den “7 MT” erschlagen wurde (Um nicht weiter nachzudenken? Man kann auch über den Preis einen Auftrag ablehnen!), hat man nun einfach (<g>) eine Kopie in HTML erzeugt. Die SQL-Injection ist nun nicht mehr möglich. Bravo! Aber… Naja… Verschiedene Links auf der Seite selber funktionieren nicht mehr und zeigen nur noch eine Leere Seite oder Fehlermeldung an und alle (!) Ergebnisse von Google führen auch nur zu einer leeren Seite. Aber egal — Google wird eh überbewertet und da kommen auch kaum Besucher her. Warum hat Google überhaupt Hunderte von Unterseiten in seinen Index aufgenommen? ;O)

Ich bin sicher, wenn ich nicht nachgefragt hätte, dann wäre auch die Umstellung auf statische HTML- und leere PHP-Seiten bzw. Fehlermeldungen (<g>) nicht erfolgt. Sicherheitslücken fixen ist ein “unnötiger” Kostenfaktor ohne jeden Gegenwert?! Die Lücke bestand sehr wahrscheinlich seit 2010, seit Bestehen der Seite. Bisher hat ja niemand (hoffentlich) die Lücke bemerkt und ausgenutzt, also warum jetzt fixen? Nur weil mal wieder der Einmann-CCC vorbeischaut und so penetrant nervt und die Schließung der Lücke fordert, sah man sich wohl gezwungen zu handeln. Keine Sorge, ich hätte nur weiter genervt, aber veröffentlicht hätte ich die Lücke nicht.