Dipl.-Inform. Carsten Eilers

Sie erinnern sich sicher noch daran: Zuerst hat der Iran gemeldet, dass er von einem Schädling mit Namen Flame angegriffen wurde. Dann haben sich die Medien auf Flame gestürzt und etwas unberechtigte Panik gemacht. Diesen Riesen-Schädling hatten die Antiviren-Hersteller lange übersehen, und das weil er so gross ist - Viren und Co. haben gefälligst klein und unauffällig zu sein.

Zumindest anfangs war Flame nichts Besonderes. Bis dann raus kam, wie er sich in lokalen Netzen verbreitete: Über eine 0-Day-Schwachstelle Windows Update-Funktion. Wie er in die Netze überhaupt rein kam, ist übrigens immer noch unbekannt. Merkwürdig, oder?

Flame lässt sich durch Plugins erweitern und sammelt alle möglichen Daten. Klarer Fall von "Jäger und Sammler", kann man ja mal gebrauchen, also wird es eingelagert. Klingt wie ein digitaler Messi? Nein nein, das ist typisches Geheimdienstverfahren: Sammeln, horten - und wenn es gebraucht wird, schnell schreddern.

Überwiegend trieb der Schädling sein Unwesen im Nahen Osten, denn Flame wurde von den USA und Israel entwickelt, um die Fähigkeiten des Irans zum Entwickeln einer Atombombe zu verlangsamen.

Im Oktober wurde dann eine kleiner Ausgabe von Flame entdeckt: miniFlame.

Um die kleine Flamme ist es ruhig geworden, dafür mach Flame selbst wieder von sich reden: Zum einen vermutet man bei Kaspersky, dass es weitere, bisher unbekannte Module für Flame gibt. Zum Beispiel eins mit den gleichen Funktionen wie Stuxnet. Und davon würde man wohl nie etwas erfahren. Das erste halte ich für ziemlich unwahrscheinlich. Warum hätte man dann noch Flame entwickeln sollen? Was ich mir vorstellen könnte, wäre eine andere Verbindung: Stuxnets Schadfunktion war anfangs als Flame-Modul vorgesehen, dann hat man sich für einen neuen, kleineren Schädling als Träger entschieden.

Generell halte ich das "Es gibt vielleicht noch mehr Module, die wir nie finden werden" für "Marketinggeschwätz". Warum? Weil es von Kaspersky kommt und vom Kaspersky-Ableger ThreatPost verbreitet wird. Wir erinnern uns: Eugene Kaspersky fordert seit langem mehr staatliche Kontrollen über das Internet, die ITU streckt die Finger danach aus, und die entscheidende ITU-Konferenz ist in Kürze. Ein Schelm, der Böses dabei denkt?

Außer den Vermutungen über weitere Flame-Module gibt es einen Bericht (französische Quelle und sehr mangelhafte deutsche Google-Übersetzung) über einen Cyberangriff auf den Pariser Elyseepalast, bei dem ein Flame ähnelnder Schädling eingesetzt wurde. Was sofort den Verdacht auf die USA lenkte.

Wieso eigentlich nicht auf Israel? Immerhin wurden die ganzen Cyberwar-Schädlinge von beiden Staaten gemeinsam entwickelt, da läge doch der Verdacht nahe, dass auch der in Frankreich gefundene Flame-Abkömmling ein Gemeinschaftsprojekt ist. Und wenn nur ein Staat dafür verantwortlich ist, könnte es Israel mit der gleichen Wahrscheinlichkeit sein wie die USA.

Eine Mitarbeiterin der US-Regierung wollte den Vorwurf weder bestätigen noch abstreiten. Was verständlich ist, immerhin haben die USA nach anfänglichen Leugnen ja auch die Entwicklung von Stuxnet zugeben. Dass sich da niemand aus dem Fenster lehnen und später als Lügner dastehen will, ist doch wohl zu erwarten. Außerdem hat man ja vielleicht auch die falsche Regierung gefragt. Was sagt denn die israelische dazu?

Wurm-Angriff im Nahen Osten

Symantec berichtet über einen neuen Wurm, der sich über USB-Sticks und Netzwerkfreigaben verbreitet und vor allem den Iran unsicher macht. Die Schadfunktion des in Delphi geschriebenen W32.Narilam hat es in sich:

Der Wurm sucht nach über OLEDB (Object Linking and Embedding Database) zugängliche SQL-Datenbanken und löscht oder überschreibt darin bestimmte Felder. Der Wurm reagiert dabei auf Schlüsselwörter wie "Holiday", "Holiday_1" und "Holiday_2", "buyername" und außerdem verschiedene persische und arabische Wörter. Zwar ist die Wahrscheinlichkeit, im deutschsprachigen Raum Opfer dieses Wurm zu werden, sehr gering. Trotzdem sollten Sie mal prüfen, ob es ggf. Backups Ihrer SQL-Datenbanken gibt. Denn die sind die einzige Möglichkeit, nach einem Angriff des Wurm den Betrieb aufrecht zu erhalten. Eine Wiederherstellung der gelöschten bzw. geänderten Daten dürfte i.A. ohne Backup ziemlich aussichtslos sein.

Exploit-Kit spezialisiert sich auf Java

Das es im BlackHole Exploit-Kit einen Exploit für eine gerade behobene Schwachstelle in Java gibt, hatte ich bereits vorige Woche berichtet. Anscheinend spezialisiert sich das chinesische Exploit-Kit Gong Da / Gondad zunehmend auf Java-Exploits. Auch der in BlackHole enthaltene Exploit hat seinen Weg in dieses Exploit-Kit gefunden, während früher verwendete Exploits für andere Software nicht mehr enthalten sind. Allerdings wurde seitdem auch ein Exploit für den Flash Player hinzugefügt.

Auf jeden Fall zeigt das mal wieder, wie gefährlich es ist, Java nicht regelmäßig auf den neuesten Stand zu bringen. Kaum hat Oracle Schwachstellen gepatcht, da sind die Patches auch schon analysiert und Exploits machen die Runde.

Rootkit verbreitet Drive-by-Infektionen

Es gibt einen neuen Trick zur Verbreitung von Drive-by-Infektionen: Auf der Mailingliste Full-Disclosure wurde ein Linux Rootkit veröffentlicht, das auf einem kompromittierten Webserver gefunden wurde. Laut Georg Wicherski von CrowdStrike wurde das Rootkit für die Kernel-Version 2.6.32-5 von Debian Squeeze entwickelt, laut Marta Janus von Kaspersky handelt es sich um ein Rootkit für die 64-Bit-Version 2.6.32-5-amd64, die aktuellste für Debian Squeeze. Das Rootkit enthält außer den üblichen Rootkit-Funktionen zum Verbergen des Schadcodes auch Code zum Zugriff auf TCP-Verbindungen, über den dann ein iframe in bestimmten HTTP-Traffic eingefügt wird.

Mir war dieser Ansatz bisher unbekannt, laut einem Kommentar zum CrowdStrike-Text wurde entsprechender Code vom Kommentator bereits 2008 gefunden und auf Securityfocus veröffentlicht. Besonders weit verbreitet ist dieser Ansatz jedenfalls nicht, was sich vermutlich damit erklären lässt, dass ein Rootkit ja erstmal irgendwie auf dem Webserver installiert werden muss. Dazu muss sich der Angreifer erst einmal allgemein Zugriff und danach root-Rechte verschaffen. Da die Angriffe auf Webserver meist über Schwachstellen in den darauf gehosteten Webanwendungen erfolgen, dürfte es im Allgemeine deutlich einfacher sein, die Webanwendung für die Verbreitung der Drive-by-Infektion zu präparieren als weiter ins System vorzustoßen. Damit spart sich der Angreifer die Mühe, eine Schwachstelle zum Erlangen von root-Rechten zu finden und das Rootkit zu installieren. Warum kompliziert, wenn es auch einfach geht?

Übrigens fehlt die interessanteste Information: Wie ist das Rootkit auf den Webserver gelangt? Wie hat der Angreifer sich erst Zugriff und danach root-Rechte verschafft? Gibt es eine 0-Day-Schwachstelle in Debian Squeeze? Laut Georg Wicherski ist der Rootkit-Entwickler mit dieser Technik nicht sehr vertraut. Wenn das eine Eigenentwicklung des Angreifers ist, dürfte der kaum besonders ausgefeilte Exploits entwickelt haben. Wie ist das Rootkit also da hin gekommen, wo es gefunden wurde?

Carsten Eilers