Ice IX – gar nicht cool

Vergangene Woche entdeckte mein Kollege Jorge Mieres den Steuerungsserver eines Botnetzes, das auf dem Schadprogramm Ice IX basiert. Wie in verschiedenen Foren angekündigt, handelt es sich bei Ice IX um einen Bot, der auf der Grundlage des im Mai dieses Jahres frei zugänglich gemachten Quellcodes von ZeuS 2.0.8.9 entwickelt wurde. Wie der Autor des neuen Bots bekräftigte, wurden in dem Programm bedeutende Veränderungen vorgenommen, die insbesondere Cyberkriminelle interessieren sollten, die den Anwendern ihr Geld mit Hilfe von Bank-Trojanern stehlen.


Abb. 1. Beschreibung des Bots

In der oben dargestellten Beschreibung des neuen Programms liegt der Schwerpunkt eindeutig auf den Verbesserungen, die angeblich im Quellcode von ZeuS umgesetzt wurden. Darunter: Umgehung von Firewalls, Umgehung der proaktiven Erkennung durch Antiviren-Programme, Schutz vor Beobachtung durch Tracker (gemeint ist natürlich ZeuS Tracker https://zeustracker.abuse.ch, der den Cyberkriminellen nachhaltig die Laune verdirbt). Der Autor verlangt 600 Dollar für eine Version des Bots mit festgeschriebener Adresse, mit der sich der Bot nach einer Infektion in jedem Fall verbindet (das heißt also, die Adresse des Steuerungszentrums), und 1800 Dollar für eine Version, die nicht fest an diese Adresse gebunden ist. Leider ist es noch nicht gelungen, ein Sample der erweiterten Version von Ice IX zu detektieren – möglicherweise hat es bisher niemand gekauft. Höchstwahrscheinlich wurde in dieser Version ein Mechanismus umgesetzt, der dem in ZeuS, ab Version 2.1 verwendeten äußerst ähnlich ist. In ZeuS funktionierte es folgendermaßen: Der Bot enthält nur einen gewissen Schlüssel — eine Zahl, aus der – ebenso wie aus dem aktuellen Datum – jeden Tag 1020 Domainnamen generiert werden, die der Bot der Reihe nach durchgeht und so versucht, in der Liste sein Steuerungszentrum zu finden.

Der Bot-Constructor der Basis-Sammlung wurde allerdings schon von irgendjemandem ausprobiert. Diese Samples wurden hinsichtlich der Unterschiede zu den Original-ZeuS-Samples analysiert, auf deren Grundlage der Bot Ice IX entwickelt wurde.

Ich möchte gleich einräumen, dass ich mehr erwartet habe. Bei einer so viel versprechenden Annonce sollte der Autor zumindest im Diskussionsthread über den grünen Klee gelobt werden: Die Umgehung des proaktiven Schutzes ist nicht ohne, das ist zweifellos ein neuer Bot, ein verbesserter ZeuS… Doch bei näherer Betrachtung erweist sich das alles als Schwindel. Der Funktionalität des öffentlich zugänglichen ZeuS 2.0.8.9 wurden keine bahnbrechenden Neuerungen hinzugefügt!

Die folgenden Unterschiede konnten wir feststellen:

1). ZeuS findet die in einem infizierten System gespeicherten Daten von E-Mail-Accounts des Anwenders. Die gefundenen Daten sendet der Bot an den Botnetz-Verwalter, so dass der Cyberkriminelle nun Zugriff auf die E-Mail-Postfächer der Nutzer eines infizierten Computers hat. Doch in den Original-Quellcodes von ZeuS war der Codeabschnitt, der für die Suche und Bearbeitung der E-Mail-Daten verantwortlich ist, kommentiert. Der Autor von Ice IX hat diesen Code einfach entkommentiert, so dass die entsprechenden Module in seinem Bot auftauchten, die in den Samples von ZeuS 2.0.8.9. fehlten.

2). Der Bot ZeuS 2.0.8.9 kann mit den folgenden Argumenten gestartet werden: -f, -n, -v, -i. Ich möchte mich nicht mit einer Beschreibung ihrer Bedeutungen aufhalten, sondern nur kurz auf Schlüssel –I eingehen: Wird das Sample ZeuS 2.0.8.9 mit diesem Schlüssel gestartet, öffnet sich ein Fenster mit gewissen Informationen zu dem Bot:


Abb. 2: Informationsfenster von ZeuS 2.0.8.9

Der Autor von Ice IX hat also einfach die Bearbeitung dieses Schlüssels aus dem Code entfernt, und dementsprechend unterstützt das Sample Ice IX dieses Argument nicht.

3). Zudem wurde eine veränderte Funktion registriert, die mit dem Lesen der Daten aus der Registry zu tun hat. Es besteht die geringe Wahrscheinlichkeit, dass es sich dabei um die „Neuheit“ handelt, die auf die Umgehung des proaktiven Schutzes von Antiviren-Programmen abzielt. Doch diese Änderung kann ebenso gut das Ergebnis einer Optimierung des Compilers sein, der die Codes des Bots unter Berücksichtigung auch unbedeutender Veränderungen in Ice IX ein wenig anders kompilierte. Im Code von ZeuS 2.0.8.9 enthält die Funktion zum Lesen der Daten aus der Registry alle API-Funktionen für diese Aufgabe, d.h. die Funktionen RegOpenKeyEx, RegQueryValueEx, RegCloseKey:


Abb. 3: Funktion Lesen aus der Registry, ZeuS

Ist es erforderlich, irgendeinen Wert aus der Registry zu lesen, so geschieht das folgendermaßen:


Abb. 3a: Aufruf der Funktion Lesen aus der Registry, ZeuS

Im Sample von Ice IX wurden dagegen an den Orten, an denen oben beschriebene Funktion aufgerufen wurde, einige Veränderungen vorgenommen. Aus der Funktion Lesen von Daten aus der Registry wurde die Funktion RegOpenKeyEx entfernt:


Abb. 4: Funktion Lesen aus der Registry, Ice IX

Folglich wurde dort, wo die Werte aus der Registry gelesen werden mussten, vor dem Aufruf der Funktion Lesen solcher Daten die API-Funktion RegOpenKeyEx zum Öffnen des Registerschlüssels aufgerufen (z.B. HKEY_CURRENT_USER oder HKEY_LOCAL_MACHINE):


Abb. 4a: Aufruf der Funktion Lesen aus der Registry, Ice IX

Ich nehme an, dass irgendein Antivirus ZeuS nach der beschriebenen Funktion Lesen aus der Registry detektiert. Höchstwahrscheinlich ist diese grundlegende Funktion in allen ZeuS-Samples vorhanden, unabhängig von der Version, und möglicherweise identifiziert ihr Code diese Familie eindeutig. Warum auch nicht? Dann würde eine Veränderung dieser Funktion (wie z.B. das Tragen von RegOpenKeyEx über ihre Grenzen hinaus) es ermöglichen die auf dieser Funktion basierende Detektion auszuschalten.

Mit allen Antiviren-Produkten habe ich die Ice IX-Samples nicht getestet, daher kann ich auch nicht sagen, ob irgendein Produkt auf Grund dieser Veränderung den Bot nicht mehr erkennt. Ich habe das Sample ausschließlich auf unserem Produkt KIS 2012 überprüft — mit alten Datenbanken aus dem Juni, als Ice IX noch gar nicht bekannt war. KIS 2012 erkannte bei der Codeausführung des Bots eine gefährliche Operation und stoppte die Ausführung des Programms. Das ist nicht weiter überraschend, denn für ZeuS mit seiner langen Geschichte und seiner umfassenden Funktionalität findet sich weder in KIS oder KAV ein Kriterium, nach dem unsere Produkte den Schadcode dieser Familie erkennen.

Und nun kommen wir zu den wichtigsten Veränderungen, durch die sich Ice IX und ZeuS 2.0.8.9 doch irgendwie unterscheiden.

3). In der Konfigurationsdatei von ZeuS gibt es einen Abschnitt mit der Bezeichnung “Web Filters”, in dem der Botmaster festlegt, wie der Bot zu reagieren hat, wenn der Anwender eines infizierten Computers die eine oder andere Site besucht. Zu diesem Zweck werden Sonderzeichen verwendet: “!”, “@”, “-“, “^”. Nehmen wir einmal das Zeichen “@”. Dieses Zeichen wird vor eine URL gestellt (zum Beispiel: @*/login.osmp.ru/*) und auf diese Weise wird dem Bot mitgeteilt, dass er – sollte der Anwender die so getarnte Adresse besuchen – einen Screenshot macht, sobald der User mit der rechten Maustaste klickt, um dieses Bild danach an seinen Master zu senden. Das ist notwendig, damit der Online-Kriminelle die eingegebenen Daten auf der Website wiederherstellen kann, wenn für die Eingabe eine virtuelle Tastatur verwendet wurde. Die anderen Zeichen zeigen dem Bot ebenfalls ein bestimmtes Verhalten an. Die einzige Veränderung, die der Autor von Ice IX vorgenommen hat, besteht darin, dass er die Sonderzeichen durch die Buchstaben “N”, “S”, “C” und “B” respektive ersetzt hat.

4). Der letzte Unterschied ist eine leicht modifizierte Methode, mit der der Bot die Konfigurationsdatei lädt. Im Code von ZeuS ist die URL zur Konfigurationsdatei enthalten, über die jeder Interessierte diese Datei herunterladen kann, zum Beispiel, http://www.example.com/files/config.bin. Der Autor von Ice IX geht davon aus, dass diese Verfügbarkeit der Konfigurationsdateien die Wurzel des Tracker-Problems ist. Und so versucht er dieses Problem zu lösen: Es ist nicht mehr möglich, die Konfigurationsdatei einfach über die URL herunterzuladen. Zu diesem Zweck muss man nun vielmehr an eine bestimmte Adresse (ebenfalls eine URL, die im Code des Bots „geschützt“ ist – an derselben Stelle wie bei ZeuS 2.0.8.9) eine speziell formulierte POST-Anfrage senden. Bei den versendeten Daten handelt es sich um einige Parameter: «id=&hash=», beispielsweise:

id=TEST_WIN_XP_B5DF77116522DF69&hash=DC0D2CAB39D49FC3D5E467501A2682C5

id – ist der Bezeichner des Bots, der nach demselben Algorithmus berechnet wird wie in ZeuS 2.0.8.9 (er wird in ZeuS bei der direkten „Kommunikation“ des Bots mit dem Steuerungszentrum verwendet). Bei dem Bezeichner handelt es sich um den Namen des Computers plus einer unikalen 16-stelligen Zahl, die aus sechzehn Zeichen besteht, die ebenso willkürlich sein können wie der Name des Computers. Dieser Bezeichner wird mit dem Algorithmus RC4 verschlüsselt (der allgemein in ZeuS für die Codierung der Daten verwendet wird) mit einer S-Box, die ebenfalls in den Körper des Bots integriert ist. Aus den verschlüsselten Daten wird die Prüfsumme entnommen – MD5. Der erhaltene Wert wird ebenfalls als Hash-Variable versendet. Berücksichtigt man, dass der Bezeichner des Bots willkürlich sein kann (Mindestanforderung ist das Format COMPUTERNAME_16CHARSHEXNUMBER), so ist zum Erhalt der Konfigurationsdatei lediglich die S-Box nötig — um den Bezeichner des Bots zu verschlüsseln. Doch Augenblick mal! Die Konfigurationsdatei ist doch bereits mit eben dem RC4 mit eben der S-Box verschlüsselt. Ohne diese S-Box ist die Konfigurationsdatei an sich nutzlos, eine sinnlose Aneinanderreihung von Bytes. Das Wertvollste steckt im Innern.

Unter dem Strich bleibt:

Wodurch, fragt man sich nun, wird den Trackern das Leben schwer gemacht? Die Antwort liegt auf der Hand – durch praktisch gar nichts. Vielleicht, dass es eine halbe Stunde braucht, um das Sample zu starten, Dump zu entfernen und die Veränderungen im bekannten Code hervorzuheben. Und das nur in dem Fall, wenn der Download von Konfigurationsdateien verschiedener Bots am Fließband analysiert werden soll. Aber es geht auch einfacher – man ziehe den Traffic von einem infizierten Computer ab und kopiere die Parameter der POST-Anfrage – eine Sache von Minuten. Und wie wird man belohnt!

Mich erinnert das Ganze an einen Spruch, der zwar aus dem Sport stammt, was aber überhaupt keine Rolle spielt: Um die Olympiade zu gewinnen, muss man einmal 9 Meter weit springen – und nicht neun Mal einen Meter weit. So ist es auch hier – was macht es für einen Unterschied, wie oft wie viele Werte mit ein und demselben Algorithmus mit ein und demselben Schlüssel chiffriert werden – die Quelldaten sind und bleiben gleich, und eine vielfache Wiederholung des Verschlüsselungsprozesses führt nicht zu einer tatsächlichen Verkomplizierung des Algorithmus. Aber allem nach zu urteilen hat sich diese Aufgabe auch nie wirklich gestellt, da es sich hier schlicht und einfach um Betrug handelt. Irgendjemand wollte das schnelle Geld machen und unter vorgehaltener Hand eine Funktionalität verkaufen, die frei verfügbar und völlig kostenlos zu haben ist.

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.