Forensic Investigations / Fi Blog

Fi Blog

BlackHat DC 2011 - "Master Offense"

Obwohl ich mit der Berichterstattung sehr hinterher hinke, und noch nicht einmal alle Artikel zum 27. Chaos Communication Congress fertiggestellt habe, hier dennoch vorab der erste Kommentar zur gestern zu Ende gegangenen BlackHat DC 2011 Sicherheitskonferenz.

Wirklich ein 'Meisterwerk'?

Tom Parker erläuterte kürzlich , dass der Code von Stuxnet keinesfalls so ausgeklügelt sei, wie vielfach in den Medien berichtet. Für die aufmerksamen Leser dieses Blogs ist das nichts wirklich Neues; bereits im Oktober hatte ich beispielsweise berichtet , dass der Wurm über keine besonders ausgeklügelte Rootkit -Technologie verfügt und sich sehr leicht entfernen lässt.

Der Embedded Systems Security-Spezialist Nate Lawson kommentierte deshalb m.E. zu Recht, dass er entsprechende Techniken schon in den 90er Jahren von "bulgarischen Teenagern" gesehen hätte.

Anti-Forensische Maßnahmen nicht einmal durschnittlich

Wie Parker wiederum richtig ausführt, enthält Stuxnet zwar Code, um AntiVirus-Software auszutricksen, aber keine fortgeschrittenen Anti-Debugging-Routinen oder Tricks zur Code-Obfuscation , wie Sie heutzutage in fast jeder Malware gängig sind. Diese Tricks können eine Analyse des Programmcodes wesentlich erschweren und verzögern.

Lawson merkt weiterhin zu Recht an, dass Stuxnet keine fortgeschrittenen Design-Patterns wie 'Hash-and-Decrypt' verwendet, bei dem der Schlüssel zum Entpacken der 'Nutzlast' aus Umgebungsparametern zusammengesetzt wird, was eine Entschlüsselung somit nur auf dem tatsächlichen Zielsystem erlaubt hätte. Durch diesen 'Mangel' war es für jedermann leicht möglich, den enthaltenen SPS-Schadcode zu analysieren.

Ich ergänze dazu mal noch Folgendes:

  • Stuxnet installiert sich direkt nach dem Exploit des 'LNK'-Bugs, statt eine gewisse 'Inkubationszeit' einzuhalten, um den Infektionsweg zu verschleiern
  • bei der Installation werden ganz unverhohlen Registry-Keys wie "SOFTWARE\SIEMENS\WinCC\Setup" oder "SOFTWARE\SIEMENS\STEP7" abgefragt, womit die SIEMENS-Software sofort als Ziel ausgemacht werden kann. Ein ausgeklügelter Virus würde beispielsweise das 'Programme'-Verzeichnis listen, Hashes von den Namen der Verzeichniseinträge erstellen, und diese dann mit dem Hash der Zeichenkette 'Siemens' vergleichen. Letzteres Verfahren würde nicht in den ersten fünf Minuten der Analyse auffliegen.

Netzwerkkommunikation unterentwickelt

Parker führte auch aus, dass Stuxnet nur über eine vergleichsweise rudimentäre "Command & Control " Struktur verfüge und die Netzwerkkommunikation unverschlüsselt abliefe. Zumindest Ersteres kann ich so bestätigen.

Schlussfolgerung

Sowohl Parker als auch Lawson ziehen den Schluss, dass es eher unwahrscheinlich sei, dass ein westlicher Geheimdienst so dilettantisch seien würde. Es darf auch als unwahrscheinlich gelten, dass die Urheber eine Entdeckung des Wurms billigend in Kauf genommen hätten.

Entgegen dem viel diskutierten, aber wenig substanziierten Bericht der New York Times, die USA und Israel würden hinter Stuxnet stecken und SIEMENS habe unfreiwillig Schützenhilfe geleistet , und den ebensolchen Vermutungen Irans selbst , halte ich diese Theorie zumindest für wesentlich schlüssiger begründet, die der Autor Jeffrey Carr auch nochmals verteidigt hat .

Zumindest das Ziel des Angriffs dürfte in der Fachwelt mittlerweile weitgehend unstreitig sein.


27. Chaos Communication Congress (27C3) - "We come in peace"

Ebenfalls interessant war der Vortrag "Building Custom Disassemblers" von Felix 'FX' Lindner, der sich mit der Analyse des SPS-Codes von Stuxnet beschäftigte. Hierzu entwickelte er einen eigenen Disassembler, der Code auf den Steuerungen wieder in lesbare Anweisungslisten (kurz: AWL) gemäß IEC 61131-3 zurückverwandelt. Im Vorjahr hatte er sich den Mängeln des SWF -Formats von Adobe gewidmet, welche durch die AWL-Implementierung von SIEMENS aber nochmals übertroffen würden ("ridiculous design").

Er fand hierbei auch weitere Wege, um Code in SPSen zu verstecken. Einige Hacks mit der 'BLD'-Instruktion seien ohne Weiteres in der Lage, die GUI-Tools von STEP7 vollkommen aus dem Takt zu bringen, diese würden aber bisher nicht von Stuxnet genutzt.

Weiterhin stellte er fest, dass Teile des SPS-Codes von Stuxnet entweder nicht mit den SIEMENS-Tools erstellt oder nachträglich 'gereinigt' worden seien. Das Datum des Codes gehe teilweise bis 1996 zurück, die letzte Änderung des SPS-Codes sei offenbar am 24. September 2007 erfolgt. Zu besagtem Datum hatte Achmadinedschad eine aufsehenerregende Rede an der Columbia University gehalten , und zwei Tage zuvor eine potentiell gegen Israel/USA einsetzbare Langstreckenrakete vorgestellt. FX hielt das Datum für womöglich echt, da keine offensichtliche Manipulation vorläge, ich möchte dennoch darauf hinweisen, dass es sich hier dennoch um ein simples Täuschungsmanöver handeln könnte, um die Urheberschaft zu verschleiern.

FX hält die Incident Response Strategien in der Industrie für unterentwickelt und sieht die Gefahr der Infektion von SPSen als unterschätzt an, vor allem angesichts der Tatsachen, wie leicht es geht und wie 'gut' es erledigt werden kann. Er sieht Staaten, die nicht schon vor 10 Jahren begonnen haben, sich auf Angriffe gegen kritische Infrastrukturen zu schützen, für mindestens die nächsten 5 Jahre als gefährdet an und wünscht diesen "good luck".

Die Anstrengungen von SIEMENS beurteilt er ebenfalls als zu gering und bemängelt, dass der 'schwarze Peter' hier dem Kunden zugeschoben werde.

Siehe dazu auch:


27. Chaos Communication Congress (27C3) - "We come in peace"

Bruce Dang von Microsofts Security Response Center berichtete über die Analysen der in Stuxnet enthaltenen Exploits. Nicht selten musste er dabei über manche Implementierung aus dem eigenen Haus schmunzeln. In "rund 40 Arbeitsstunden" an "drei oder vier Tagen" sei die "grundlegende Analyse der vier großen Fehler" erledigt gewesen.

Bei der Analyse der Sicherheitslücken wurde der Fehler im Druckerwarteschlangendienst zunächst übersehen, da die Testumgebung keinerlei Netzwerk simuliert hätte. Der Hinweis auf diesen Fehler sei dann von den Anti-Viren-Experten bei Kaspersky gekommen. "Schon fünf Minuten" nach diesem Hinweis sei ein erster Fix zur Verfügung gestanden, der aber noch entsprechend abgeändert werden hätte müssen.

Er zeigte sich gleichermaßen überrascht wie beängstigt über die "100-prozentige Zuverlässigkeit" der in Stuxnet enthaltenen Exploits. Ein Zeichen, dass Microsoft offenbar im Gegensatz zu SIEMENS verstanden hat, wie wichtig Sicherheit ist und wie kritisch solche Lücken sind. Letztere reagieren seit Monaten nicht einmal mit einem fünf-minütigen Anruf auf die zwei von uns entdeckten Exploits zum SIMATIC-Paket, welche ebenfalls 100% Zuverlässigkeit erreichen.

Das "Big Picture" blieb bei Dangs Vortrag freilich ausser Betracht, denn die "Minuten", "Stunden" oder "Tage" wurden letztendlich zu Monaten. Er bemerkte, von dem eigentlichen Schadcode in Stuxnet nichts zu verstehen (im Vortrag auch fälschlicher Weise als "SCADA part" bezeichnet).

Soziologische Aspekte des Incident Response wurden ebenso thematisiert: Dang erläuterte, dass sofort entsprechende Fachleute eingebunden wurden, die direkt mit der Entwicklung der jeweiligen Systemteile befasst waren. Er räumte auch ein, dass eine Problemlösung schneller möglich gewesen wäre, wenn er den Feststellungen eines Kollegen früher Glauben geschenkt hätte. Zudem stellte er fest, dass der berüchtigte 'LNK-Bug' offenbar im Hause bereits bekannt war, sich aber scheinbar niemand zuständig gefühlt hatte, die Beseitigung des Fehlers anzustoßen. Ein sehr schönes Beispiel, wie mangelndes Sicherheitsbewusstsein einzelner Mitarbeiter zu großen Problemen führen kann.

In puncto Fakten gab es insgesamt nichts wirklich Neues für alle, die das ESET Papier zu Stuxnet gelesen haben, das m.E. fundierter ist als das wohl häufiger zitierte, aber zum Teil fehlerhafte Symantec Papier . Dennoch ein interessanter und auch unterhaltsamer Vortrag, der nicht nur für Entwickler und Incident Responder lehrreich sein kann.

Siehe dazu auch:



Hier finden Sie aktuelle Themen und Hintergründe rund um Sicherheit, Internet und Recht, das Sachverständigenwesen und die Computer-Forensik.

Mon Di Mi Do Fr Sa So
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31