Alle Bedrohungen

Viren

Hacker

Spam

Alle Seiten    Viren
  
Virus Enzyklopädie
Alarme
Analysen
Nachrichten
Glossar
Weblog

 
Kalender

<< 2014  
Jan Feb Mär
Apr Mai Jun
Jul Aug Sep
Okt Nov Dez
Most Popular Analysis



Kaspersky Security Bulletin 2014/2015 – Statistik für das Jahr 2014



Kaspersky Security Bulletin 2014/2015. Ein Blick in die APT-Kristallkugel



Kaspersky Security Bulletin 2014. Entwicklung der IT-Bedrohungen



Kaspersky Security Bulletin 2014/2015. Vorschau auf 2015



Entwicklung der IT-Bedrohungen im 3. Quartal 2014
 
Für potentielle Autoren

Möchten Sie einer unserer Autoren werden und Ihre Texte auf der Viruslist.com lesen? Setzen Sie sich mit uns in Verbindung!

 

  Home / Analysen

Stuxnet/Duqu: Evolution der Treiber

10.01.2012   |   Ihr Kommentar

Alexander Gostev
Senior Virenanalyst, Kaspersky Lab
Igor Soumenkov

Einleitung

Bereits seit zwei Monaten dauern unsere Untersuchungen zum Trojaner Duqu an und behandeln die Geschichte seines Auftauchens, sein Verbreitungsgebiet sowie sein Funktionsschema. Trotz der riesigen Fülle von Informationen, von denen wir einen Großteil noch nicht veröffentlich haben, konnten wir bisher noch keine Antwort auf die wichtigste Frage finden, die da lautet: Wer hat Duqu entwickelt?

Daneben stellen sich auch noch weitere Fragen, die alle mit der Entwicklung des Trojaners zusammenhängen – genauer gesagt mit der Erstellung der Plattform, auf der dann Duqu und Stuxnet umgesetzt wurden.

Die Architektur der Plattform von Duqu und Stuxnet ist identisch. Es handelt sich um eine Treiberdatei, die den Download des Hauptmoduls übernimmt, das als verschlüsselte Bibliothek vorliegt. Dabei gibt es eine einzelne Konfigurationsdatei für den gesamten Schadkomplex und einen speziellen Block im Systemregister, der den Speicherort des herunterzuladenden Moduls bestimmt.


Schematischer Aufbau der Plattform-Architektur

Diese Plattform könnte man zum Beispiel „Tilded“ nennen – aufgrund der merkwürdigen Neigung der Autoren, Dateinamen zu verwenden, die mit „~d“ beginnen.

Wir sind der Meinung, dass Duqu und Stuxnet parallele Projekte waren, die von ein und demselben Team betreut wurden.

Eine Reihe der von uns aufgedeckten Fakten weist auf die mögliche Existenz von mindestens einem weiteren Spionagemodul hin, das in den Jahren 2007 und 2008 auf Basis eben dieser Plattform entwickelt wurde, sowie auf die Existenz einiger anderer Programme unbekannter Funktionalität aus der Zeit zwischen 2008 und 2010.

Diese Fakten verändern die bestehende „offizielle“ Version der Stuxnet-Geschichte wesentlich. Wir versuchen mit diesem Artikel Licht ins Dunkel zu bringen, doch zunächst einmal möchten wir noch einmal kurz die Geschichte selbst in Erinnerung rufen.

Die „offizielle“ Stuxnet-Geschichte

Wir beginnen mit einer Frage: Wie viele Treiberdateien von Stuxnet sind bekannt? Bis zum heutigen Tag lautete die korrekte Antwort vier. Hier die Informationen dazu:


Dateiname Größe (Byte) Kompilierungsdatum Wo und wann angewendet Digitale Signatur /Signaturdatum
Mrxcls.sys 19840 01.01.2009 Stuxnet (22.06.2009) Keine
Mrxcls.sys 26616 01.01.2009 Stuxnet (01.03.2010/14.04.2010) Realtek, 25.01.2010
Mrxnet.sys 17400 25.01.2010 Stuxnet (01.03.2010/14.04.2010) Realtek, 25.01.2010
Jmidebs.sys 25552 14.07.2010 Vermutlich Stuxnet Jmicron, unbekannt

Die erste Modifikation des Wurms Stuxnet, die im Jahr 2009 entwickelt wurde, verwendete mit mrxcls.sys nur eine einzige Treiberdatei, die keine digitale Signatur enthielt.

Im Jahr 2010 entwickelten die Autoren den zweiten Treiber mrxnet.sys, um mit seiner Hilfe die Wurmdateien zu verbergen. Dazu statteten sie mrxnet.sys und den Treiber mrxcls.sys mit einem digitalen Zertifikat der Firma Realtek aus. Der Treiber mrxnet.sys ist im Rahmen unserer Geschichte nicht von großer Bedeutung, da er ein gesondertes Modul ist und nicht zur allgemeinen Architektur der Plattform gehört.

Am 17. Juli 2010 entdeckte das Unternehmen Eset einen weiteren Treiber in „freier Wildbahn“, und zwar jmidebs.sys, der dem bereits bekannten Treiber mrxcls.sys überaus ähnlich ist, allerdings erst drei Tage vor seiner Entdeckung erstellt wurde. Dieser Treiber wurde mit einem neuen Zertifikat signiert, das dieses Mal von der Firma Jmicron stammte.

Bis vor kurzem war die Bedeutung dieser Datei noch unbekannt, doch gemäß der vorherrschenden Meinung gehörte dieser Treiber zu Stuxnet. Einer Lesart der Geschichte zufolge wurde er möglicherweise über die Steuerzentrale (C&C) von Stuxnet verbreitet, um so die alte Version mit dem Realtek-Zertifikat gegen die neue auszutauschen. Auf diese Weise versuchten die Autoren des Wurms angeblich, seine Erkennung durch Antiviren-Programme zu umgehen oder sie benutzten das neue Zertifikat anstelle des bereits gesperrten.

Diese Version hat sich leider nicht bestätigt – Jmidebs.sys verschwand und erschien nie wieder. Irgendeine neue Stuxnet-Variante, die diese Datei installieren könnte, wurde ebenfalls nicht entdeckt.

So lautet die „offizielle“ Geschichte von Stuxnet. Genauer gesagt: So lautete sie. Wie bereits erwähnt, sind wir im Rahmen unserer Untersuchung auf neue Fakten gestoßen, von denen im Folgenden die Rede sein wird.

Bisher unbekannte Treiber

rtniczw.sys

Im Zuge der Analyse eines Vorfalls mit Duqu, der bei einem Anwender im Iran aufgetreten war, stießen wir auf etwas Neues – und das könnte die gesamte Geschichte des Wurms Stuxnet ins Wanken bringen.

Auf dem Computer des betroffenen Anwenders stieß unsere Sicherheits-Software auf eine merkwürdige Datei und erkannte sie als „Rootkit.Win32.Stuxnet.a“. Diese Datei hätte mit der bekannten und oben beschriebenen Datei mrxcls.sys übereinstimmen sollen, doch die Kontrollsumme und der Dateiname wichen voneinander ab!

Der Name der neuen Datei lautete rtniczw.sys, sie hatte eine Größe von 26.872 Byte und besaß den MD5-Hash 546C4BBEBF02A1604EB2CAAAD4974DE0.

rtniczw.sys war ein wenig größer als die Datei mrxcls.sys, die mit einer digitalen Signatur von Realtek versehen ist. Das bedeutete, dass die Datei rtniczw.sys ebenfalls über eine digitale Signatur verfügt. Uns ist es gelungen, an eine Kopie dieser Datei zu kommen. Man kann sich vielleicht vorstellen, wie erstaunt wir waren, als sich herausstellte, dass in ihr dieselbe digitale Signatur von Realtek verwendet wird, wobei sich das Signaturdatum der Datei allerdings von dem Signaturdatum in mrxcls.sys unterscheidet: Die Datei rtniczw.sys wurde am 18. März 2010 signiert, mrxcls.sys dagegen am 25. Januar desselben Jahres.

 
Mrxcls.sys

 
Rtniczw.sys


Zudem arbeitet rtniczw.sys mit einem Schlüssel und einem Block des Systemregisters, die in Stuxnet nicht verwendet wurden. In Stuxnet wurden der Schlüssel „MRxCls“ und der Wert „Data“ verwendet, bei rtniczw.sys waren es hingegen der Schlüssel „rtniczw“ und der Wert „Config“.

Eine detaillierte Analyse des Codes von rtniczw.sys ergab keine anderen Unterschiede zu dem „Prototyp“ des Treibers: Es war derselbe Treiber mrxcls.sys, erstellt im selben Jahr, am selben Tag zur selben Stunde – am 1. Januar 2009.

Wir versuchten, mehr über andere Anwender in Erfahrung zu bringen, bei denen genau so eine Datei aufgetaucht war, aber wir fanden nicht einen einzigen! Auch über den Namen der Datei (rtniczw.sys) konnten wir nichts herausfinden, ebenso wenig wie über ihren MD5-Hash, den wir in verschiedene Suchsysteme eingaben. Diese Datei wurde nur ein einziges Mal gefunden – im Mai 2011 wurde sie aus China zur Überprüfung an VirusTotal geschickt.

Allem Anschein nach wurde das von uns untersuchte System im Iran Ende August 2011 befallen. Wichtig ist, dass wir dort keine Stuxnet-Infektion feststellen konnten – aus dem Stuxnet-Arsenal wurde nicht eine zusätzliche Datei gefunden. Dafür wurden Duqu-Dateien entdeckt.

Wir sind zu dem Schluss gekommen, dass es noch weitere Treiber-Dateien geben könnte, die dem „Prototyp“ mrxcls.sys ähneln und die nicht zu den bekannten Stuxnet-Varianten gehören.

rndismpc.sys

Bei einer Überprüfung unserer Virensammlung stießen wir auf eine weitere interessante Datei, die vor über einem Jahr bei uns gelandet ist. Die Datei trägt die Bezeichnung „rndismpc.sys“, mit einer Größe von 19.968 Byte und einem MD5-Hash von 9AEC6E10C5EE9C05BED93221544C783E.


Es handelte sich dabei um einen weiteren Treiber, dessen Funktionalität mrxcls.sys vollkommen gleicht, mit Ausnahme der folgenden Punkte:

  1. Rndismpc.sys arbeitet mit einem Schlüssel des Systemregisters, der sich sowohl von mrxcls als auch von rtniczw unterscheidet – dem Schlüssel „rndismpc“ mit dem Wert „Action“.
  2. Es wird ein von mrxcls/rtniczw abweichender Chiffrierungsschlüssel verwendet – 0x89CF98B1.
  3. Das Kompilierungsdatum der Datei ist der 20. Januar 2008, liegt also etwa ein Jahr vor dem Erstellungsdatum von mrxcls/rtniczw.

Die Datei rndismpc.sys wurde ebenfalls niemals irgendwo bei unseren Anwendern gefunden. Es ist unbekannt, welches Schadprogramm sie installiert hat und mit welchem Hauptmodul sie arbeiten sollte.

Das Verbindungsglied: mrxcls.sys —> jmidebs.sys —> Duqu-Treiber

Fügt man den erhaltenen Daten die bereits bekannten Informationen über die in Duqu verwendeten Treiber hinzu (siehe http://www.securelist.com/en/blog/208193182/The_Mystery_of_Duqu_Part_One, http://www.securelist.com/en/blog/208193197/The_Mystery_of_Duqu_Part_Two), ergibt sich daraus folgende Tabelle:

Name Größe Kompilierungsdatum Hauptmodul Chiffrierungsschlüssel Registerschlüssel Wert Gerätename
rndismpc.sys 19.968 20.01.2008 unbekannt 0x89CF98B1 rndismpc “Action” “rndismpc”
mrxcls.sys 19.84 01.01.2009 Stuxnet.a 0xAE240682 MRxCls “Data” “MRxClsDvX”
mrxcls.sys (signed) 26.616 01.01.2009 Stuxnet.b/.c 0xAE240682 MRxCls “Data” “MRxClsDvX”
rtniczw.sys (signed) 26.872 01.01.2009 unbekannt 0xAE240682 rtniczw “Config” “RealTekDev291”
jmidebs.sys (signed) 25.502 14.07.2010 unbekannt 0xAE240682 jmidebs “IDE” {3093983-109232-29291}
<name>.sys* unterschiedlich 03.11.2010 Duqu 0xAE240682 <name> “FILTER” {3093AAZ3-1092-2929-9391}
<name>.sys* unterschiedlich 17.10.2011 Duqu 0x20F546D3 <name> “FILTER” {624409B3-4CEF-41c0-8B81-7634279A41E5}

*die bekannten Duqu-Treiber verfügen über einzigartige Dateinamen, die sich je nach Variante unterscheiden. Ihre Funktionalität ist dabei völlig identisch.

Die Analyse zeigt, dass jmidebs.sys das Verbindungsglied zwischen mrxcls.sys und den Treibern ist, die danach in Duqu verwendet wurden.

Der Code der Treiber mrxcls und jmidebs stimmt im Wesentlichen überein. Einige Unterschiede könnten mit unterschiedlichen Einstellungen des Compilers und minimalen Veränderungen im Quellcode zusammenhängen, wobei der Sinn des Codes unverändert bleibt.

In einigen Funktionen gibt es allerdings deutliche Unterschiede:

  1. Die Dienstfunktion, die die Adresse der API-Funktion empfängt. mrxcls verwendet für diese Funktion MmGetSystemRoutineAddress und benutzt dementsprechend die Textnamen der empfangenen Adressen der API-Funktionen. jmidebs ruft eigene Funktionen zum Empfang der API-Adressen nach Hash-Summen ihrer Namen auf. Genau solche Funktionen werden in den Duqu-Treibern verwendet, dabei ist die Liste der Hash-Funktionen doppelt so lang.
  2. Die Funktion, die das Stub-Modul zum Einschleusen der PNF-DLL in die Prozesse erstellt. mrxcls verwendet ein Stub-Modul mit einer Gesamtgröße von 6.332 Byte. jmidebs und die Duqu-Treiber verwenden Stub-Module mit einer Gesamtgröße von 7.061 Byte. Der Code der Stub-Module ist in allen diesen Treibern identisch, allerdings unterscheiden sich ihre Kompilierungsdaten.
  Mrxcls (Stuxnet) jmidebs Duqu
API RtlGetVersion, KeAreAllApcsDisabled, werden mit Hilfe des Aufrufs von MmGetSystemRoutineAddress erhalten RtlGetVersion, KeAreAllApcsDisabled, PsGetProcessSessionId, PsGetProcessPeb, werden mit Hilfe der eigenen Funktion erhalten Analog zu jmidebs, weitere 4 Funktionen hinzugefügt
Injected EXE 6.332 Jan 01 22:53:23 2009 7.061 Jul 14 13:05:31 2010 7.061 Unterschiedliche Kompilierungsdaten

Evolutionsschema der Treiber

Die Verbindungen zwischen den bekannten Treibern haben wir in unten stehendem Schema aufgeschlüsselt, in dem deren Evolution und die wichtigsten Entwicklungsschritte leicht nachzuvollziehen sind.

 
Evolutionsschema der Treiber

rndismpc.sys, rtniczw.sys und jmidebs.sys

Wie man sieht, ist für drei der Treiber – rndismpc.sys, rtniczw.sys und jmidebs.sys – das wesentliche Schadprogramm, mit dem sie interagierten, nicht bekannt. Die logische Frage lautet hier: Wurden sie in Stuxnet eingesetzt? Die unserer Meinung nach richtige Antwort ist nein.

Erstens: Wären sie in Stuxnet verwendet worden, wären sie sehr viel weiter verbreitet gewesen und mehr als die von uns aufgedeckten einzelnen Fälle wären bekannt geworden. Zweitens: Es wurde keine Variante von Stuxnet entdeckt, die mit diesen Treibern funktioniert hätte.

Die Datei rtniczw.sys wurde am 18. März 2010 entdeckt, doch am 14. April 2010 entwickelten die Stuxnet-Autoren eine neue Variante des Wurms, in dem der „Prototyp“ mrxcls.sys verwendet wurde. Offensichtlich war rtniczw.sys für etwas anderes bestimmt. Dasselbe gilt auch für jmidebs.sys. Wir sind der Meinung, dass man diese drei Treiber aus der Stuxnet-Historie streichen muss – sie haben nur indirekt damit zu tun.

Und noch eine Frage drängt sich auf – könnten diese Treiber auch für die Arbeit mit Duqu genutzt werden?

Hier gibt es keine eindeutige Antwort. Ungeachtet dessen, dass alle bekannten Duqu-Varianten in den Zeitraum von November 2010 bis Oktober 2011 eingeordnet werden können, meinen wir, dass noch frühere Varianten des Spionage-Trojaners existieren, die zum Informationsdiebstahl entwickelt wurden. Diese drei Treiber könnten zweifellos entweder in früheren Duqu-Varianten eingesetzt worden sein oder für die Arbeit mit irgendwelchen anderen Trojanern, die auch auf der Plattform Stuxnet/Duqu basieren. Am wahrscheinlichsten ist, dass diese Trojaner, ebenso wie Duqu, zur Durchführung zielgerichteter Attacken eingesetzt wurden – sowohl bis zum Auftauchen von Stuxnet (spätestens im Jahr 2008) als auch während seiner „Existenzdauer“ und nach Schließung seines C&C. Das waren parallele Projekte und Stuxnet basierte auf dem bereits vorhandenen Erfahrungsschatz und dem entwickelten Programmcode, wobei er nicht das einzige Projekt seiner Autoren war.

Entwicklungsprozess der Treiber

Stellen wir uns einmal vor, wie der Entwicklungsprozess der Treiber aussehen könnte. Mehrmals pro Jahr kompilieren ihre Autoren eine neue Version der Treiber-Datei, wobei sie einen Datei-Prototyp erhalten. Seine Hauptaufgabe besteht im Download des Hauptmoduls, das separat entwickelt wird. Das kann Stuxnet sein oder Duqu oder irgendetwas anderes.

Wenn ein Treiber für das neue Hauptmodul benötigt wird, ändern die Autoren mit Hilfe eines speziellen Programms die entsprechenden Informationen in der Datei des Treiber-Prototyps – Name, Dienstinformationen sowie den Registerschlüssel und seinen Wert.

Wichtig dabei ist, dass sie die fertige Datei ändern und sie nicht erneut kompilieren. Auf diese Weise können sie so viele unterschiedliche Treiberdateien erstellen wie sie wollen, die alle über ein und dieselbe Funktionalität und dasselbe Erstellungsdatum verfügen.

Je nach Aufgabe des Trojaners und nach Art des Objekts, gegen das er eingesetzt werden soll, können einige Treiber-Dateien daraufhin mit legalen digitalen Zertifikaten signiert werden, deren Herkunft bisher noch nicht bekannt ist.

Fazit

Ausgehend von den von Kaspersky Lab gesammelten Daten kann man mit an Sicherheit grenzender Wahrscheinlichkeit behaupten, dass die Plattform „Tilded“ spätestens Ende 2007/Anfang 2008 entwickelt wurde und dass die entscheidenden Veränderungen im Sommer/Herbst 2010 vorgenommen wurden. Diese Veränderungen wurden durch die Entwicklung des Codes und die Notwendigkeit hervorgerufen, die Entdeckung durch AV-Programme zu umgehen. Zwischen 2007 und 2011 liefen mehrere Projekte zur Entwicklung von Programmen auf der Basis der Plattform „Tilded“, von denen Stuxnet und Duqu bekannt sind. Die übrigen Projekte sind bis heute unbekannt. Die Plattform wird weiterentwickelt, doch erneut müssen aufgrund der Entdeckung von Duqu Änderungen vorgenommen werden.

Quelle:
Kaspersky Lab
 

Copyright © 1996 - 2014
Kaspersky Lab
Industry Leading Antivirus Software
Alle Rechte vorbehalten
 

Email: webmaster@kaspersky.com
Datenschutzbestimmungen