Eintrag von 2012-01-01
▶ Wie der Grinch das Botnet gestohlen hat
Anmerkung: Aus Sicherheitsgründen sah ich mich dazu veranlasst, einige Namen und Bezeichner in diesem Text zu zensieren, da es mit Kenntnis dieser möglich ist, unerlaubt Kontrolle über einige fremde Computersysteme zu erlangen. Ich bitte um Verständnis, dass ich diese Daten deshalb nicht öffentlich machen kann.
Der Advent ist schon lange keine stille Zeit mehr. Abseits vom normalen Weihnachtsstress bietet sich rund um die Feiertage auch ein für Cracker attraktives Zeitfenster, um in diesen Tagen weniger genau als üblich bewachte Systeme zu entern und unter ihre Kontrolle zu bringen. Mit so einem Zwischenfall hatte ich kürzlich zu kämpfen, als das IDS eines Webservers verdächtige Aktivitäten in der Nacht vom 22. auf den 23. Dezember meldete.
Ein VHost des installierten Apache-Webservers wuchs des Nachts um einige unschuldig aussehende Dateien im Cache-Directory eines populären CMS - einem Ort im Dateisystem, auf das der Webserver zwingend Schreibzugriff benötigte. Ich musste gar nicht tief graben um zu wissen, womit ich zu tun hatte: die scheinbar unschuldige Textdatei mit dem Namen "os2.txt" demaskierte sich rasch als ein in Perl zusammengehackter IRC-Bot, der über einen im Script kodierten C&C (Command and Control) Channel eine Vielzahl Kommandos entgegennehmen konnte, um auf diese Geheiße hin allerhand unangenehme Aktionen zu starten. Die Palette reichte vom Auffinden von Schwachstellen in Webseiten (Google-Dorks) über Bulk-Mailing via MTA des infizierten Systems und einen etwas kruden TCP-Portscanner bis hin zum Up- und Download von Files via XDCC bzw. HTTP. Ein wahres Schweizer Offiziersmesser für übelwollende Scriptkiddies also.
Einfaches Löschen der unerwünschten Datei ist in so einem Fall niemals anzuraten - man muss analysieren, was man sich eingefangen hat, um dann entsprechende Gegenmaßnahmen planen und umsetzen zu können. Ich beschloss also, dem Möchtegern-Einbrecher ein bisschen nachzusteigen, und mir anzusehen, was er denn so alles treibt oder noch zu treiben plant. Da das Schadprogramm nicht durch primitive Behelfe wie base64-Encoding des Quellcodes obfuskiert war, konnte ich ohne lästige Umwege Einblick in seine Funktionsweise nehmen. Schon in den ersten paar Zeilen der Datei fanden sich einige vielversprechend aussehende Skalardefinitionen:
1 #!/usr/bin/perl [...] 18 my $fakeproc = "/usr/sbin/apache2 -k start"; 19 my $ircserver = "irc.plasa.com"; 20 my $ircport = "6660"; 21 my $nickname = "user-redacted[".int(rand(100))."]"; [...] 23 my $channel = "#channel-redacted"; 24 my $admin = "maliciousUser"; [...]
Ohne den folgenden Code zu lesen konnte ich daraus mit einiger Sicherheit die folgenden Schlüsse ziehen:
- Es handelt sich um einen IRC-Bot.
- Die Intention des Crackers ist es, mehrere solcher Bots parallel zu installieren und zu kontrollieren - deswegen wird der Nickname des Bots (leidlich) zufällig generiert.
- Der Bot scheint zur "Authentifizierung" seines Meisters lediglich dessen IRC-Nickname zu prüfen.
Einer so indirekten wie herzlichen Einladung in einen Botnet-CNC-Channel konnte ich natürlich nicht widerstehen, und leitete meinen ohnehin laufenden IRC-Client gleich in Richtung irc.plasa.com, Teil eines indonesischen IRC-Netzwerkes. Das ergab Sinn, denn der HTTP-Request, den ich laut httpd Access-Log für das Einpflanzen der os2.txt-Datei als verantwortlich identifizieren konnte, erging laut WHOIS ebenfalls von einer Quell-IP-Adresse aus dem Netz der "PT TELKOM INDONESIA", direkt aus dem schönen Jakarta.
irc.plasa.com erwies sich nach dem Verbinden als Teil der "AllNetwork"-Föderation. Dass ich dort normalerweise nichts zu schaffen habe, hinderte mich nicht daran, ein bisschen herumzustöbern. Zuerst wollte ich wissen, ob mein alter Bekannter "maliciousUser" - seines Zeichens passionierter Botnet-Züchter und Drohnen-Meister - für ein persönliches Pläuschchen zu haben wäre:
/WHOIS maliciousUser * maliciousUser: No such nick/channel
Schade, niemand zum Plaudern da. Wenn schon der Meister nicht anwesend ist, dann doch vielleicht eine seiner fleißigen Drohnen? Und um vor solchen einen guten und vertrauenswürdigen Eindruck zu machen, hilft es doch bestimmt, wenn man eine ihnen vertraute Identität annimmt...
/NICK maliciousUser * You are now known as maliciousUser -NickServ- This nickname is registered. Please choose a different nickname, or identify via /NickServ identify <password>.
maliciousUser legte also Wert darauf, dass nur er selbst seinen Nickname tragen würde - deshalb hatte er ihn sich via NickServ reservieren lassen. Das alleine hält niemanden im IRC davon ab, die Identität (bzw. den Nickname) eines beliebigen Users anzunehmen, der momentan nicht online ist. Erst wenn der rechtmäßige "Besitzer" eines Nicknames diesen annehmen möchte und dann feststellt, dass ihn jemand anders trägt, kann er ggf. via Nachricht an NickServ unter Angabe seines Passwortes einen Kick des Identitätsdiebes veranlassen, und daraufhin selbst den so freigewordenen Nickname übernehmen. Der gute maliciousUser war zum Zeitpunkt meiner Nachfroschungen nicht verbunden, und konnte somit nicht einmal hilflos zusehen, als ich die Kontrolle über seine Drohnen übernahm...
/JOIN #channel-redacted /NAMES #channel-redacted * Users on #channel-redacted: maliciousUser user-redacted[93]
Nun, das war zugegeben etwas weniger, als ich mir erwartet hätte: Ein einzelner, etwas armselig und einsam wirkender Bot, verlassen sogar von seinem (vermuteten) Meister maliciousUser - wobei es diese Beziehung noch zu prüfen galt. Laut mir vorliegendem Sourcecode des Bots sollte es das Kommando "!reset" geben, welches, sofern der Bot-Admin es in den Channel oder direkt in ein Query für den Bot schreibt, einen totalen Neuaufbau seiner IRC-Verbindung bewirken sollte. Und tatsächlich:
<maliciousUser> !reset * user-redacted[93] has quit (Quit: Restarting...) <user-redacted[93]> Hi maliciousUser im here !!!
Mein neuer Freund user-redacted[93] ließ sich ohne Umschweife dazu überreden, sich neu zu verbinden. Mehr noch: nach dem erfolgreichen Reconnect war er sogar so freundlich, mir in gebrochenem Englisch mitzuteilen, dass er jetzt anwesend (und bereit zur Entgegennahme neuer Kommandos) wäre.
Nach ein bisschen Umgraben im Quellcode meiner Bot-Kopie beschloss ich, dass ich genug gesehen hatte - die "erweiterten" Features wie z. B. eine vollwertige Shell auf dem infizierten Host musste ich gar nicht mehr mit eigenen Augen sehen, um dem Treiben des echten maliciousUser einen Riegel vorschieben zu wollen. Was aber tut man in so einem Fall? Ohne mehr über die Identität des wahren maliciousUser zu wissen, gibt es nicht viel, das man proaktiv unternehmen könnte. Eine kurze Anfrage bei NickServ ergab, dass es den registrierten Nickname "maliciousUser" noch nicht einmal ganz zwei Tage gab, und dass dieser seine Registrierung noch nicht (via E-Mail-Validation - die E-Mail-Adresse dafür wird von NickServ in der Regel, und so auch hier, nicht herausgegeben) bestätigt hätte. Aus dem Banner des IRC-Servers vermochten mir meine nicht gerade famosen Indonesisch-Kenntnisse auszudeutschen, dass man im Channel #help Administratoren des Netzwerks kontaktieren könnte:
/NICK c0l0 /JOIN #help * Now talking on #help <c0l0> hi everyone <SkiN> yes <SkiN> may i help u ? <c0l0> I need to find out the email address of a person who registered with the nickserv service on your network. I do know the nickname of that person. is that possible? <SkiN> who ? <SkiN> can you speak in bahasa ? <c0l0> sorry, only English or German <c0l0> (and a little bit of Italian) <SkiN> hehe * SkiN just can speak bahasa and litle bit of english <c0l0> it's about the user with the registered nickname "maliciousUser" <SkiN> who the person you're looking for <SkiN> wait pls <c0l0> I will. thanks for your support :) <SkiN> but before i give you the information <SkiN> may i know who are you ? <c0l0> I'm a network administrator. I have reasons to believe that "maliciousUser" is responsible for an intrusion attempt into one of our web servers. <SkiN> maliciousUser has NOT COMPLETED registration verification <c0l0> yes, I noticed that from querying nickserv <SkiN> [16:53] -NickServ- Email : cristercorp@gmail.com (hidden) [...]
So weit, so gut. Wenige Sekunden bevor ich die E-Mail-Adresse durch den freundlichen Admin SkiN mitgeteilt bekommen hatte, passierte in #channel-redacted allerdings etwas Bemerkenswertes: user-redacted[93] schaltete sich selbst spontan ab! Das kann natürlich wirklich Zufall sein - oder aber der Hinweis darauf, dass zumindest SkiN (oder ein mit ihm bekannter User des Netzwerks) irgendwie im Zusammenhang mit dem Aufbau oder Betrieb des Botnetzes stehen könnte. Da sich dieses aber nunmehr auf die ungefährliche Größe von 0 Hosts reduziert hatte, beschloss ich, den Netzwerk-Admin aus user-redacted[93]s IP-Block eine kurze Mitteilung zukommen zu lassen: Dass dieser Host Teil eines Botnetzes wäre, und dass man den Administrator der Maschine zu einem etwas vorgezogenen Neujahrsputz anhalten sollte. Zwei Tage später kam die Antwort (sogar die eines echten Menschen - ich war beinahe gerührt!), dass man sich den Host angesehen hätte, und keine TCP-Verbindungen mehr zum fraglichen IRC-Server bestünden. Ich hoffe für die Betreiber, dass dies immer noch zutrifft.
Die verwundbare Wordpress-Installation auf dem Webserver wurde inzwischen gesundgepatcht, und weitere Einbrüche sind - nach gegenwärtigem Kenntnisstand - vorerst nicht zu erwarten. Das Botnetz, das maliciousUser hätte aufbauen wollen, existiert aber weiterhin, zumindest in Bruchteilen. Alle paar Tage schaue ich kurz vorbei, schlüpfe in den Wolfspelz von maliciousUser und kümmere mich um meine Schäfchen - ich schalte sie also ab und benachrichtige jene, die nachhaltig etwas gegen ihren Befall tun können. Vielleicht laufe ich so ja auch maliciousUser einmal über den Weg. Ich wäre gespannt, was er in unserem Pläuschchen zu erzählen hätte!
direkter Link ▲© 2007-2020 Johannes Truschnigg | valid xhmtl & css