5 verrückte SQL-Injection-Geschichten aus echten Pentest- und Bug-Bounty-Berichten

SQL-Injection ist eine der ältesten Schwachstellenklassen überhaupt – seit über 25 Jahren bekannt, seit Jahren trivial vermeidbar (Prepared Statements, Parametrisierung), und trotzdem taucht sie immer wieder auf, von Indie-Startups bis zu Fortune-500-Firmen und Behörden. Fünf reale, öffentlich dokumentierte Fälle – technisch eingeordnet, mit Quellen zu jedem.

1. RockYou – 32 Millionen Passwörter im Klartext (Dezember 2009)

RockYou baute Widgets und Mini-Apps für MySpace und Facebook. Eine SQL-Injection-Schwachstelle in der Webanwendung erlaubte Angreifern, die komplette Nutzerdatenbank auszulesen – rund 32 Millionen Konten. Die eigentliche Katastrophe war aber nicht die Injection selbst, sondern was sie freilegte: RockYou speicherte sämtliche Passwörter unverschlüsselt im Klartext, kein Hashing, kein Salting. Aus einer reinen Datenextraktion wurde damit ein sofortiger Vollzugriff auf jedes einzelne Passwort – kein Cracken nötig.

Die Liste kursiert bis heute als rockyou.txt und ist Standard-Wordlist in so gut wie jedem Passwort-Cracking-Tool (Hashcat, John the Ripper). Über 15 Jahre später greift praktisch jeder Pentest weltweit auf genau diese Liste zurück, um andere Systeme auf schwache Passwörter zu testen – der Angriff hat sein eigenes Nachleben als Werkzeug der gesamten Security-Branche.

→ RockYou hack compromises 32 million passwords, SC Media → RockYou hacked, VentureBeat

2. PBS, gehackt von LulzSec – Tupac lebt (angeblich) (Mai 2011)

Nachdem PBS eine WikiLeaks-kritische Dokumentation ausgestrahlt hatte, nutzte die Hackergruppe LulzSec SQL-Injection, um sich Zugriff auf das Content-Management-System von PBS zu verschaffen. Der technische Ablauf ist der klassische Dreischritt: verwundbaren Parameter finden, die Admin-Zugangsdaten-Tabelle per Injection auslesen, mit den erbeuteten Zugangsdaten ganz regulär als authentifizierter Nutzer ins CMS einloggen. Die gedumpten Zugangsdaten – inklusive Logins für lokale PBS-Sender – wurden anschließend öffentlich gepostet.

Der eigentliche Payload war aber kein Datendiebstahl im klassischen Sinn, sondern ein Streich: LulzSec veröffentlichte über den erbeuteten CMS-Zugang eine gefälschte Breaking-News-Meldung, dass Tupac Shakur noch lebe und in Neuseeland wohne. Der Artikel bekam über 3.000 Facebook-Likes, bevor er als Fake entlarvt wurde – SQL-Injection nicht für Profit, sondern für maximalen Trollcontent.

→ PBS hacked by LulzSec, The Hacker News → Thousands ‘Like’ Fake Tupac Story, Forbes

3. Starbucks – fast eine Million Finanzdatensätze für 4.000 Dollar (2019)

Sicherheitsforscher Eugene Lim (Bug-Bounty-Handle spaceraccoon) stieß bei Subdomain-Enumeration auf eine fast vergessene Starbucks-Subdomain mit einem simplen HTML-Datei-Upload-Formular, dahinter ein altes Microsoft Dynamics AX ERP-System. Erste Versuche mit Datei-Upload-Schwachstellen und XXE (XML External Entity) liefen ins Leere. Einen Monat später kam er zurück und testete stattdessen SQL-Injection – diesmal erfolgreich. Mit Microsofts eigener öffentlicher Dynamics-AX-Dokumentation identifizierte er die Standard-Tabellen- und Spaltennamen des Systems und konnte darüber gezielt abfragen, wie viele und wie aktuelle Datensätze vorlagen.

Ergebnis: Zugriff auf knapp eine Million echte Datensätze mit Buchhaltungs-, Steuer-, Beleg- und Gehaltsabrechnungsdaten. Gemeldet am 8. April 2019, gepatcht innerhalb von zwei Tagen. Bounty: 4.000 US-Dollar – laut Starbucks der Maximalbetrag, den das Programm für kritische Schwachstellen zahlt, unabhängig vom tatsächlichen Ausmaß.

→ SQL Injection Vulnerability Exposed Starbucks Financial Records, SecurityWeek → HackerOne Report #531051

4. Valve – 25.000 Dollar für dieselbe Bugklasse

Zum Vergleich: Eine SQL-Injection in report_xml.php über den Parameter countryFilter[] brachte einem Bug-Hunter bei Valve 25.000 US-Dollar ein – die höchste öffentlich bekannte SQLi-Bounty im HackerOne-Datensatz. Technisch fällt so ein Bug oft durch dasselbe blinde Loch: Array-Parameter (erkennbar an der []-Schreibweise, mehrere Werte unter einem Formularfeld) werden häufig anders behandelt als einzelne Werte – viele Sanitization-Schichten sind nur für skalare Eingaben geschrieben und prüfen nie, dass die einzelnen Array-Elemente Zeichen für Zeichen in eine SQL-IN (...)-Klausel einkonkateniert werden. Ein sehr verbreitetes, reales Muster, gerade in älteren PHP-Backends.

Gleiche Bugklasse wie bei Starbucks, gut sechsmal so hohe Bounty – ein guter Beleg dafür, wie stark die Bezahlung je nach Bug-Bounty-Budget des Programms schwankt, unabhängig vom tatsächlichen Risiko.

→ HackerOne Report #383127

5. Das Nummernschild “NULL” (2019)

Kein Web-Bug, aber dieselbe Bug-DNA: Sicherheitsforscher Droogie ließ sich in Kalifornien das Wunschkennzeichen “NULL” geben – halb als Scherz, halb in der Hoffnung, automatische Kennzeichen-Erkennung oder das Ticket-System des DMV zu verwirren. Es hat funktioniert – nur anders als gedacht: Bußgeldstellen-Systeme scheinen den String "NULL" intern als Platzhalter für Strafzettel ohne erfasstes Kennzeichen zu verwenden – vermutlich Text-Gleichheit (WHERE plate = 'NULL') statt eines echten SQL-NULL-Werts. Sobald sein reales Kennzeichen ebenfalls "NULL" lautete, wurde ihm jedes nicht zuordenbare Ticket automatisch zugeschrieben.

Ergebnis: über 12.000 US-Dollar an fremden Strafzetteln landeten bei ihm. Nach einer öffentlichen Klärung wurden die Bußgelder gestrichen – Droogie behielt das Kennzeichen trotzdem und kassierte weitere Tickets. Kein SQLi im engeren Sinn, aber dieselbe Wurzelursache wie bei jeder Injection-Schwachstelle: ein String, dessen Bedeutung (Platzhalter für “kein Wert”) mit seinem Inhalt (der literale Text) verwechselt wird.

→ Security Researcher’s ‘NULL’ Vanity Plates Cause Glitch, Gizmodo → Hacker Gets $12,000 In Parking Tickets, Forbes

Fazit

Der rote Faden durch alle fünf Fälle: Die Bugklasse ist uralt, technisch gut verstanden und mit Prepared Statements zuverlässig vermeidbar – und trotzdem reicht die Bandbreite der Folgen von einem viralen Fake-News-Post bis zu einer Million echten Finanzdatensätzen für eine vierstellige Bounty. Der Unterschied zwischen einem harmlosen Scherz und einem Millionen-Datensatz-Leak liegt selten in der Schwachstelle selbst – sondern darin, wessen Datenbank gerade nicht zwischen Daten und Bedeutung unterscheidet.