Die Spambot – Challenge berichtet von einer Kontroll-Oberfläche, die verwendet wird um automatisiert (SPAM-)Nachrichten in Gästebücher oder andere Online-Plattformen einzubringen. Ziel soll es daher sein, die Spambots “aufzuhalten”.
Zuerst verschaffen wir uns wie gewohnt einen Überblick, indem wir die bereit gestellte Oberfläche ausgiebig erkunden und damit experimentieren. Sie stellt sich folgendermaßen dar:
Es handelt sich um ein einziges Formular, dem eine URL übergeben werden kann. Zusätzlich wird die Webseite “/guestbook/” genannt, die verwendet werden kann, um das Senden der SPAM-Nachrichten zu testen. Diese Webseite sehen wir uns auch einmal kurz an.
Das Gästebuch sieht recht unspektakulär aus. Es besitzt Eingabefelder zum Eintragen neuer Nachrichten und eine Auflistung bereits erstellter Einträge. Um zu verhindern, dass Bots SPAM in das Gästebuch eintragen, ist eine “Spam protection” enthalten, die darauf abzielt, zunächst eine Rechenaufgabe zu lösen.
Um den Bot weiter zu untersuchen, rufen wir nochmals die Kontroll-Oberfläche auf und übergeben dem Bot diesmal die URL des Gästebuches, damit dieser einen SPAM-Eintrag darin erstellt. Nach Absenden der Anweisung erhalten wir folgende Ausgabe:
Aus der Rückgabe können wir ableiten, dass…
- der Bot die Webseite herunter läd,
- dabei Cookies übernimmt / übergibt,
- INPUT-Felder und TEXTAREAS identifiziert
- die Spam-Protection-Rechnung löst
- Daten an das Formularfeld sendet (was hier, für das Test-Gästebuch vermutlich deaktiviert wurde, um die Seite nicht zu überfluten)
Diese Erkenntnis lässt uns nun mehrere mögliche Angriffspunkte vermuten:
- wir können den Bot auf eine von uns erstellte Webseite loslassen
- über das Cookie-Feld könnten sich Daten einschleusen lassen (z.B. HTTP-Header-Response-Splitting)
- über eine geeignete Benennung der INPUT-Felder könnte man den Bot zusätzliche Daten eintragen lassen, die ggf. wertvolle Informationen enthalten
- über fehlerhafte Rechnungen oder Angriffe gegen die Auswertung der Spam-Protection könnte man den Bot beeinflussen oder Fehler auslösen
- man könnte den Bot auf seine eigene Kontroll-Oberfläche loslassen um sich so selbst zu deaktivieren (Aufgabe “Stop them!”)
Um den Bot beeinflussen zu können, müssen wir eine eigene Webseite erstellen, die als SPAM-Ziel dienen soll. Dazu begeben wir uns auf einen von uns kontrollierten Webserver und legen eine HTML-Seite an. Ich wähle hier einfacherweise eine Kopie des Gästebuches.
rup0rt@f00l:~$ cd public_html rup0rt@f00l:~/public_html$ rup0rt@f00l:~/public_html$ wget --no-check-certificate https://ctf.fluxfingers.net:2075/guestbook/ --2012-10-28 13:25:49-- https://ctf.fluxfingers.net:2075/guestbook/ Resolving ctf.fluxfingers.net... 149.13.33.74 [...]
Anschließend könnten wir diese Webseite an den Bot zum SPAM-Versand übergeben.
149.13.33.74 - - [23/Oct/2012:12:07:43 +0100] "GET /~rup0rt HTTP/1.0" 301 532 "-" "-" 149.13.33.74 - - [23/Oct/2012:12:07:43 +0100] "GET /~rup0rt HTTP/1.0" 200 1593 "-" "-" 149.13.33.74 - - [23/Oct/2012:12:07:43 +0100] "POST /~rup0rt HTTP/1.0" 301 532 "-" "-" 149.13.33.74 - - [23/Oct/2012:12:07:43 +0100] "GET /~rup0rt HTTP/1.0" 200 1593 "-" "-"
Anhand des Protokoll-Auszuges des Apache-Webservers sehen wir, wie der Bot arbeitet. Zuerst wird die Webseite geladen – hier erfolgt die Analyse -, anschließend wir der Spam versand (POST) und abschließend noch geprüft, ob der Spam-Verand erfolgreich war und ein neuer Eintrag angelegt wurde.
Mit diesem Wissen und der Möglichkeit die Webseite nach unserem Belieben zu verändern, können wir nun versuchen den Bot anzugreifen. Ich habe hier vieles ausprobiert. Von Manipulationen des Cookies über Abfangen der POST-Daten bis hin zu Anlegen von zusätzlichen INPUT-Feldern mit speziellen Namen (z.B. “secret”). Keine dieser Maßnahmen hatte jedoch Erfolg.
Es bleibt jedoch noch die Spam-Protection. Erste Versuche zum Beispiel Division durch Null, Spielereien mit INT_MAX oder mehrere Megabytes große Rechenaufgaben führten nur dazu, dass der Bot die Berechnung abbrach. Weitere Überlegungen, wie das Lösen der Aufgaben intern umgesetzt ist, führte jedoch zu der Erkenntnis, dass es sich um irgendeine Art “eval()“-Anweisung handeln könnte, in PHP zum Beispiel:
<?php
$calc = "1337 * 23";
eval("print $calc;");
?>
Da wir mit unserer Webseite auch die Rechenaufgabe kontrollieren, wäre es möglich, weitere Instruktionen in die eval()-Anweisung einzuschleusen, die dann vom Bot lokal ausgeführt werden würden. Um dies zu testen, wählen wir hier das system()-Kommando, mit dem Tool “id” und fügen es in unser manipuliertes Gästebuch ein.
Spam protection: <b>1+1; system('id');</b>
Nach dem Speichern und einer erneuten Aufforderung an den Bot, SPAM zu versenden, erhalten wir diese Ausgabe:
Und tatsächlich, es funktioniert! Neben der Berechnung der Aufgabe “1+1” wurde auch das mit Semikolon getrennte Kommando “system(‘id’)” ausgeführt und deren Ausgabe an uns zurück gesand! Uns stehen damit alle Möglichkeiten offen, das System weiter zu erfoschen.
Wir bewegen uns also zunächst einmal im Dateisystem mit “ls” umher und sehen uns an, welche Dateien vorhanden sind. Nach einiger Suche stoßen wir dann auch, auf folgendes Listing im root-Verzeichnis:
Demnach gibt es eine Datei namens “6f170bcecda1ca8d3a5435591202988881b34bad”, die auf normalen Linux-System dort nicht hingehört. Diese Betrachten wir mit “cat” und erhalten:
Die Lösung lautet somit “OMG_EVAL_IS_EVIL_SPAM“.