Stuxnet Analysen

01.06.2012

Update 01.06.2012
Obama soll Stuxnet-Einsatz angeordnet haben

Washington-Korrespondent der New York Times David E. Sanger hat in seinem Buch „Confront and Conceal“ unter anderem die Geschichte von Stuxnet enthüllt.

Danach soll der unter heutigen Namen bekannte Stuxnet Wurm bereits unter George W. Bush entwickelt worden sein um mehr Informationen über das umstrittene iranische Atomprogramm zu erhalten. Damals nannte man das Programm noch „Olympic Games“.

Angeblich habe die USA in enger Zusammenarbeit mit Israel die Spionage-Schadsoftware entwickelt. Nach Fertigstellung wurde Stuxnet in die Anlage von Natanz über Spione und unwissende Mitarbeiter eingeschleust.

Bis zur Amtsübernahme von Obama soll angeblich kein Schaden entstanden sein, obwohl bereits die Iraner mit Mitarbeiterentlassungen und dem Abschalten von Anlagen auf den Angriff reagiert hatten.

Laut Sanger soll dann Obama die Fortführung des Stuxnet Programms angeordnet haben. Dabei war geplant, dass die Spionagesoftware die Anlagen im Iran nie verlassen sollte.  Durch einen Programmierfehler im Code von Stuxnet wurde dieser angeblich versehentlich über einen iranischen Ingenieur ins Internet verbreitet, wo er wie bekannt, einiges an Schaden angerichtet hat. Trotz der Popularität des nun analysierten Spionagetools soll Obama nach wie vor die Fortführung des Projekts angeordnet haben, um das Atomprogramm möglichst lange zu unterbrechen, bis entsprechende Sanktionen gegen den Iran Wirkung zeigen.

Für den Inhalt des Buches hat Sanger angeblich über 1,5 Jahre recherchiert und mit ehemaligen Insidern gesprochen haben.

Es bleibt interessant wie die USA auf das Buch, das nächste Woche veröffentlicht wird reagieren werden.
Interessant bleibt auch die Frage, ob nicht die USA demnächst mit der gleichen aber dann modifizierten Stuxnet Variante zum Spionageopfer werden. Wer kommt eigentlich für die den Schaden auf den Stuxnet weltweit verursacht hat?

In den letzten Tagen ist der Hype um die Stuxnet Bedrohung wieder verstärkt aufgeflammt. Das Info-Point-Security Team ist deshalb auf die Suche nach Analysen zur Stuxnet Problematik gegangen und vor allem bei den Weblogs des Symantec Security Reponse Teams fündig geworden. Im Folgenden finden Sie komprimiert einige sehr interessante Analysen (mit aktuellen Ergänzungen)  – einschliesslich Infektionswege wie auch Infektionsmethoden der industriellen Steuerungsrechner und PLC Systeme –  zur Stuxnet Attacke –

Generelle Beschreibung von W32.Stuxnet (von Jarrad Shearer)

• Risikostufe: 2 (gering für die Allgemeinheit – sehr speziell auf Industriebereich)
• Erstmalige Entdeckung: 13. Juli 2010
• Weitere verwendete Namen für diese Bedrohung: Troj/Stuxnet-A [Sophos], W32/Stuxnet-B [Sophos], W32.Temphid [Symantec], WORM_STUXNET.A [Trend], Win32/Stuxnet.B [Computer Associates], Trojan- Dropper:W32/Stuxnet [F-Secure], Stuxnet [McAfee], W32/Stuxnet.A [Norman]
• Malware-Art: Wurm
• Infektions-Dauer: Variiert
• Betroffene Betriebssysteme: Windows 98, Windows 95, Windows XP, Windows Me, Windows Vista, Windows NT, Windows Server 2003, Windows 2000
• CVE-Referenz: VE-2010-2568 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2568

Generelle Beschreibung:
W32.Stuxnet wurde erstmalig im Juli 2010 kategorisiert. Symantec taufte diesen Schädling nach der ersten Entdeckung und den damals vorliegenden Informationen zunächst auf den Namen „W32.Temphid“ und änderte den Namen später auf Stuxnet, um in Kovention mit anderen AntiVirus Lösungsanbietern zu bleiben. Am 19. Juli 2010 wurden entsprechende automatische Erkennungsmuster für diesen Schädling für die AntiVirus Lösungen erstellt und weltweit verteilt.

Der Wurm attackiert industrielle Kontrollsysteme wie bspw. Stromaggregate, um die Kontrolle über diese Systeme zu erlangen. Obwohl die tatsächlichen Motive der „Erschaffer“ von Stuxnet immer noch unklar sind, wird spekuliert, dass aus verschiedenen Gründen vor allem die industrielle Spionage der Hauptgrund sein dürfte. Bis jetzt ist auch die tatsächliche Identität des oder der „Erschaffer“ von Stuxnet noch nicht bekannt. Unabhängig von der wahren Identität bestehen aber nur geringe Zweifel, dass diese über hervorragende technische Fähigkeiten und eine erstklassige Ausstattung verfügen müssen – und diese Eigenschaften in Kombination zur Erzeugung einer sehr spezifischen Bedrohung in sehr kurzer Zeit genutzt wurde. Stuxnet hat zudem gleich vier Exploits für Zero-Day Schwachstellen für seine Verbreitung ausgenutzt – ein bisher noch nie dagewesener Fall.

Infektionsarten:
Stuxnet war die erste Malware-Art, die die Microsoft Windows Shortcut ‚LNK/PIF‘ Files Automatic File Execution Vulnerability (BID 41732) für seine Verbreitung nutzte. Der Wurm platzierte dazu eine Kopie von sich selbst und eine Verlinkung zu dieser Kopie auf einem transportablen Speichermedium. Wenn so ein infiziertes transportables Speichermedium an ein System angeschlossen und mit einer Applikation darauf zugegriffen wird, die Icons anzeigen kann (wie bspw. der Windows Explorer), dann führt die verlinkte Datei die Kopie des Wurms aus. Aufgrund eines Design-Fehlers in Windows können Applikationen, die in der Lage sind, Icons anzuzeigen, auch versehentlich einen damit verbundenen Code ausführen. Im Falle von Stuxnet verwies der Code der .lnk Datei auf die Kopie des Wurms auf demselben transportablen Speichermedium.

Zudem nutzte Stuxnet auch die Microsoft Windows Server Service RPC Handling Remote Code Execution Schwachstelle (BID 31874), die durch den enormen Erfolg des W32.Downadup Schädlings (alias Conficker) traurige Berühmtheit erlangte. Aber auch die Microsoft Windows Print Spooler Service Remote Code Execution Schwachstelle (BID 43073) wurde vom Wurm genutzt. Zu guter letzt versuchte sich der Wurm auch über mit schwachen Passwörtern geschützte Netzwerklaufwerke / Ordner mittels Kopien zu verbreiten.

Funktionalität
Die primäre Absicht des Stuxnet Wurms ist, die Kontrolle über Industrieanlagen zu gewinnen. Interessanterweise hat man bisher anscheinend nicht damit gerechnet, dass es den Malware-Autoren bereits möglich ist, eine Malware zu entwickeln, die nicht nur die Computer infiziert, die diese Anlagen kontrollieren, sondern auch die Anlagen selbst. Wie dem auch sei – wie jeder andere Wurm auch verbreitete sich dieser Wurm in ungewöhnlich hoher Geschwindigkeit über die oben beschriebenen Schwachstellen.

Der zeitliche Ablauf der Attacke zeigt, dass der Stuxnet Wurm anfangs vor allem Computern aus den Ländern Iran, Indonesien und Indien angegriffen hat.

Um so eine enorme Verbreitung in kürzester Zeit erreichen zu können, hat der Wurm zwei unterschiedliche und sehr umfassend legitimierte digitale Zertifikate von sehr bekannten Unternehmen verwendet. Dies führte dazu, dass zunächst die meisten AntiVirus Lösungen den Wurm nicht als Gefahr erkannten. Wenn der Wurm den Weg auf einen Computer gefunden hat und die .LNK Schwachstelle zur eigenen Ausführung nützt, installierte er anschliessend ein Rootkit, um sich selbst innerhalb des infizierten Systems verstecken zu können.

Stuxnet sucht nach industriellen Kontrollsystemen, die im allgemeinen (und fälschlicherweise) auch unter dem Namen SCADA Systeme bekannt sind. Findet der Wurm solche Systeme auf einem kompromitierten Computer, dann versucht er, den Code und entsprechend gespeicherte Projektdaten zu stehlen. Der Wurm kann auch die Vorteile einer auf einem kompromitierten Computer vorhandenen Software-Programmierungs-Schnittstelle nutzen, um seinen eigenen Code in die Programmierbaren Logic Controler (PLCs) zu implementieren. Solche PLC sind „Mini-Computer“ innerhalb eines industriellen Kontroll-Systems, die typischerweise wiederum von SCADA Systemen überwacht werden. Stuxnet tarnt anschliessend seinen eigenen Code, damit ein Programmierer, der einen kompromitierten Computer zur Anzeige des Codes auf einem PLC verwendet, nicht den zusätzlichen, von Stuxnet injizierten Code entdecken kann.

Aus diesem Grund ist Stuxnet nicht nur ein Rootkit, dass sich unter Windows tarnen kann, sondern das erste bekannt gewordene Rootkit, dass seinen Code auch in ein PLC injizieren und verstecken kann.

Geographische Verbreitung:
Symantec hat die folgende geographische Verbreitung dieser Bedrohung beobachtet:

 

Verbreitungsniveau:
Symantec hat die folgenden Infektionsraten dieser Bedrohung in der letzten Woche weltweit registrieren können:

Wie konnten von den Stuxnet „Erschaffern“ digitale Signaturen geraubt werden? (von Fergal Ladley)

Ein wesentlicher Erfolg von Stuxent im industriellen Umfeld beruhte auf der Tatsache, dass die Malware über eine offizelle digitale Signatur von zwei weltweit renommierten, taiwanesischen Chip-Produzenten verfügte. Solche Signaturen sollen eigentlich im Vorfeld garantieren, dass eine Software über keine schädlichen Inhalte verfügt und ohne größere Prüfprozesse auf einem Rechner installiert werden kann, da sie ja von einem renommierten Unternehmen stammt und geprüft wurde. Entsprechend schnell konnte Stuxnet durch diese Signatur sich auf den bestens geschützen industriellen Systemen ausbreiten. Nachforschungen haben ergeben, dass diese digitalen Zertifikate den taiwanesischen Produzenten gestohlen wurden. Der Symantec IT-Security Spezialist Fergal Ladley zeigt in der folgenden Analyse, dass der Diebstahl digitaler Zertifikate nicht unbedingt etwas Neues in der Malware Szene ist.

Im Juli 2010 konnten die ersten Stuxnet Würmer beobachtet werden, die industrielle Kontrollanlagen angegriffen haben. Dafür haben die „Erschaffer“ von Stuxnet die digitalen Signaturen von zwei taiwanesischen Chip-Produzenten gestohlen und diese in das Rootkit implementiert, das der Wurm einsetzt. Wie es den „Erschaffern“ von Stuxnet gelingen konnte, an die privaten Schlüssel zu gelangen, damit die gestohlenen Signaturen auch für die Cyberkriminellen zweckvoll eingesetzt werden können, bleibt nach wie vor ein ungelöstes Geheimnis im gesamten Stuxnet-Puzzle – oder vielleicht doch nicht?

Um auch nur ein Binary digital signieren zu können, müssen sie einen privaten Schlüssel besitzen. Wenn es einem Angreifer gelingt, in den Besitz dieses privaten Schlüssel zu kommen, dann kann sie/er die Signatur des Schlüsselbesitzers komplett stehlen. Daher sollte man immer dafür sorgen, dass der private Schlüssel auch privat/geheim bleibt. Wie dem auch sei. Diese privaten Schlüssel der taiwanesischen Chip-Produzenten wurden gestohlen und von den Stuxnet „Erschaffern“ zur digitalen Signatur des Rootkits verwendet. Dies gewährleistete, dass das Rootkit auch von Windows Vista und Windows 7 Betriebssystemen geladen werden konnte.

Einen privaten Schlüssel für ein digitales Zertifikat zu erhalten, ist gar nicht so schwierig, wie es man sich vorstellen könnte. Der „Infostealer.Nimkey“ ist ein gutes Beispiel für eine Bedrohung, die nur darauf ausgelegt ist, PKCS#12 Public Key Zertifikatsdateien zu stehlen. PKCS#12 Zertifikate unterscheiden sich von gewöhnlichen Public Key Zertifikaten – sie können nämlich nicht nur öffentliche, sondern auch private Schlüssel enthalten!

Diese Bedrohung wurde mittels Spam-eMail-Nachrichten in Umlauf gebracht, die Links auf kompromitierte Webseiten in Italien, Ungarn, Deutschland und den U.S.A. (Bundesstaaten Texas und Florida) enthielten, auf denen der Trojaner gehostet wurde. Der Trojaner wurde auf einen potentiellen Opfer-Rechner als „.com“ Datei wie bspw. „irs-pdf-f941.irs.com“, „report6.com“ oder „details.com“ heruntergeladen. Es ist eine von Cyberkriminellen gängige Social Engineering Taktik, um unbedarfte Internetnutzer zur Ausführung der Malware zu bewegen, indem man den eigentlichen Dateinamen derart umgestaltet, dass dieser wie ein Link auf eine Webseite aussieht.

Wenn die Bedrohung „Infostealer.Nimkey“ auf einem potentiellen Opfer-Rechner ausgeführt wird, dann beginnt der Infostealer sofort damit, das „Formular 941 aus dem Jahr 2010 für die vierteljährliche Steuererstattung für Angestellte“ der US-Steuererstattungsbehörde herunterzuladen und anzuzeigen. Hierbei handelt es sich lediglich um eine weitere Social Engineering Taktik, die den eigentlichen Nutzer des Rechners von der Tätigkeit der Malware im Hintergrund ablenken soll.

Während der Nutzer also abgelenkt ist, lädt der Trojaner zusätzliche Malware Dateien von einer Polnischen, Moldawischen oder Bosnischen Webseite herunter. Eine der heruntergeladenen Dateien wird unter dem Namen „alg.exe“ gespeichert. Die andere heisst „AcroIEHelper.dll“ und ist ein Browser Helper Objekt. Warum ein Browser Helper Object? Nun – die „AcroIEHelper.dll“Datei ist immer aktiviert, wenn der Internet Explorer gestartet wird. Sie zeichnet alle URLs auf, auf die vom infizierten Rechner zugegriffen wird und sendet diese Informationen an einen Server nach China.

Die „alg.exe“ Komponente sucht hingegen auf dem infizierten Rechner nach Dateien mit dem Namen „Cert_*.p12″(die zuvor bereits erwähnten PKCS#12 Zertifikate). Da die privaten Schlüssel aber immer verschlüsselt gespeichert werden, so enthält „Infostealer.Nimkey“ gleich praktischerweise einen integrierten Keylogger (ein Tool zum Aufzeichnen von Tastatureingaben), dass sogar nicht nur Tastatureingaben, sondern auch Daten aus dem Windows Clipboard aufzeichnen kann. Auch diese gestohlenen Zertifikate, die aufgezeichneten Tastatureingaben und die Daten aus dem Windows Clipboard werden an den Server in China via HTTP gesendet.

„Infostealer.Nimkey“ enthält alles, was man zum Diebstahl privater Schlüsselinformationen benötigt. Jeder, der diese Informationen besitzt, kann seine eigenen geschriebenen Dateien z.B. mit der Signatur eines vertrauenswürdigen Software-Anbieters (falls diesem die Schlüssel gestohlen wurden) digital signieren. Vielleicht ist es aber auch ihr Unternehmen, dass den nächsten gefährlichen Trojaner digital signiert – wer weis…..

Wenn aber immer mehr Bedrohungen auftauchen, die auf einen Diebstahl der privaten Schlüssel von digitalen Zertifikaten ausgelegt sind, dann wird auch verstärkt signierte Malware in den Umlauf kommen und unglücklicherweise dazu führen, dass digitalen Zertifikaten immer weniger vertraut wird. Jeder, der der Meinung ist, dass der persönliche private Schlüssel oder der private Schlüssel des eigenen Unternehmens kompromitiert sein könnte, sollte seinen Zertifikats-Anbieter um Hilfe bitten.

Wie erfolgte die erste Verbreitung von Stuxnet? (von Liam O Murchu)

Der IT-Sicherheitsexperte Liam O Murchu von den Symantec Security Response Labs beschreibt in dieser Analyse die ersten Infektionswege des Stuxnet Wurms über die AutoRun Funktionalität von Windows Betriebssystemen – ein sehr beliebter Trick von Malware-Autoren zur Verbreitung von Schädlingen.

Die ersten Varianten von Stuxnet nutzten keine Schwachstellen um sich zu verbreiten, sondern einen AutoRun Trick. Der Trick des Wurms war dabei, aus zwei versteckten Gründen eine Autorun.inf Datei in das Root-Verzeichnis eines transportablen Speichermedium zu platzieren: Die speziell präparierte Datei konnte vom Sytem entweder als ausführbare Datei oder als korrekt formatiertes autorun.inf Datei interpretiert werden. Wenn Windows eine autorun.inf Datei analysiert, dann ist die Analyse ganz klar vorgegeben. Vor allem wird jedes Zeichen, dass nicht als Teil eines legitimen AutoRun Kommandos angesehen wird, als Abfall angesehen und die Analyse geht ganz normal weiter. Stuxnet nutzt dies zu seinem Vorteil und platziert die MZ-Datei ganz am Anfang der autorun.inf Datei. Wenn Windows also die autorun-inf Datei analysiert, dann wird der gesamte MZ Inhalt als Datenmüll ignoriert, bis Windows am Ende der Datei auf die legitimen AutoRun Kommandos  stößt. Der Anfangs- (Header) und der Schlussteil (Footer) sind in den folgenden beiden Abbildungen beschrieben:

Anfangsteil der autorun.inf Datei:

 

Schlussteil der autorun.inf Datei:

Extrahiert man nur die Zeichenfolgen aus dem Schlussteil, dann kann man erkennen, dass diese aus legitimen AutoRun Kommandos bestehen:

Beachten Sie dabei, dass die AutoRun Befehle die autorun.inf Datei selbst als die Datei spezifizieren, die es auszuführen gilt (im obigen Bild rot markiert). Durch diesen Trick wird die autorun.inf Datei zuerst als ganz normale autorun.inf Datei behandelt und anschliessend als legitime EXE-Datei ausgeführt (und somit der Wurm gestartet). Zusätzlich zu dieser gerissenen List nutzt Stuxnet aber noch einen weiteren Trick, um die Wahrscheinlichkeit seiner Ausführung zu erhöhen. Die AutoRun Befehle, die im obigen Text bereits beschrieben und gezeigt wurden, schalten zunächst die AutoPlay Funktion ab und fügen anschliessend einen neuen Befehl in das Kontext (z.B. Rechtsklick) Menü ein. Diesen Befehl, der hinzugefügt wird, findet man im Verzeichnis %Windir%\system32\shell32.dll,-8496 und sieht wie der ganz normale „Öffnen“ Befehl aus. Dies bedeutet, dass man bei der Ansicht des Kontext-Menüs für den transportablen Datenträger zwei „Öffnen“ Befehle sehen kann, wie die nachfolgende Abbildung zeigt:

Einer dieser Befehle ist der richtige Öffnen Befehl, der andere der von Stuxnet zugefügte „Öffnen“-Befehl. Wenn sich der Anwender zum Öffnen des transportablen Datenträgers mit dem falschen Öffnen-Befehl entscheidet, dann wird der Wurm gemäß den Anweisungen in der autorin.inf Datei ausgeführt. Der Stuxnet Code öffnet anschliessend das Explorer Fenster und zeigt ganz normal die Inhalte des transportablen Datenträgers an. Der Anwender ist der Meinung, dass alles ganz normal verlaufen sei. Es ist aber anzumerken, dass der Erfolg von der ersten Stuxnet Varianten sehr stark von den AutoPlay und AutoRun Einstellungen eines Rechners abhängig war/ist. Es empfiehlt sich daher immer, diese beiden Funktionen zu deaktivieren, um sich und Andere vor allem vor der Ausbreitung von Würmern zu schützen.

Da sich diese Infektionsmöglichkeit sehr einfach blockieren läßt, so haben der oder die „Erschaffer“ von Stuxnet im späteren Verlauf der Attacke noch vier Zero-Day Exploits (wie am Anfang des Artikels beschrieben) in den Code von Stuxnet implementiert.

Update 27. September 2010: Stuxnet Infektion mittels Step 7 Projekten (von Nicolas Falliere)

Das Stuxnet sich Anfangs über autorun.inf Dateien auf transportablen Speichermedien und später durch die Ausnutzung von vier Zero-Day Exploits verbreitet hat, ist mittlerweile bestens bekannt. Der IT-Sicherheitsexperte Nicolas Falliere beschreibt in dieser Analyse einen neu entdeckten Infektionsweg über Step 7 Projektdateien und Ordner.

Die Untersuchungen der Symantec Security Response Labs haben eine weitere Methode zur Verbreitung des Stuxnet Wurms aufgedeckt: Step 7 Projekt-Ordner. Wenn ein Nutzer einen von einem anderen Nutzer angelegten Step 7 Projekt-Ordner öffnet und dieser zuvor vom Stuxnet Wurm infiziert wurde, dann wird auch sein System mit dem Wurm infziert.

Die Struktur eines Step 7 Projektordners sieht in etwa folgendermaßen aus:
ApiLog\…
CONN\…
Global\…
hOmSave7\…
XUTILS\…
XUTILS\listen\…
XUTILS\links\…
…
.s7p
…

Stuxnet überwacht Step 7 Projekte (.SP7 Dateien), an denen gearbeitet wird, indem er sich mit Datei-erzeugende APIs spezifischer DLLs innerhalb des s7tgtopx.exe Prozesses (dem Simatic Manager) verkettet. Jedes Projekt, auf das Stuxnet auf diese Weise trifft, wird infiziert. Tiefergehende Analysen haben ergeben, dass sogar Projekte innerhalb von ZIP-Dateien auf dieselbe Art infiziert wurden.

Der Infektionsprozeß geht dabei in mehreren unterschiedlichen Schritten vor sich:

Zuerst erzeugt Stuxnet die folgenden Dateien:

• xutils\listen\xr000000.mdx: eine verschlüsselte Kopie der  grundlegenden Stuxnet .dll Datei
• xutils\links\s7p00001.dbf: eine Kopie der Stuxnet Datendatei (90 Bytes groß)
• xutils\listen\s7000001.mdx: eine verschlüsselte, aktualisierte Version des Stuxnet Konfigurations-Daten-Blocks

Anschliessend sucht Stuxnet nach Unterordnern im hOmSave7 Ordner. In jedem gefundenen Unterordner wird eine Kopie der Stuxnet .dll Datei innerhalb der Ressourcen hinterlegt. Diese DLL Datei verfügt über einen spezifischen Namen (im Folgenden einfach „xyz.dll“ genannt).

Nun modifiziert Stuxnet die Step7 Datendatei, die sich innerhalb der Projekt-Ordner-Struktur befindet. Aus Sicherheitsgründen (möglicher Nachbau durch andere Malware-Autoren) wird auf diese Modifikation nicht genauer eingegangen. Mit diesem Schritt ist dann der eigentliche Infektionsprozeß abgeschlossen.

Wenn nun ein infiziertes Projekt mit dem Simatic Manager geöffnet wird, dann führt die modifizierte Datendatei eine Suche nach der „xyz.dll“ aus. Es werden auch nach den folgenden Ordnern in dem Ordnern gesucht:

• Der S7BIN Ordner innerhalb des Step7 Installationsordners
• Der „System“ Ordner
• der „Windir\System“ Ordner
• der „Windir“ Ordner
• Unterordner des Projekt hOmSave7 Ordners

Wenn die „xyz.dll“ Datei in keiner der ersten vier oben aufgeführten Verzeichnisse/Ordner gefunden werden kann, dann wird die gefährliche DLL geladen und vom Manager ausgeführt. Diese gefährliche DLL Datei agiert dabei wie ein Entschlüsselungs- und Ladeprogramm für die Haupt-DLL Datei, die sich unter „xutils\listen\xr000000.mdx“ versteckt. Diese Strategie ist den im AUgust 2010 beobachteten DLL Preloading Attacken sehr ähnlich.

Die Symantec Security Repsonse Labs haben diese Infektionsmöglichkeit mit zwei verschiedenen Versionen des Simatic Managers getestet. Dabei waren die Version 5.3 und 5.4 SP4 von einer Infektion betroffen, Step7 Lite v3 aber anscheinend nicht. Es konnte bis jetzt noch nicht eindeutig geklärt werden, ob auch die aktuellsten Versionen des Managers (v5.4 SP5 und v5.5 – beide vom August 2010) ebenfalls für eine Infektion anfällig sind.

Stuxnet´s Fähigkeit, Projekt-Dateien zu infizieren und sich selbst bei einem Öffnen weiter zu verbreiten ist nur eine weitere Variante der vielen Verbeitungswege dieses Wurms. Obwohl die Symantec Security Response Labs von Haus aus allen Betreibern und Programmierern immer raten, keine Projektdateien von nicht vertrauenswürdigen Quellen – bspw. Internetforen – zu öffnen, so liegt hier ja – wie leider immer öfter zu beobachten – die Gefahr durch eine Infektion eines solchen Verzeichnisses innerhalb eines eigentlich vertrauenswürdigen Netzes und somit einer vertrauenswürdigen Quelle. Hinzu kommt noch, dass vielleicht sogar infizierte Projekte bereits im Rahmen eines täglichen oder wöchentlichen Backups gesichert wurden und bei einem Restore der Dateien und Ordner sich die Infektion erneut auf bereits gesäuberten Systemen ausbreitet. Administratoren sollten daher sehr genau die gesicherten Dateien und Ordner untersuchen, bevor sie diese einfach wiederherstellen.

Beschreibung des PLC Infektions-Prozesses von Stuxnet (von Nicolas Falliere)

Stuxnet zielt auf die Infektion industrieller Kontrollsysteme ab. Aber nicht nur das Kontrollsystem selbst – bspw. ein Windows Rechner zur Steuerung bestimmter industrieller Anlagen – ist betroffen, sondern auch die programmierbaren, logischen Controller (PLCs) der Anlagen, die mittels des Kontrollrechners gewartet / programmiert werden. Der IT-Sicherheitsexperte Nicolas Falliere von den Symantec Security Response Labs beschreibt in dieser Analyse, dass Stuxnet sowohl die Infektion programmiertechnisch komplett unterschiedlicher Systeme wie auch das raffinierte Tarnen auf diesen beiden komplett unterschiedlichen Systemen bestens beherrscht.

Da Stuxnet ein spezifisches industrielles Kontrollsystem attackiert, so könnte die Verhaltensanalyse dieser Bedrohung auf einem Testsystem zu falschen Schlüssen führen, da in so einem standardisierten Testsystem die meisten der interessanten Verhaltenscharakteristiken dieses Schädlings einfach nicht vorkommen. Einmal ausgeführt ist eine der ersten Verhaltensweisen des Stuxnet Wurms, sofort auf den programmierbaren logischen Controller (PLC) Datenblock DB890 zuzugreifen. Dieser Datenblock wurde von Stuxnet selbst hinzugefügt und ist kein ursprünglicher Bestandteil eines angegriffenen Systems. Stuxnet überwacht und schreibt in diesen Datenblock, um den PLC Programmfluss hinsichtlich bestimmter Bedingungen zu beeinflussen.

Im Folgenden soll deshalb einmal genauer auf die eigentliche PLC Infektion und die Rootkit Funktionalität eingegangen werden. Im Speziellen sollen die folgenden, wichtigen Aspekte der Stuxnet Attacke auf angegriffenen industriellen Kontrollsystemen untersucht werden:

1. Wie wählt Stuxnet die industriellen Kontrollsysteme aus, die er angreifen will
2. Die von Stuxnet verwendete Methode, um PLC Code Blöcke zu infizieren
3. Der aktuelle Code, der von Stuxnet in die PLCs während einer Infektion platziert wird.
4. Der PLC Rootkit Code, der sich auf einem infizierten Windows Rechner befindet

Diese vier Punkte werden einzeln behandelt, da auch der Code, um jede dieser Aufgaben zu erreichen, sehr unterschiedlich ist.

Das Ziel von Stuxnet ist, das Verhalten eines industriellen Kontrollsystems durch die Modifikation der PLCs zu verändern. Aus diesem Grund fängt er die Schreib-/Leseanfragen, die vom System an den PLC gesendet werden, ab und bestimmt so, ob das System auch das gewünschte Zielsystem ist. Anschliessend modifiziert er die bestehenden PLC Code Blöcke und schreibt neue Blöcke in den PLC. Abschliessend versteckt er mittels einer Rootkit Funktionalität die PLC Infektion vor dem eigentlichen PLC Betreiber/Programmierer. Diese Aufgaben sind sehr unterschiedlich, da beispielsweise das Verstecken der infizierten Code Blöcke über den infizierten Windows Rechner mittels einem üblichen C/C++ COde stattfindet und der gefährliche Code, den Stuxnet über das industrielle Kontrollsystem auf dem PLC ausführt in MC7 Bytecode verfasst ist. MC7 ist die Assembler-Sprache, die für PLCs verwendet wird und ist oftmals in STL verfasst.

Bevor wir nun die Stuxnet Techniken für den Angriff auf PLC genauer betrachten, sollten wir erst einmal einen Blick darauf werfen, wie auf PLCs normalerweise zugeriffen wird und wie diese programmiert werden:

Um auf einen PLC zugreifen zu können, muss eine spezifische Software auf einem Rechner installiert sein. Stuxnet greift im speziellen die WinCC/Step 7 Software an, die für die Programmierung spezifischer PLC Modelle verwendet wird. Mit Hilfe dieser Software kann sich ein Programmierer mit dem PLC über ein Datenkabel verbinden und auf die Speicherinhalte zugreifen, diese modifizieren, ein Programm heraufladen oder den bisherigen Code von Fehlern bereinigen. Wenn der PLC einmal konfiguriert und prgrammiert wurde, dann kann die Verbindung mit dem Windows Rechner getrennt erden und der PLC funktioniert selbständig. Die folgende Abbildung zeigt, wie diese Konstellation im Symantec Test Labor nachgestellt wurde:

Der nachfolgende Screenshot zeigt einen Teil von Stuxnet´s gefährlichem Code im Step7 STL Editor. Es ist der Anfang des MC7 Codes für einige von Stuxnet´s Funktions Code (FC) Blöcken sichtbar. Der sichtbare Code stammt vom disassimilierten Block FC1873.

Die Step 7 Software nutzt eine Library-Datei mit dem Namen s7otbxdx.dll, um die aktuelle Kommunikation mit dem PLC durchzuführen. Das Step 7 Programm ruft deshalb verschiedene Routinen in dieser DLL auf, wenn es einen Zugriff auf den PLC durchführen will. Wenn beispielsweise ein Code Clock vom PLC mittels Step 7 gelesen werden soll, wird die s7blk_read Routine aufgerufen. Der Code in der s7otbxdx.dll Datei greift auf die PLC zu, liest den Code aus und schickt ihn an das Step 7 Programm, wie die folgende Abbildung zeigt:

Wie sieht nun der Zugriff auf den PLC aus, wenn Stuxnet installiert ist. Nach dem Start benennt Stuxnet zuerst einmal die Original s7otbxdx.dll Datei in s7otbxsx.dll um. Anschliessend wird die Original-Datei durch die Stuxnet Version ersetzt. Stuxnet kann jetzt jeden Aufruf, der für einen Zugriff auf die PLC egal von welchen Software-Paket aus gestartet wird, abfangen.

Stuxnet´s modifizierte s7otbdxdx.dll Datei enthält alle portentiellen Export-Befehle der Original-DLL Datei – mit maximal 109 Befehlen – damit auch dieselben Abfragen vorgenommen werden können. Die Mehrzahl dieser Exportanfragen werden einfach von der Stuxnet Variante an die echte DLL weitergeleitet, die ja nun s7otbxsx.ddll heisst. Es passiert also nicht Ungewöhnliches. Tatsächlich werden 93 der ursprünglich 109 Exportanfragen auf diese Weise abgearbeitet. Der Trick liegt in den 16 Export-Abfragen, die nicht einfach weitergeleitet, sondern von der  Stuxnet DLL direkt abgefangen werden. Diese abgefangenen Export-Abfragen sind die Routinen, die für das Lesen, Schreiben und die Ortsbestimmung der Code Blöcke auf dem PLC zuständig sind. Durch das Abfangen dieser Abfragen ist Stuxnet in der Lage, alle Daten, die vom PLC gesendet oder die an den PLC geleitet werden, zu modifizieren. Und das, ohne das es der Betreiber oder Programmierer des PLCs jemals bemerken wird. Diese Vorgehensweise ist auch der Grund dafür, das der gefährliche Code innerhalb des PLCs nicht sichtbar ist.

Um verstehen zu können, wie Stuxnet auf einen PLC zugreift und diesen infiziert, müssen wir uns zunächst einmal die bestehenden Daten ansehen. PLCs arbeiten mit Code- und Datenblöcken, die vom Betreiber auf den PLC geladen werden. Für ein besseres Verständnis wollen wir einmal die gängisten Arten von Codeblöcken und ihre Funktionsweise beschreiben:

• Datenblöcke (DB) enthalten programm-spezifische Daten wie Nummern, Strukturen usw.
• Systemdatenblöcke (SDB) erhalten Informationen, wie der PLC konfiguriert ist. Diese werden abhängig von der Anzahl/dem Typ der Hardware Module erzeugt, die mit dem PLC verbunden sind.
• Organisations-Blöcke (OB) sind die Einstiegspunkte des Programms. Sie werden periodisch von der CPU ausgeführt. In Bezug auf Stuxnet sind die wichtigsten OBs:
  • OB1 ist der Startpunkt des PLC Programms. Es wird periodisch ohne spezifische Zeitvoraussetzungen ausgeführt
  • OB35 ist der Standard-Überwachungs-Organisations-Block. Er wird vom System alle 100 msec ausgeführt. Diese Funktion enthält die gesamte Logik, die zur Überwachung von kritischen Eingaben mit sofortigen Antworten oder die zur Durchführung zeitkritischer Funktionen benötugt wird.
• Funktionsblöcke (FC) sind die Standard Code Blöcke. Sie beinhalten den eigentlichen Code, der vom PLC ausgeführt wird. Im Allgemeinen referenziert der OB1 Block auf mindestens einen FC Block.

Die folgenden Bereiche gehen auf die zuvor beschriebenen 4 Aspekte der Stuxnet PLC Infektion

genauer ein.

1. Bestimmung, welcher PLC infiziert werden soll

Stuxnet infiziert PLCs mit unterschiedlichem Code – abhängig von den Charakteristiken des Zielsystems. Eine Infektions-Sequenz besteht aus PLC Blöcken (Code-Blöcken und Datenblöcken), die in den PLC injiziert werden, um dessen Verhalten zu verändern. Die Bedrohung beinhaltet drei Infektions-Sequenzen. Zwei dieser Sequenzen sind sehr ähnlich und funktionell äquivalent. Wir haben diese beiden Sequenzen A und B getauft. Die dritte Sequenz wurde als Sequenz C betitelt. Stuxnet bestimmt, ob das System das beabsichtigte Zielsystem ist, indem es das System mittels der Fingerprinting-Technik kennzeichnet. Stuxnet überprüft:

• Den PLC Typ/die PLC Familie: nur CPUs 6ES7-417 und 6ES7-315-2 werden infiziert
• Die System Daten Blöcke: die SDBs werden geparst und abhängig von den Werten, die sie enthalten, wird er Infektionsprozess mit der Methode A oder B oder keiner gestartet. Während des Parsens der SDBs sucht der Code nach der Präsenz von 2 Werten (7050h und 9500h). Abhängig von der Anzahl des Auftauchens jeder dieser Werte wird die Sequenz A oder B verwendet, um den PLC zu infizieren.

Der Code sucht zudem nach den Bytes 2C CB 00 01 beim Offset 50h in den SDB Blöcken. Dies kommt vor, wenn der CP 342-5 Kommunikations-Prozessor (der für die Profibus-DB verwendet wird) vorhanden ist. Wenn diese Bytes nicht gefunden werden, dann findet auch keine Infektion statt.

Die Infektionsbedingungen für die Sequenz C werden von anderen Faktoren bestimmt.

2. Infektionsmethode

Stuxnet nutzt Code-abhängige Infektionstechniken. Wenn Stuxnet die OB1 infiziert, dann führt er die folgenden Aktionssequenzen aus:

1. Die Größe des ursprünglichen Blocks erhöhen
2. Den gefährlichen Code am Anfang des Blocks einfügen
3. Den Original-OB1 Code nach dem gefährlichen Code wieder einfügen

 

Für die Infektion der OB35 geht Stuxnet in ähnlicher Weise wie für die Infektion der OB1 vor. Es wird ebenfalls der Original Coprozessor DP_RECV Block mit dem eigenen Code Block ausgetauscht und somit die Netzwerk-Kommunikation auf dem Profibus (einem Standard industriellen Netzwerk Bus, der für ein verteiltes I/O genutzt wird) verkettet.

Der gesamte Prozess für die Infektionsmethoden A/B lässt sich wie folgt zusammenfassen:

• Überprüfung des PLC Typs – dieser muss S7/315-2 entsprechen
• Überprüfung der SDB Blöcke und Festlegung, ob die Sequenz A oder B geschrieben werden soll
• Auffinden von DP_RECV, dieses anschliessend in die FC1869 kopieren und mit dem gefährlichen Code von Stuxnet ersetzen.
• Schreiben der gefährlichen Blöcke (insgesamt 20 Blöcke) der Sequenz, die in Stuxnet eingebettet sind.
• Infizierung von OB1, damit der gefährliche Code jedesmal beim Start eine Zykluses ausgeführt wird
• Infizierung von OB35, der als Aufpasser fungiert.

3. Der Infektionscode

Der Code, der in die OB1 Funktion eingefügt wird, ist für den Start der Infektionssequenzen A und B verantwortlich. Diese Sequenzen beinhalten die folgenden Blöcke:

• Code Blöcke: FC1865 bis FC1874, FC1876 bis FC1880 (beachten Sie hierbei, dass FC1869 nicht von Stuxnet selbst stammt, sondern dass es sich hierbei um eine Kopie des Original Dp_RECV Blocks der PLC handelt)
• Daten Blöcke: DB888 bis DB891

Die Sequenzen A und B fangen Pakete auf dem Profibus durch die Nutzung des DP_REVC Hooking Blocks ab. Basierend auf den Werten, die in diesem Blöcken gefunden wurden, werden andere Pakete generiert und über das Kabel gesendet. Dies wird über eine komplexe State Machine (die in den verschiedenen, oben bereits erwähnten FC Blöcken implementiert ist) kontrolliert. Diese Maschine kann auch partiell über die DLL mittels dem Datenblock DB890 kontrolliert werden.

Unter bestimmten Bedingungen kann auch die Sequenz C auf einen PLC geschrieben werden. Diese Sequenz enthält mehr Blöcke als die Sequenzen A/B:

• FC6055 bis FC6084
• DB8062, DB8063
• DB8061, DB8064 bis DB8070, generiert im Vorübergehen

Die Sequenz C ist auserkoren, I/O (Input/Output) Informationen in die I/O Speicher-Abbild-Bereiche des PLCs wie auch der periphären I/O zu lesen und zu schreiben.

Der Kontrollfluss für das Programm A/B wird nachfolgend gezeigt, der auch teilweise im Screenshot des Step7 Editors zuvor (Code Block FC1873) zu sehen war:

Der Programmfluss für die Code Sequenz C ist deutlich komplexer – wie das folgende Diagramm zeigt:

4. Das Rootkit

Der Stuxnet PLC Rootkit Code ist komplett in der falschen s7otbxdx.dll Daeti enthalten. Um sein Ziel einer Nichtentdeckung auf einem PLC zu erreichen, müssen die folgenden Voraussetzungen gegeben sein:

1. Die Anfragen für die eigenen gefährlichen Code Blöcke müssen gelesen werden
2. Die Anfragen für die infizierten Code Blöcke (OB1, OB35, DP_RECV) müssen gelesen werden
3. Anfragen selbst verfassen, die den eigenen Code von Stuxnet überschreiben können

Stuxnet enthält Code, um solche Anfragetypen zu überwachen und abzufangen. Stuxnet modfiziert solche Anfragen derat, dass der Stuxnet Code selbst niemals entdeckt oder beschädigt wird. Die folgende List gibt einige Beispiele, wie Stuxnet die gehookten Exporte nutzt, um diese Situationen abzuwickeln:

• s7blk_read: Lese-Anfragen werden überwacht. Stuxnet wird dann rückmelden:
  • die echte DP_RECV (die als FV1869 gespeichert wurde), wenn diese angefragt wird
  • Eine Fehlermeldung, wenn die ANfrage die eigenen gefährlichen Blöcke betrifft
  • Eine gesäuberte Versions- (auf die Schnelle desinfiziert) Kopie von OB1 oder OB35
• s7blk_write: Schreib-Anfragen bezüglich OB1/OB35 werden überwacht, um sicherzustellen, dass auch neue Versionen dieser Blöcke gleich wieder infiziert werden
• s7blk_findfirst / s7blk_findnext: Diese Routinen werden genutzt, um Blöcke auf einem PLC zu zählen. Gefährliche Blöcke werden dabei von Stuxnet elegant bei der Zählung weggelassen
• s7blk_delete: Das Löschen von Blöcken wird natürlich ebenfalls überwacht.

Auf diese Weise kann Stuxnet seine dauernde Präsenz auf einem PLC sicherstellen.

Update 10. Oktober 2010: Die Erkennung von PLC Infektionen (von Nicolas Falliere – Symantec Security Response Labs)

Der IT-Sicherheitsexperte Nicholas Falliere gibt im Symantec Security Response Weblog einen detaillierten Einblick in die PLC Infektionen von Stuxnet und zeigt Möglichkeiten auf, wie man diese Infektionen entdecken kann.

In diesem Beitrag werden weitere Details des PLC Infektionsprozesses und Massnahmen aufgezeigt, wie ein Administrator feststellen kann, ob ein PLC infiziert wurde.

Zunächst einmal bleibt festzuhalten, dass das finale Ziel von Stuxnet die Infektion spezieller SIEMENS Simatic PLCs ist. Um dieses Ziel zu erreichen, wird die Simatic DLL von Stuxent ersetzt und agiert ab diesem Zeitpunkt als Proxy zwischen der Programmierumgebung und den PLC Geräten. Die DLL kann folgende Aufgaben übernehmen:

• Überwachung der Kommunikation zwischen den PLCs und der Programmierumgebung
• Infektion von PLCs
• Tarnen potentiell infizierter PLCs

Eine Sequenz besteht dabei auf verschiedenen gefährlichen Blöcken wie auch Infektions-Kontroll-Abschnitten für bereits infizierte PLC Blöcke. In Stuxnet sind dabei zwei Sequenz-Typen enthalten.

Sequenzen A und B

Der erste Typ besteht aus zwei ähnlichen Sequenzen – A und B. Jede Sequenz besteht aus 20 Blöcken und greift speziell die PLC 315-2 mit eigenen System-Datenblöcken an (für weitere Details siehe auch das kürzlich veröffentlichte Symantec Dossier – Linkliste am Ende dieser Analysen-Sammlung). Diese Sequenzen zielen darauf ab, die Profibus-Frames zu überwachen und können entsprechend natürlich auch aktiv eingreifen und Frames in das Profibus Netzwerk injizieren.

Diese Sequenz besteht aus den folgenden Komponenten:

• Statische Blöcke
  • DB888 bis DB891
  • FC1865 bis FC1868, FC1870, FC1871, FC1873, FC1874, FC1876 bis 1880
  • Ein gefährlicher DP_RECV Block
• Dynamische Blöcke
  • FC1869 (Eine Kopie der Original DP_RECV)
• Infizierte Blöcke
  • OB1, OB35

Abbildung 1: Datenflussplan der Sequenzen A/B

Um schnell feststellen zu können, ob ein PLC von den Sequenzen A oder B infiziert ist, müssen Sie den Simatic Manager in einer sauberen Betriebsumgebung öffnen und dann die Blöcke OB1 und OB35 genau untersuchen. Ein infizierter OB1 Block beginnt mit den folgenden Code-Anweisungen (diese sorgen für den Start der Infektions-Sequenz und möglicherweise auch für eine Art Kurzschluss bei der OB1 Ausführung unter bestimmten Bedingungen):

UC FC1865
POP
L DW#16#DEADF007
==D
BEC
L DW#16#0
L DW#16#0

Eine infizierte OB35 beginnt mit den folgenden Anweisungen (die auch zu einer Art Kurzschluss bei der OB35 Ausführung unter bestimmten Bedingungen führen können):

UC FC1874
POP
L DW#16#DEADF007
==D
BEC
L DW#16#0
L DW#16#0

Sequence C

Obwohl in beiden Stuxent Varianten vorhanden haben Analysen gezeigt, dass die Sequenz C nicht automatisch auf einen PLC geschrieben wird. Für die Sequenz C gibt es eine ganz spezifische Ausnahme, die während der Erzeugung des kritischen Code erstellt wird.

Dies könnte entweder daran liegen, dass der Code nicht gänzlich fertig gestellt oder eventuell auch absichtlich „auskommentiert“ – bspw. durch ein übrig gebliebenes Codefragement, das nicht mehr aufgerufen wird – wurde. Diese Sequenz C greift PLCs vom Typ 417 an. Die Aufgabe besteht im Auslesen und Schreiben von I/O (Input/Output) Informationen sowohl in gemappte I/O Speicherbereiche des PLC wie auch in die periphären I/Os.

Die Sequenz C besteht aus den folgenden Bestandteilen:

• Statische Blöcke
  • DB8062, DB8063
  • FC6055 bis FC6084
  • OB80 (wenn dieser nicht besteht)
• Dynamische Blöcke
  • DB8061
  • DB8064 bis DB8070
• Infizierte Blöcke
  • OB1
  • SDB0, SDB4 (modifiziert)

Abbildung 2: Datenflussplan der Sequenz C

 

Im Gegensatz zu den Sequenzen A und B – deren Infektionen über einen sepraten Thread kontrolliert werden – wird die Infektion hier eingeleitet, wenn ein Block der Art OB, DB, FC oder FB auf den PLC mittels eines ‘s7blk_write()’ API Aufrufes geschrieben wird.

Es macht den Eindruck, als könnte DB8061 auf der Basis einer existierenden SDB7 generiert werden, die Stuxnet auf einem anzugreifenden PLC vermutet. Die genauen Details bleiben aber unentdeckt, da der Code nicht komplett ist oder absichtlich verstümmelt wurde. In einigen Fällen könnte dies aber auch eine Erklärung für die Nutzung der OB80 sein – die Behandlung von Zeit-Problemen. Der Einsatz der Sequenz C hat vielleicht nicht zu den gewünschten Ergebnissen geführt und wurde deshalb deaktiviert. Wenn diese Hypothese stimmen sollte, stellt sich allerdings die Frage, warum die Fragmente im Code immer noch vorhanden sind?

SDB0 soll Datensätze aufzeichnen. Der Block wird zunächst geparst und anschliessend ein 10 Byte grosser Bereich in den Block eingefügt. Im Gegensatz zu den Sequenzen A und B werden aber anschliessend keine spezifischen Werte innerhalb des Blocks gesucht. Vielmehr kann nur die Aufzeichnung 13 des SDB0 modofiziert werden.

Der Zeitstempel des SDB0 ist inkrementell und wird aus Konsistenzgründen in einen speziellen Bereich der SDB4 repliziert. Die Sequenz C wird erzeugt. Zudem vergewissert sich Stuxnet, dass eine OB80 besteht. Falls dies nicht der Fall sein sollte, dann wird eine leere OB80 angelegt.

Neben dieser technischen Erklärung sollten Sie beachten, dass hier anscheinend nur sehr wenige Fingerprinting-Überprüfungen ablaufen, was äußerst besorgniserregend ist (im Gegensatz zu den Sequenzen A und B, die sehr umfangreich die SDB Blöcke überprüfen, um sicherzustellen, dass eine SDB0, SDB4 und SDB7 existiert). Wie aber bereits mehrfach erwähnt macht es den Eindruck, dass der Code, der für die Verwaltung dieser Sequenz zuständig ist, deaktiviert wurde.

Sollte es im schlimmsten Fall doch zu einer Infektion eines PLCs mit der Sequenz C kommen, dann würde der OB1 Block mit der folgenden Anweisung starten:

UC FC6083

Eine Erkennung von Stuxnet und entsprechende Erkennungs-/Abwehrempfehlungen für Windows sind nun seit einigen Monaten verfügbar. Dennoch erfordert die Erkennung und Säuberung infizierter PLCs nach wie vor zusätzliche Schritte. Zuerst müssen alle Stuxnet Windows Binaries entfernt werden, bevor die angeschlossenen PLCs nach den Schlüsselementen der Stuxnet Payloads untersuchen sollte:

• Die Sequenzen A und B greifen nur PLCs des Typs 315-2 an. Bei diesem Typ werden OB1 und OB35 infiziert.
• Die Sequenz C greift PLCs des Typs 417 an. Bei diesem Typ wird OB1 infiziert – aber diese Sequenz scheint von den Stuxnet Autoren deaktiviert worden zu sein.

Die Stuxnet P2P Komponente (von Liam O Murchu)

Die Symantec Security Response Labs untersuchen die Stuxnet Attacke bereits seit ihrer ersten Entdeckung Anfang des Jahres 2010. Die ersten Untersuchungen haben ergeben, dass analog zu Botnetzerken eine „Command and Control“ (C&C) Infrastruktur zur Kontrolle von Stuxnet eingesetzt wurde. Diese C&C Server wurden aber sofort vom Netz genommen, sobald die Entdeckung dieses Kontrollmechanismuses bekannt wurde.

Die tiefergehenden und nach wie vor anhaltenden Untersuchungen durch das Symantec Security Response Team haben ergeben, dass nicht nur eine Kontrolle von Stuxnet über C&C Infrastrukturen stattfindet, sondern das sich Stuxnet zudem über eine integrierte P2P (Peer-to-Peer) Komponete jederzeit selbständig mit Updates versorgt.

Mittels dieser P2P-Komponente bleiben die infizierten Maschinen untereinander in Kontakt und überprüfen gegenseitig, welche Maschine die aktuellste Version dieser Bedrohung installiert hat. Diejenige Maschine, auf der sich die aktuellste Version befindet, verteilt diese automatisch an alle anderen infizierten Maschinen. Somit ist der Wurm in der Lage, sich selbst ohne einen Kontakt mit dem zentralen C&C Server auf dem neuesten Stand zu halten. P2P Netzwerke werden oft aus den unterschiedlichsten Gründen eingesetzt und sind sehr schwierig vom Netz zu nehmen, da es keine zentrale Instanz, die man ausschaulten könnte, gibt. Die „Entwickler“ von Stuxnet waren sich durchaus bewusst, dass sie sehr schnell die Kontrolle über ihre eigenen „Command-and-Control“ (C&C) Server verlieren könnten. Deshalb haben sie gleich einen P2P Funktionalität integriert, um vor dieser Eventualität gewappnet zu sein.

Diese P2P Komponente funktioniert durch eine automatische Installation eines RPC Servers und eines Clients, wenn Stuxnet einen Computer infiziert. Nach der Installation wird sofort der RPC Server gestartet und dieser wartet dann auf eine Verbindungsanfrage. Jeder andere infizierte Computer in einem Netzwerk kann sich nun mit diesem RPC Server verbinden und anfragen, welche Version der Bedrohung auf dem Remote-Rechner installiert ist.Wenn die Version des Remote Rechners neuer ist als auf der anfragenden Maschine, dann startet diese Maschine eine Anfrage für diese neue Version und führt bei sich ein entsprechendes Update auf die neue Version durch. Wenn die Version des Remote Rechners älter ist als die Version auf der anfragenden Maschine, dann erstellt die anfragende Maschine eine Kopie von der eigenen aktuelleren Version und sendet diese an den Remote Rechner, der dann ein eigenes Update ausführt. Auf diese Weise kann ein Update auf jede infizierte Maschine in diesem Netzwerk verteilt werden und auch eventuell an alle anderen infizierten Maschinen in anderen Netzwerken.

Sämtliche P2P Anfragen werden über den RPC abgewickelt, wie die nachfolgende Abbildung zeigt.

Der RPC Server bietet die folgenden Routinen:

• 0: Gibt die Versionsnummer der installierten Stuxnet Version an
• 1: Empfängt eine EXE-Datei und führt diese (via Injection) aus
• 2: Lädt Module und führt Export durch
• 3: Injiziert Code in Isass und führt diesen aus
• 4: Erstellt die letzte Version von Stuxnet und sendet diese an die Remote Maschine
• 5: Erstellt einen Prozess
• 6: Datei lesen
• 7: Datei verwerfen
• 8: Datei löschen
• 9: Schreiben von Daten Aufzeichnungen

Diese Routinen werden folgendermaßen aufgerufen:

(Beispiel einer älteren Client Version, die nach der aktuellen Client Version von Stuxnet via P2P anfrägt)

Der RPC Client führt die folgenden Anfragen aus:

1. Aufruf der RPC  Funktion 0, um die Remote Versionsnnummer zu erhalten
2. Überprüfung, ob die Remote Version neuer als die lokale Version ist
3. Wenn die Remote Version neuer ist, dann Aufruf der RPCF unktion 4 und die letzte Stuxnet Version anfragen
4. Abruf der aktuelleren Stuxent Version
5. Lokale Installation (über eine Prozess Injektion) 3a

Alternativ, wenn die Remote Version älter als die installierte Version sein sollte:
Schritt 4: Eine eigenständige EXE-Version der installierten Stuxnet Version erzeugen
Schritt 5: Diese eigenständige Version durch Aufruf der RPC Funktion 1 an die Remote Maschine senden

All dies bedeutet, dass selbst wenn die „Command-and-Control“ Server von Stuxnet komplett abgeschaltet wurden, die Attacke nach wie vor
funktionstüchtig ist und die Updates und Kontrolle des Wurms über den P2P Kommunikationskanal ablaufen kann.

Quelle: Symantec Security Response Weblog / Symantec Connect

Weitere Updates und Artikel über Stuxnet:

• Kaspersky Labs Stuxnet / Duqu – Evolution der Treiber

• Vorläuder für Stuxnet 2 gefunden

• ENISA Analyse der Stuxnet Malware: Eine Paradigmenwechsel in der Bedrohungslandschaft und für den Schutz der Informations-Infrastruktur (Aktuelle Stellungnahme der European Network and Information Security Agency zum Thema Stuxnet)

• Symantec Whitepaper zu W32.Stuxnet (ausführliches Whitepaper mit aktuellen Studien zum Stuxnet-Wurm)

• BSI bietet Handlungsempfehlungen zur Überprüfung auf Manipulationen durch Stuxnet-Schadsoftware (einschliesslich Downloadlink zur Erkennungssoftware von Siemens)

• Symantec Security Response: Verschiedene Analysen über den Stuxnet Wurm (Sehr ausführliche und umfangreiche Analysen zu Stuxnet)

• Büchse der Pandora: Stuxnet läutet das Zeitalter der Cyberkriegsführung ein

• Gestohlene Stuxnet-Zertifikate verunsichern die IT-Welt