Stuxnet, Duqu und Flame – der virtuelle Krieg hat begonnen

Anatomie eines Cyberkriegs
Kommentare

Cyberangriffe sollen das iranische Atomprogramm bremsen und konventionelle Angriffe unnötig machen. Damit haben die USA und Israel aber eine digitale Büchse der Pandora geöffnet. 

Stuxnet, Duqu und Flame haben eines gemeinsam: Sie wurden von den USA und Israel entwickelt, um das iranische Atomprogramm zu sabotieren bzw. auszuspionieren. Werfen wir mal einen Blick auf die Entwicklung und die Folgen. Als erster Schädling wurde Stuxnet entdeckt.

Stuxnet, der Saboteur

Erstmals aufgefallen ist Stuxnet, als bzw. weil er die von Microsoft am 2. August 2010 außer der Reihe gepatchte so genannte „Shortcut-Lücke“ ausnutzte. Anfangs sah alles nach einem mehr oder weniger alltäglichen Wurm aus: Am 15. Juli 2010 gab es erste Berichte über eine mögliche neue 0-Day-Schwachstelle in Windows, die von einem sich über USB-Sticks verbreitenden Wurm ausgenutzt wird[1][2]. Die ersten Exemplare dieses Wurms waren vom weißrussischen Antiviren-Hersteller VirusBlokAda am 17. Juni 2010 entdeckt worden [3]. Das Besondere an diesem Wurm: Er wurde nicht wie damals sonst üblich über die Autorun-Funktion installiert, sondern nutzte eine 0-Day-Schwachstelle beim Verarbeiten von Shortcuts (Verknüpfungen, .lnk-Dateien): Bei der Anzeige des dazugehörigen Icons, z. B. im Windows Explorer, startete ohne weiteres Zutun des Anwenders der Schadcode. Vom Wurm installiert wurden zwei Treiber mit Rootkit-Eigenschaften, die beide mit einer gültigen digitalen Signatur der Realtek Semiconductor Corp. versehen waren [4]. Ziel der Angriffe waren SCADA-(Supervisory-Control-and-Data-Acquisition-)Systeme zur Überwachung und Steuerung technischer Prozesse von Siemens. Der Wurm wurde z. B. von Sophos als W32/Stuxnet-B bezeichnet und konnte ein voll gepatchtes Windows-7-System infizieren [5]. Seine Verbreitung war anfangs laut Kaspersky nur im Iran, Indien und Indonesien hoch, dort wurden jeweils mehr als 5000 der weltweit insgesamt über 16 000 Infektionen gezählt, während es in Russland nur ca. 150 und in China 5 waren [6]. Schon am 16. Juli 2010 gab es weitere Informationen: Microsoft veröffentlichte ein Security Advisory und eine Beschreibung der Stuxnet-Familie [7][8]. Die angegriffenen SCADA-Systeme von Siemens nutzten fest vorgegebene Benutzernamen und Passwörter für den Administrator-Account der Datenbank, die laut Siemens nicht geändert werden sollten [9][10]. Siemens veröffentlichte ein Security Advisory, dem zufolge nur sehr wenige Kunden von den Angriffen betroffen waren [11]. Am 19. Juli 2010 wurde vom Internet Storm Center (ISC) die Gefahrenwarnstufe (Infocon Level) vom Normalwert Grün auf Gelb erhöht, um auf die drohenden Angriffe auf die 0-Day-Schwachstelle aufmerksam zu machen [12]. Am 20. Juli 2010 wurde von Microsoft eine Aktualisierung des Security Advisory angekündigt [13]: Ein „Fix it“-Tool zum Durchführen eines Workarounds stand bereit. Das ISC senkte die Warnstufe wieder zurück auf Grün: Das Ziel der Erhöhung war erreicht, die Gefahr durch die Schwachstelle allgemein bekannt [14]. Am 29. Juli 2010 kündigte Microsoft für den 2. August 2010 ein außerplanmäßiges Update an, um die zu Schwachstelle beheben [15]. Die Entwicklung der Bedrohung durch Angriffe auf bzw. über die Schwachstelle wurde vom Microsoft Malware Protection Center beschrieben [16]. Inzwischen nutzten schon fünf Schädlingsfamilien die Schwachstelle aus. Am 2. August 2010 wurde dann wie angekündigt das Update veröffentlicht [17]

Das war erst der Anfang

Bisher dahin war Stuxnet ein mehr oder weniger alltäglicher Wurm, der Daten sammelt. Das einzig Besondere waren die Ausnutzung der 0-Day-Schwachstelle und der Angriff auf SCADA-Systeme. Entsprechend richtete sich das Augenmerk anfangs auch auf die Gefahr, dass andere Schädlinge die 0-Day-Schwachstelle ebenfalls ausnutzen könnten, bevor der Patch veröffentlicht wird. Aber nach und nach kamen weitere Details ans Licht, nach denen sich der Wurm letztendlich als Waffe im Cyberwar herausstellte.

Manipulation der SCADA-Systeme

Am 19. August 2010 meldete Symantec, dass der Wurm nicht nur Informationen ausspähen, sondern sich auch in Form eines Rootkits in die SCADA-Systeme einschleusen und diese manipulieren konnte [18]. Siemens untersuchte den Wurm ebenfalls genauer und stellte fest, dass ganz bestimmte Systeme manipuliert werden können [11]. Welche, wurde nicht verraten. Der Wurm wurde zwar in verschiedenen Systemen gefunden (15 insgesamt mit Stand vom 17. September 2010), nicht aber in solchen, auf die er es abgesehen hat. Betrachtete man die Verbreitung des Wurms, fiel die Häufung von Infektionen im Iran auf [6][19][20].

Ein Wurm, vier 0-Day-Schwachstellen

Schon die Tatsache, dass SCADA-Systeme angegriffen wurden, und dann auch noch ganz bestimmte, wies auf einen besonders aufwändigen Schädling hin. Für so einen Angriff ist sehr spezifisches Fachwissen erforderlich. Ein weiterer Beweis für den bei der Entwicklung betriebenen Aufwand: Es wurden gleich mehrere 0-Day-Schwachstellen verwendet [21]. Außer der schon vom Wurm Conficker genutzten RPC-Schwachstelle wurde eine 0-Day-Schwachstelle im Printspooler zur Verbreitung im lokalen Netz ausgenutzt. Zwei weitere beim Verarbeiten von Tastaturlayouts und im Task-Scheduler wurden zur Privilegieneskalation genutzt. Zusammen mit der Shortcut-Lücke macht das vier 0-Day-Schwachstellen auf einmal, was ein neuer Rekord war [22]. Die Schwachstelle im Printspooler nimmt dabei eine Sonderstellung ein, da sie streng genommen keine 0-Day-Schwachstelle war: Sie wurde bereits 2009 beschrieben, aber nicht an Microsoft gemeldet. Dadurch war sie Microsoft bis zur Ausnutzung durch Stuxnet unbekannt [23], [24].

Viel Entwicklungsaufwand für einen einzigen Wurm

Symantec hat verschiedene Varianten des Wurms analysiert und verglichen und dabei festgestellt, dass der Wurm seit Juni 2009 entwickelt wurde [25]. Die Nutzung der 0-Day-Schwachstellen war erst in der letzten Version hinzugekommen, alle Varianten konnten aber schon SCADA-Systeme ausspähen und wohl auch manipulieren. Die Verbreitung über USB-Sticks erfolgte erst seit März 2010 über die „Shortcut-Lücke“, davor versuchte der Wurm, sich über die Autorun-Funktion zu verbreiten [26]. Ein weiterer Ansatz zur Verbreitung von Stuxnet besteht in der Manipulation von „Step 7“-Projekten, die zum Programmieren der speicherprogrammierbaren Steuerungen der Siemens-SCADA-Systeme verwendet werden: Eine eingefügte DLL-Datei mit dem Schadcode wird beim Öffnen des Projekts ausgeführt, vergleichbar mit DLL-Preloading-Angriffen [27]. Eine weitere Eigenheit von Stuxnet, die für Schadsoftware damals noch ungewöhnlich war: Ein vom Wurm verwendeter Treiber trug eine korrekte Signatur [28]. Anfangs von Realtek [2], später von JMicron Technology. Die verwendeten Zertifikate wurden nach der Entdeckung des Missbrauchs zurückgezogen. Wie die Angreifer an die zum Signieren notwendigen privaten Schlüssel gelangt sind, ist nie bekannt geworden. Vermutlich wurden sie bei den rechtmäßigen Eigentümern ausgespäht; entsprechende Schadsoftware existiert [29].

Das eigentliche Ziel

Eigentliches Ziel von Stuxnet war nicht die Infektion der Windows-Rechner, sondern der darüber kontrollierten SCADA-Systeme [30]. Dazu manipulierte der Wurm deren Programmable Logic Controller (PLC) und fügte ein Rootkit ein. Dabei ging Stuxnet den Weg über das schon oben erwähnte Step 7: Schadcode zur Manipulation der Kommunikation zwischen Step 7 und PLC wurde in eine DLL der Programmierumgebung eingefügt, danach konnte der Wurm darüber auf den PLC zugreifen und das Rootkit einschleusen. Die SCADA-Systeme machten es Stuxnet besonders leicht, da deren Default-Passwort laut Siemens nicht geändert werden sollte [10]

Welche Industrieanlage sucht Stuxnet?

Stuxnet soll ganz bestimmte Industrieanlagen manipulieren. Aber welche, und wo stehen die? Zwar wurde vom Iran bestätigt, dass „the IP addresses of 30 000 industrial computer systems infected by this malware have been detected“, aber das Problem hatten auch andere Staaten. Es ist auch völlig egal, wie viele oder auch wenige Rechner in einem Staat mit Stuxnet infiziert wurden, interessant sind nur die infizierten SCADA-Systeme, und davon hat Siemens bis zum 1. Oktober 2010 lediglich 15 registriert, fünf davon sollen sich in Deutschland befinden [32]. Das eigentliche Ziel war sehr wahrscheinlich nicht darunter, da die Infektionen keine Folgen für die Systeme gehabt haben sollen. Berichte, dass der iranische Atomreaktor in Bushehr oder die Uranzentrifugen in Natanz das Ziel des Angriffs waren, basierten damals nur auf Vermutungen [33], [34] .

Weitere Puzzleteile

Im November 2010 gab es dann weitere Puzzleteile auf dem Weg zum eigentlichen Angriffsziel: Symantec fand heraus, dass es Stuxnet auf die Steuerung bestimmter Frequenzwandler zweier Hersteller abgesehen hat: Einer mit Sitz in Finnland, der andere mit Sitz im Iran [36]. Die Frequenzwandler werden zur Steuerung von Motoren verwendet, wobei in diesem Fall die Frequenz zwischen 807 Hz und 1210 Hz liegen muss. Stuxnet ändert die Ausgangsfrequenzen der Wandler und damit die Drehzahl der gesteuerten Motoren für kurze Intervalle über einen Zeitraum von Monaten. Die Anzahl möglicher Systeme konnte damit deutlich eingegrenzt werden, und Symantec wies darauf hin, dass entsprechende Frequenzwandler in den USA einer Exportregulierung durch die Nuclear Regulatory Commission unterliegen, da sie u. a. zur Urananreicherung eingesetzt werden können. Alles lief also auf die iranische Urananreicherungsanlage in Natanz als Angriffsziel hinaus. Laut Siemens meldeten bis zum 22. November 2010 22 Kunden „weltweit aus dem industriellen Umfeld“ infizierte Systeme. Alle ohne Auswirkungen auf den Betrieb der zugehörigen Anlagen [11]. Der letzte Stand bei Siemens sind 24 Kunden bis zum 11.3.2011. Ob es danach wirklich keine Neuinfektionen mehr gab ist natürlich nicht bekannt.

Die Katze ist aus dem Sack

Am 15. Januar 2011 meldete die New York Times, dass Stuxnet ein gegen die iranischen Urananreicherungsanlagen gerichtetes Gemeinschaftsprojekt der USA und Israels sei [37]. Die im SCADA-System ausgenutzten Schwachstellen wurden vom Idaho National Laboratory und dem US-amerikanischen Department of Homeland Security in Zusammenarbeit mit Siemens im Rahmen eines Projekts entdeckt, in dem es eigentlich gerade um die Abwehr von Cyberangriffen ging [38]. Der Schadcode wurde sorgfältig auf die Urananreicherungsanlagen des Iran abgestimmt, wobei Israel die eigenen Atomanlagen für Tests bereitstellte und Informationen über die Uranzentrifugen beisteuerte. Es wurde sehr genau darauf geachtet, dass der Wurm nur eine ganz bestimmte Anlage, nämlich eine mit 984 angebundenen Zentrifugen, angreifen kann. Die Schadfunktion von Stuxnet besteht aus zwei Komponenten: Zum einen werden die Zentrifugen durch lang andauernde Manipulationen der Regelungssysteme nach und nach zerstört, zum anderen den Überwachungsfunktionen korrekte Werte vorgegaukelt, sodass die Manipulationen nicht erkannt werden. Und das mit der Zerstörung scheint auch funktioniert zu haben, zumindest hat der Iran eine passende Anzahl Zentrifugen – 984 – außer Betrieb genommen.

Wie kam der Wurm in die Urananreicherungsanlage?

Nachdem das Ziel bekannt war, blieb die Frage, wie der Wurm in die Urananreicherungsanlage gelangte. Im Februar 2011 erklärte Symantec, dass anfangs fünf Organisationen angegriffen wurden, über die Stuxnet dann in die iranischen Atomanlagen gelangen sollte [39]. Von diesen fünf Organisationen aus, die alle Büros im Iran haben, infizierte Stuxnet dann insgesamt 12 000 Rechner. Die Angriffe fanden im Juni und Juli 2009 sowie im März, April und Mai 2010 statt, wobei drei Varianten (Juli 2009, März und April 2010) zum Einsatz kamen. Eine vermutete vierte Variante kam nicht zum Einsatz. Warum, ist natürlich nicht bekannt. Anfang April 2012 gab es eine neue Erklärung, wie Stuxnet in die Urananreicherungsanlage gelangte: Laut ISSSource hat ein Mitarbeiter der Anlage im Auftrag des israelischen Auslandsgeheimdienstes Mossad den Wurm auf einem präparierten USB-Stick in die Anlage eingeschleust [40], was im Juni 2012 bestätigt wurde [41]. Wie das zu Symantecs Feststellungen passt, ist noch nicht bekannt.

Stuxnet war erfolgreich!

Am 11. Juli 2011 veröffentlichte Kim Zetter auf Wired.com die Geschichte der Erforschung des Wurms [42]. Er beginnt mit der Beobachtung der IAEA-Inspekteure der iranischen Urananreicherungsanlagen, dass der Iran Anfang 2010 deutlich mehr Uranzentrifugen als eigentlich üblich ersetzt hat. Wieso, wurde vom Iran nicht angegeben, und die Inspekteure wussten damals noch nicht, dass im Juni 2009 ein Wurm auf die Urananreicherungsanlagen angesetzt worden war. Laut einem Artikel auf Threatpost vom 22. Juli 2011 war der Iran angeblich nicht in der Lage, Stuxnet zu entfernen und die Urananreicherungsanlage mit dem vorhandenen Zentrifugen wieder in Betrieb zu nehmen [43], [44]. Stattdessen werden neue Zentrifugen installiert, die den Anreicherungsprozess beschleunigen sollen. 

Das Eingeständnis

Am 1. Juni 2012 berichtete die New York Times, dass der Cyberangriff auf den Iran, in dessen Folge Stuxnet entwickelt und eingesetzt wurde, 2006 von US-Präsident George W. Bush angeordnet worden war [41], [45]. An der Entwicklung war Israel beteiligt, da man dort wichtige Informationen über das Ziel besaß. Bushs Nachfolger Barak Obama führte die Aktion dann weiter – wohl wissend, dass damit eine Grenze überschritten wurde und gerade die USA besonders verwundbar sind, sollte es zu einem Cyberangriff kommen. Stuxnet sollte die Urananreicherungsanlage in Natanz niemals verlassen. Durch einen Programmierfehler gelangte er auf das Notebook eines Technikers, als das mit den Zentrifugen verbunden war. Als der Techniker das Notebook später mit dem Internet verband, erkannte der Wurm nicht, dass er sich in einer anderen Umgebung befand, und fuhr fort, sich zu verbreiten. Die entsprechenden Änderungen am Code sollen von Israel vorgenommen worden sein. Warum, ist den USA angeblich nicht bekannt. Stuxnets Shortcut-Verbreitungsroutine stellte übrigens am 24. Juni 2012 den Betrieb ein [46]. Verantwortlich dafür war ein fest im Konfigurationscode des Wurms vorgegebener Parameter. Das war vermutlich als Sicherheitsmaßnahme gedacht – dummerweise war der Wurm schon lange vorher im Internet unterwegs. Kommen wir nun zum nächsten im Internet entdeckten Cyberwar-Schädling: Duqu.

Aufmacherbild: Web terrorism target von Shutterstock / Urheberrecht: alexskopje

[ header = Duqu, der kleine Spion ]

Duqu, der kleine Spion

Am 14. Oktober 2011 informierte das Laboratory of Cryptography and System Security (CrySyS) der Budapest University of Technology and Economics Symantec über einen neuen Schädling. Da er Dateien mit dem Prefix ~DQ anlegt, wurde er W32.Duqu genannt [47], [48]. Duqu enthält zum Teil mit Stuxnet identischen Code, vor allem im zugehörigen Treiber. Die Übereinstimmungen gehen so weit, dass F-Secures Backend-Systeme den neuen Schädling als Stuxnet erkannten [49]. Da der Stuxnet-Sourcecode bisher nicht veröffentlicht wurde, müssen die Duqu-Entwickler mit den Stuxnet-Entwicklern identisch sein oder zumindest in Verbindung stehen.

Ein RAT ohne Verbreitungsroutine 

Duqu enthält jedoch keinen Code für Angriffe auf SCADA-Systeme, sondern ist „nur“ ein Remote Administration Toolkit, über das die Angreifer die Kontrolle über den angegriffenen Rechner übernehmen können. Im Gegensatz zu Stuxnet besitzt Duqu auch keine Verbreitungsroutinen, der Schädling wurde nur im Rahmen gezielter Angriffe auf eine geringe Anzahl von Organisationen eingesetzt. Wie Duqu eingeschleust wurde, war anfangs nicht bekannt. Duqu besteht aus drei Dateien: Einem Treiber, einer DLL (die ihrerseits mehrere Dateien enthält) und einer Konfigurationsdatei. Diese Dateien werden von dem anfangs nicht entdeckten Installationsprogramm installiert, das den Treiber so registriert, dass er beim Systemstart gestartet wird. Der Treiber schleust dann die DLL in services.exe ein, wo sie weitere Komponenten aus sich selbst entpackt und in weitere Prozesse einschleust. Eine Variante des Treibers war mit einer gültigen Signatur eines von Symantec nicht genannten Taiwanesischen Unternehmens versehen. Das zugehörige Zertifikat läuft erst am 2. August 2012 ab, wurde aber am 14. Oktober 2011 zurückgerufen. 

Kommunikation über HTTP/HTTPS

Nach der Installation verbindet sich Duqu über HTTP und HTTPS mit einem Command-&-Control-Server. Die Angreifer können dann weiteren Code einschleusen, z. B. einen Infostealer. Die gesammelten Daten werden in einer nur leicht verschlüsselten und komprimierten Datei gespeichert, die später von den Angreifern heruntergeladen wird. Die Kommunikation erfolgt über ein eigenes Protokoll, wobei die hoch- und runtergeladenen Daten als .jpg-Dateien getarnt sind [50]. Der Schadcode ist so konfiguriert, dass er sich nach 36 Tagen selbst entfernt. Von Symantec wurden mehrere Duqu-Varianten gesammelt, davon anfangs zwei analysiert. Aufgrund der Kompilier-Zeiten konnte die Entwicklung von Duqu nachvollzogen werden. Die erste Variante wurde bereits im Dezember 2010 eingesetzt und war auch im September 2011 noch aktiv, die zweite Variante basiert auf dem gleichen Code, der Treiber wurde aber im Juli 2011 signiert, gleichzeitig wurde der Schadcode angepasst. Auch der nachträglich eingeschleuste Infostealer wurde im Juli 2011 entwickelt. 

Angriffe auf Zertifizierungsstellen

McAfee hat eine andere Variante als Symantec analysiert, die für Angriffe auf Zertifizierungsstellen (Certificate Authorities, CAs) verwendet wurde [51]. Dieser Schädling war mit einer korrekten Signatur des Unternehmens Cmedia Electronics in Taipei in Taiwan versehen. Ob es sich um das gleiche Unternehmen wie im Fall der von Symantec untersuchten Versionen handelt, ist nicht bekannt, aber sehr wahrscheinlich. McAfee hat außer dem Infostealer zwei weitere nachgeladene Module entdeckt, die u. a. dazu dienen, Sicherheitsprogramme, insbesondere bestimmte Virenscanner, zu deaktivieren. Und auch Kaspersky berichtet über Angriffe auf Zertifizierungsstellen, anscheinend brauchen die Duqu/Stuxnet-Hintermänner neue Zertifikate zum Tarnen ihres Schadcodes [52]. Das Hauptziel der Angriffe bleibt aber unklar, die Angriffe auf die Zertifizierungsstellen scheinen nur ein Nebeneffekt zu sein.

Und wieder eine 0-Day-Schwachstelle

Am 2. November 2011 berichtete Symantec über das Einfallstor von Duqu: Ein per E-Mail an die Opfer geschicktes Word-Dokument nutzt eine 0-Day-Schwachstelle im Windows-Kernel aus, um den Schadcode einzuschleusen [53], [54]: Beim Verarbeiten von in Dokumenten oder Webseiten eingebetteten True Type Fonts konnte es zu einem Pufferüberlauf kommen, über den eingeschleuster Code ausgeführt werden konnte. Die 0-Day-Schwachstelle wurde am 13. Dezember 2011 behoben [55]. War ein Rechner erst mal unter der Kontrolle der Angreifer, konnten sie den Schadcode dann z. B. über Dateifreigaben auf andere Rechner verbreiten. Gelangt der Schädling dabei auf Rechner, die keine Internetanbindung besitzen, wird die Konfiguration geändert: Statt direkt eine Verbindung zum Command-&-Control-Server aufzubauen, wird ein Filesharing-C&C-Protokoll zur Kommunikation mit einem anderen kompromittierten Rechner genutzt, der eine Verbindung zum C&C-Server aufbauen kann. Wie die Infektion abläuft, wenn nur auf dem angegriffenen Rechner Informationen gesammelt werden, hat Kaspersky anhand eines beobachteten Angriffs beschrieben [56]

Duqu lebt

Während Stuxnet vermutlich nicht mehr aktiv ist, wurde von Duqu im März 2012 eine neue Variante der Loader-Komponente entdeckt, die am 23. Februar 2012 kompiliert wurde [57]. Das war besonders bemerkenswert, weil die Angreifer am 20. Oktober 2011 alle zuvor genutzten C&C-Server gelöscht haben, um ihre Spuren zu verwischen [58]. Insgesamt wurden weltweit weniger als 50 Infektionen mit Duqu entdeckt (was nicht zwingend bedeutet, dass es nicht noch mehr gab, die nicht veröffentlicht wurden), die meisten davon im Iran [58]. Das sollte wohl reichen, um den Iran als Angriffsziel zu identifizieren. Zumal wahrscheinlich eine Vorversion von Duqu, genannt „Star“, im Iran entdeckt wurde [59]. Da Duqu bereits 2007 und damit vor Stuxnet entwickelt wurde, kann man davon ausgehen, dass Duqu u. a. dazu diente, die für Stuxnet benötigten Informationen auszuspionieren [60]. Und nun kommen wir zum neuesten Cyberwar-Schädling: Flame.

[ header = Flame, die digitale eierlegende Wollmilchsau ]

Flame, die digitale eierlegende Wollmilchsau

Diesmal ist die Suche nach dem Angriffsziel nicht nötigt, da sich das Opfer zuerst gemeldet hat: Am 28. Mai 2012 hat das Iran National CERT (MAHER) gemeldet, dass es Angriffe durch einen neuen Wurm namens Flame (auch Flamer oder Skywiper genannt) gab, bei dem es sich um einen Nachfolger von Stuxnet handeln soll [61], [62]. Die Fähigkeiten des Wurms sind beachtlich:

 

  • Verbreitung über mobile Massenspeicher über präparierte autorun.inf-Dateien und die Shortcut-Schwachstelle, beides auch von Stuxnet genutzte Taktiken
  • Verbreitung in lokalen Netzen, u. a. über die von Stuxnet ausgenutzte Schwachstelle im Printspooler und mithilfe ausgespähter Passwörter über Windows-Dateifreigaben
  • Sniffen im Netzwerk, Erkennen von Netzwerkressourcen und Sammeln von Passwörtern
  • Durchsuchen der Festplatten der infizierten Rechner nach bestimmten Dateien und Inhalten
  • Anfertigen von Screenshots, wenn bestimmte Prozesse oder Fenster aktiv sind
  • Aufnehmen von Umgebungsgeräuschen mit dem eingebauten Mikrofon des Rechners
  • Übertragen der gesammelten Daten an C&C-Server, wobei mehr als 10 Domains als C&S-Server verwendet werden und die Daten über SSH und HTTPS gesichert übertragen werden
  • Umgehen bekannter Virenscanner etc.
  • Infizieren von Windows-XP-, Vista- und 7-Systemen sowie von lokalen Netzen im großen Maßstab

 

Das CrySyS Lab, das schon Duqu entdeckt hatte, hat eine Analyse veröffentlicht und vermutet, der Wurm wäre „developed by a government or nation state with signigficant budget and effort, and may be related to cyber warfare activities“ [63]. Flame ist ein typischer „Jäger und Sammler“, es gibt wohl kaum eine Information oder Datei, die der Schädling nicht sammelt [64]. Flame schien schon bei seiner Entdeckung eine Art Super-Überraschungsei für Cyberkriminelle zu sein; der Schädling erfüllt etliche Wünsche auf einmal: Er ist eine Backdoor, ein Trojaner, ein Wurm, lässt sich durch eine Vielzahl von Plug-ins nahezu beliebig erweitern, und wie er eingeschleust wird, ist bisher (Stand 08.07.2012) noch nicht mal bekannt [65], [66]. Nebenbei ist Flame auch noch sehr groß, über 20 MB sind für einen Schädling eine beachtliche Größe. Die ergibt sich u. a. durch die Verwendung verschiedener Libraries wie zlib, libbz2 und ppmd, SQLite3 und einer Lua Virtual Maschine. Lua ist eine Skriptsprache, in der die „high order logic“ für viele Teile von Flame geschrieben wurde, während die Angriffs-Subroutinen und Libraries in C++ geschrieben wurden.

Die Antivirenhersteller haben Flame übersehen

Flame ist groß und hat einen beachtlichen Funktionsumfang. Da sollte man ja eigentlich erwarten, dass der Schädling sehr schnell von den Antivirenherstellern entdeckt wird. Genau das Gegenteil war aber der Fall: Der Schadcode wurde von den automatischen Systemen registriert und teilweise zur manuellen Analyse vorgemerkt, wirklich angesehen hat ihn sich aber lange Zeit niemand. Kaspersky begründet das so: „The large size of the malware is precisely why it wasn’t discovered for so long. In general, today’s malware is small and focused. It’s easier to hide a small file than a larger module. Additionally, over unreliable networks, downloading 100 K has a much higher chance of being successful than downloading 6 MB.“ [65]. Mikko H. Hypponen von F-Secure hat eine Stellungnahme zur Unfähigkeit der Antivirenhersteller abgegeben [67], die bei Bruce Schneier auf Widerspruch stößt („I don’t buy this“) [68]. F-Secures Antwort darauf fiel mager aus [69]. Von McAfee gibt es eine Übersicht darüber, wann einige der Flame-Dateien bei VirusTotal geprüft wurden [70]. VirusTotal prüft hochgeladene Dateien mit einer Vielzahl von Virenscannern und leitet die Dateien ggf. an die Antivirenhersteller weiter. Die haben die Flame-Dateien aber nicht als neue Schadsoftware erkannt. Im Grunde war an Flame nichts besonderes, wenn man mal vom Angriffsziel absah. Aber dann wurde die für Cyberwar-Schädlinge schon obligatorische 0-Day-Schwachstelle gefunden, und plötzlich sah alles ganz anders aus: Flame nutzt eine Schwachstelle in der Windows-Update-Funktion, um sich mithilfe gefälschter Zertifikate als angebliches Microsoft-Update im lokalen Netz zu verbreiten. Eine genaue Beschreibung der Schwachstelle finden Sie in meinem Blog, hier fehlt der Platz dafür [71]. Diese 0-Day-Schwachstelle entspricht einem Super-GAU. Die Möglichkeit, Schadcode ungeprüft als Windows-Update installieren zu lassen, ist das Beste, was einem Angreifer passieren kann. 

Flame und die Verbindung zu Stuxnet

Kaspersky hat eine Verbindung zwischen Flame und Stuxnet gefunden [72]. Die so genannte „Resource 207“ von Stuxnet ist eine verschlüsselte DLL-Datei, die eine PE-Datei enthält. Und diese PE-Datei wurde nun als Prototyp eines Flame-Plug-ins identifiziert. Dabei handelt es sich um Code zur Verbreitung über mobile Massenspeicher mithilfe der autorun.inf, der nur in der Stuxnet-Version von 2009 verwendet und 2010 durch neuen Code ersetzt wurde. Das Flame-Modul nutzt u. a. eine damals unbekannte Privilegieneskalations-Schwachstelle aus, enthielt also einen 0-Day-Exploit. Kaspersky geht davon aus, das Stuxnet und Flame spätestens seit 2007/2008 von zwei unabhängigen Gruppen entwickelt wurden und 2009 Sourcecode von Flame für Stuxnet übernommen wurde. Seit 2010 wurden die Schädlinge dann wieder unabhängig voneinander entwickelt. Dabei gab es zumindest einen gewissen Informationsaustausch, da die gleichen Schwachstellen ausgenutzt wurden. 

Flame im Selbstmord-Modus

Nachdem Flame entdeckt wurde, wurde dessen Hintermännern wohl der Boden zu heiß, und sie aktivierten Anfang Juni eine weitere Funktion von Flame [73]: Einige Command-&-Control-Server lieferten eine Datei mit dem Namen browse32.ocx aus, deren einzige Aufgabe das restlose Entfernen von Flame und allen Komponenten ist. Das Modul löscht nach und nach alle zu Flame gehörenden Dateien und zum Schluss sich selbst. Eigentlich wäre für diese Aufgabe das Modul Suicide mit einem identischen Funktionsumfang zuständig. Wieso die Angreifer statt dessen das erst am 9. Mai 2012 erzeugte Modul browse32.ocx nutzten, ist (natürlich) nicht bekannt. Das neue Modul wurde übrigens in einem Honeypot gefunden, auf infizierten Rechnern ist es nach getaner Arbeit ja nicht mehr vorhanden. Die Command-&-Control-Infrastruktur selbst hatte bereits am 28. Mai zumindest teilweise den Betrieb eingestellt [74]. Anhand der registrierten Domainnamen konnte der Beginn der Flame-Angriffe bis 2008 zurückverfolgt werden. 

Die Urheber

Am 19. Juni 20102 berichtete die Washington Post, dass die USA und Israel Flame gemeinsam entwickelt haben [75]. Das Ziel des Cyberangriffs: Irans Fähigkeiten zum Entwickeln einer Atombombe verlangsamen. Mit den von Flame gesammelten Informationen sollten weitere Cyberangriffe vorbereitet werden. Einer davon dürfte Stuxnet sein

Die Folgen

Die Cyberangriffe richten sich gegen den Iran bzw. mit dem iranischen Atomprogramm in Verbindung stehende Organisationen. Dass Stuxnet „ausgerissen“ ist und sich über das Internet auf unbeteiligte Rechner verbreitet hat, war von den USA nicht vorgesehen. Dann sollte für alle anderen Benutzer ja keine Gefahr bestehen, oder? Leider ist das ganz und gar nicht der Fall. George W. Bush und Barak Obama haben in der Tat eine Grenze überschritten und eine digitale Büchse der Pandora geöffnet. Indem sie die Cyberangriffe auf den Iran genehmigten, gaben sie allen anderen eine Rechtfertigung für die Entwicklung entsprechender Schadsoftware. Vermutlich gibt es jetzt ein digitales Wettrüsten, mit der Folge, dass viele Schwachstellen nicht mehr an die Hersteller gemeldet, sondern von den Geheimdiensten etc. gehortet werden. Und das ist fatal. Was wäre passiert, wenn z. B. die 0-Day-Schwachstelle in Windows Update nicht von US-amerikanischen und israelischen Geheimdiensten, sondern von Cyberkriminellen entdeckt und ausgenutzt worden wäre? Die hätten dann ungestört Schadsoftware verbreiten können. Schadsoftware, die als angebliches Microsoft-Update von den Virenscannern vermutlich nicht beachtet worden wäre. Hinzu kommt, dass man diese Schwachstelle im schlimmsten Fall nicht beheben kann: Wenn die Update-Funktion selbst nicht mehr vertrauenswürdig ist, gibt es keine Möglichkeit, sie zuverlässig zu patchen. Ein angenommener Schädling würde die entsprechenden Updates einfach unterdrücken oder manipulieren. Es war also Glück, dass die Schwachstelle von den Geheimdiensten und nicht zuerst von Cyberkriminellen entdeckt und ausgenutzt wurde.

Einmal ist keinmal 

Nur weil jemand eine Schwachstelle findet und geheim hält oder an den Hersteller meldet, bedeutet das noch lange nicht, dass nicht ein Dritter die gleiche Schwachstelle finden und ausnutzen könnte, bevor ein Patch veröffentlicht wurde. Ein gutes Beispiel dafür gab es im Januar 2010: Im Rahmen der „Operation Aurora“ gab es im Dezember 2009 Cyberangriffe auf Google und weitere Unternehmen. Der Schadcode wurde über eine Schwachstelle im Internet Explorer eingeschleust, die Microsoft schon Ende Januar 2010 beheben konnte. Und das aus dem einfachen Grund: Microsoft wurde sie bereits Anfang September 2009 vertraulich von einem Sicherheitsforscher gemeldet, der Patch befand sich bereits in Entwicklung. Nach Microsofts Ansicht kannten nur der Entdecker und Microsoft die Schwachstelle und man konnte sich Zeit lassen, einen Patch zu entwickeln und zu testen. Dass ein Dritter sie finden und ausnutzen könnte, hat man nicht bedacht. 

Auch Cyberwaffen sind gefährlich

Eine weitere Gefahr stellen die Cyberwaffen selbst dar. Niemand kann den Entdecker einer Schadsoftware daran hindern, sie zu analysieren, zu verbreiten oder was auch immer damit zu machen. Dass Stuxnet durch einen Programmierfehler aus der Urananreicherungsanlage gelangte, ist bedauerlich. Genau so gut hätte der Wurm aber auch von einem Mitarbeiter der Anlage entdeckt und im Internet freigesetzt werden können. Oder der iranische Geheimdienst hätte ihn analysieren, anpassen und z. B. auf die israelischen Anlagen los lassen können. Ein weiteres Problem: Wer die Schadsoftware untersuchen kann, wird dabei auch die Exploits für die 0-Day-Schwachstellen finden, die er dann z. B. für eigene Zwecke einsetzen oder auf dem Schwarzmarkt verkaufen kann.

Helfen Abkommen?

Bruce Schneier fordert Cyberwar-Abkommen („Cyberwar Treaties“) [77]. Die Frage ist nur, ob die wirklich viel bewirken würden. Cyberwaffen kann jeder noch so kleine Staat, jede noch so kleine Interessengruppe entwickeln oder entwickeln lassen. Ist es nicht zu verlockend, einem noch so großen Gegner mit einem kleinen Stück Schadsoftware großen Schaden zufügen zu können? Warum sollte jemand auf diese Möglichkeit verzichten? Und wenn ein Staat offiziell darauf verzichtet, wie will man das Einhalten eines solchen Abkommens überprüfen? Software lässt sich deutlich leichter verstecken und transportieren als herkömmliche Waffen. Von der Entwicklung und Herstellung ganz zu schweigen. Wenn ein Staat Langstreckenraketen mit Atomsprengköpfen entwickeln und bauen will, fällt das früher oder später auf. Schadsoftware erkennt man dagegen im schlimmsten Fall erst, wenn sie bereits erfolgreich im Einsatz war.

Angriff oder Verteidigung

Im Grunde muss sich in Zukunft jeder Staat auf die Abwehr von Cyberangriffen durch andere Staaten vorbereiten, unabhängig davon, ob er selbst Angriffe in Betracht zieht oder nicht. Was passiert eigentlich, wenn eine staatliche Stelle eine kritische Schwachstelle in einem Betriebssystem oder einer Anwendung findet – wird sie dem Hersteller gemeldet, um mögliche Angriffe darauf durch einen Patch abzuwehren, oder geht sie in das Waffenarsenal der eigenen Cyberkrieger über? Ich sehe interessante Zeiten auf uns zukommen …

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -