Forensic Investigations / Fi Blog

Fi Blog

Lange schon war die Nachahmung des Stuxnet-Wurms in der Diskussion . Nun ist den Analysten von Symantec eine Duqu [dyü-kyü] getaufte Software aus dem europäischen Raum zugespielt worden. Die Malware sei Duqu getauft worden, da sie Dateien mit dem Präfix "~DQ" anlege. Symantec hat dazu ein technisches Papier , F-Secure und McAfee berichteten, das ICS-CERT hat ALERT-11-291-01 ALERT-11-291-01A ALERT-11-291-01B ALERT-11-291-01D ALERT-11-291-01E herausgegeben.

Anatomie des Rootkit-Teils von Duqu. Bild (c) Symantec

F-Secure schreibt , der Kernel Rootkit Treiber von Duqu (JMINET7.SYS) sei Stuxnet so ähnlich, dass deren Analyse-Systeme es für Stuxnet (MRXCLS.SYS) hielten.

Während Stuxnet mutmaßlich gestohlene Zertifikate der taiwanesischen Firmen RealTek und JMicron verwendete, sei die Duqu Malware mit einem Zertifikat der ebenfalls taiwanesischen Firma C-Media Electronics Incorporation signiert. Wie die beiden anderen Zertifikate sei es von VeriSign ausgestellt und am 14.10.2011 zurückgezogen worden. Dies dürfte aber nur wenig Wirkung zeigen, da ältere Systeme wie Windows XP dies nicht ausreichend überprüfen.

Symantec berichtet , Duqu sei nicht darauf ausgelegt, Automatisierungssysteme direkt zu sabotieren, sondern vielmehr sehr spezifische Dokumente wie Anlagen- und Gerätedesigns zur Vorbereitung zukünftiger Attacken zu stehlen. Der informationsstehlende Trojaner verfüge über eine Command & Control Infrastruktur, mit der er per HTTP oder HTTPS kommuniziere. Der C&C Server, über den die Steuerung des so gebildeten Botnets erfolgt, stünde in Indien und sei noch aktiv.

Das zurückgezogene Zertifikat der Rootkit-Komponente von Duqu (cmi4432.sys)

Der Verbreitungsweg sei noch unbekannt, die Malware würde sich im Gegensatz zu Stuxnet nicht selbst replizieren, sei also kein Wurm. Die Zahl der Organisationen, auf die die Malware abziele, sei sehr klein (<=2), darunter befänden sich Hersteller von Industrieautomatisierungssystemen. Als wahrscheinlichsten Verbreitungsweg kann man deshalb Social Engineering mittels Email- Scams mutmaßen. Die Schadsoftware würde sich zudem nach 36 Tagen selbst zerstören.

Zu den Fähigkeiten der Schadsoftware gehörten das Sammeln von Systeminformationen, Auswerten der Netzwerktopologie und das Aufzeichnen von Tastatureingaben ("Keylogging"). Es seien bereits mehrere Varianten aufgetaucht.

McAfee's Blogeintrag kann derzeit keine neuen Erkenntnisse beisteuern.

In den Medien wird hier vom "Vorgänger vom Nachfolger", "Sohn" oder "Bruder" von Stuxnet gesprochen. Bruder trifft es wohl am ehesten, da beide "genetisch" ähnlich sind. Ob es tatsächlich der "Vorgänger vom Nachfolger" ist, erscheint aus meiner Sicht spekulativ und unlogisch. Warum man erst von bestimmten Herstellern Informationen stehlen sollte erscheint schleierhaft, da ein weiterer Angriff nach diesem Schema auch so leicht möglich wäre.

UPDATE 21.10.2011: Das ICS-CERT hat einen aktualisierten Alert Alert , der die unzensierte IP-Adresse des Command&Control Servers benennt. Der Server wurde mittlerweile abgeschaltet.

Das Symantec-Papier zeigt keine wirklichen Besonderheiten des Trojaners. Interessant ist aber, dass Duqu die schon von Stuxnet bekannte Liste der zu umgehenden Virenscanner um die zwei chinesischen Hersteller Rising International und 360 erweitert hat. Auch interessant: Symantec hat laut Paper keine Ahnung, wie der Trojaner genau mit dem C&C Server kommuniziert(e), und wo im Code sich ein Selbstzerstörungsmechanismus befinden soll, weiß aber gleichzeitig, dass es genau nach 36 Tagen ist, und der Trojaner es selbst tut, und nicht ferngesteuert. Na dann.

Die Hashsummen der bisher bekannten vier Varianten des Duqu-Rootkits.

UPDATE 22.10.2011: Jetzt ist es offiziell: Duqu zielt NICHT auf Betreiber oder Hersteller von Automatisierungssystemen ab, vermeldet das ICS-CERT in Koordination mit Symantec und CrySyS , den Entdeckern von Duqu. Ich wollte es nicht so direkt schreiben, wie aber schon vermutet handelt es sich wohl um eine PR-Ente von Symantec. Ob die Geschichte mit dem Diebstahl sensitiver Dokumente von Automatisierungsherstellern gänzlich frei erfunden oder eine bloße Vermutung war, die als Faktum verkauft wurde, werden wir wohl nie erfahren. Der ICS-Security-Community wurde damit ein echter Bärendienst erwiesen.

Nebenbei hat das ICS-CERT im aktualisierten Duqu-Papier versäumt zu melden, dass neben den zwei bekannten Varianten noch zwei weitere gefunden wurden, weswegen ich das mit dem "ganz gezielten Angriff" auch nicht glauben konnte.
Die Rootkit-Treiber der vier bisher bekannten Varianten heißen "cmi4432.sys ", "jminet7.sys ", "adpu321.sys " und "nfrd965.sys ". Lediglich "cmi4432.sys" trägt eine vormals gültige digitale Signatur. Das zum Signieren benutzte Zertifikat wurde aber mittlerweile zurückgezogen.

UPDATE 27.10.2011: Aktualisierter Alert des ICS-CERT. Ergänzt werden Informationen aus einem Blog-Artikel von Kaspersky Labs. Berichtet wird dort von einem Infektionsfall im Sudan und drei Fällen im Iran. Dabei seien weitere, jeweils unterschiedliche, Dateinamen des Rootkit-Treibers festgestellt worden, namentlich "adp55xx.sys", "iraid18.sys", "igdkmd16b.sys", "bpmgs.sys" und "noname.sys". Ein Zusammenhang mit industriellen Automatisierungssystemen oder zwischen den Opfern bestünde nicht.

UPDATE 02.11.2011: Aktualisiertes Symantec-Papier zu Duqu. Symantec spricht von mittlerweile 14 Varianten.

Das "Verfallsdatum" des Trojaners lässt sich laut einem Blogeintrag von ESET in dessen Konfigurationsdatei angeben, analog zu Stuxnet. Dieses Verfallsdatum kann offenbar entsprechend verlängert werden.

Der Dropper (Duqu-"Installationsprogramm") wurde mittlerweile ebenfalls entdeckt. Er soll in einem Word-Dokument enthalten sein und nutzt eine bisher unbekannte Sicherheitslücke ("0day") in Microsoft-Betriebssystemen aus. Microsoft hat die Lücke bestätigt und arbeitet an der Behebung .

Command and Control Weiterleitung an das interne Netz mittels RPC-over-SMB. Bild (c) Symantec

Ein weiterer Server zur Fernsteurung ("Command & Control") in Belgien wurde entdeckt und vom Netz genommen.

Symantec und ESET berichten übereinstimmend, Duqu besitze einen zu Stuxnet analogen Kommunikationsmechanismus . Dieser könne Kommandos von einem infizierten Rechner mit Internetverbindung an einen internen Rechner ohne Internetverbindung weiterreichen. Dabei verwende Duqu RPC über SMB ("Named Pipes "), was von keiner Firewall blockiert werden wird.

Insgesamt also viele Parallelen, neben den völlig verschiedenen Payloads und Angriffszielen. Symantec spricht von mittlerweile 3 verschiedenen Payloads, die alle Informationen zu eingesetzten Systemen und/oder der Netztopologie entwenden.

UPDATE 04.11.2011: (!!!WICHTIG!!!) Microsoft hat ein Advisory und ein Fix-It herausgegeben, das die Ausnutzung der Sicherheitslücke (CVE-2011-3402 ) durch den Duqu-Installer verhindern soll. Die Sicherheitslücke betrifft alle Windows-Versionen und ermöglicht Privilegieneskalation. Der Fehler steckt im Windows-Kernel, genauer gesagt dem Parsen von TrueType Fonts. Voraussichtlich wird Microsoft diese Lücke mit dem November-Patchday am nächsten Dienstag (08.11.2011) noch nicht endgültig schließen. Es empfiehlt sich deshalb die Benutzung des Fix-Its, um kein zu großes Zeitfenster für eine Infektion entstehen zu lassen.

UPDATE 05.11.2011: Die im Advisory 2639658 beschriebenen manuellen Workarounds funktionieren unter Windows XP und Server 2003 nur für englischsprachige Windows-Versionen. In nicht-englischen Windows-Versionen ist der Benutzergruppenname "everyone" durch das jeweilige lokalisierte Äquivalent zu ersetzen (z.B. Deutsch: "Jeder"). Das Fix-It funktioniert auch auf nicht-englischen Sprachversionen. Sowohl die manuelle als auch die automatische Methode verhindern den Zugriff auf die Datei "t2embed.dll". Unter Windows XP und Server 2003 führt das zu der unerwünschten Nebenwirkung, dass die Updates KB972270 (MS10-001) und KB982132 (MS10-076) ständig erneut angeboten werden, auch wenn diese schon installiert sind oder nochmals installiert werden. Es empfiehlt sich deshalb, diese Updates entweder zu ignorieren oder auszublenden.

UPDATE 09.11.2011: Neues gemeinsames Papier des US-CERT und des ICS-CERT ("Joint Security Awareness Report"). Keine neuen Erkenntnisse, lediglich Zusammenfassung.

UPDATE 13.12.2011: Microsoft schließt die Duqu-Lücken im Windows-Kernel-Treiber win32k.sys (MS11-087 /CVE-2011-3402 ) wie erwartet im Zuge des Dezember-Patchdays . Das oben beschriebene Fix-It wird damit obsolet. Diese (Symantec PR- und FUD-)Story ist damit beendet.


'Stuxnet 2.0' Demo - Bild (c) Dale G. Peterson

Symantec zeigte auf dem Ausstellungsflur der BlackHat eine 'Stuxnet 2.0' Demo. Hierbei hätten Sie das 'Payload', also die 'Nutzlast' des Stuxnet-Codes ausgetauscht. Ebenso wie beim originalen Stuxnet sei die Manipulation des SPS-Codes durch einen Operator nicht zu erkennen, da diese beim Auslesen versteckt würde.

Die 'Nutzlast' könnte Steuerungen auf vielfältige Weise manipulieren. Die trivialste mögliche Manipulation hatte Ralph Langner schon vor einiger Zeit demonstriert . Mit 14 Bytes implementierte er eine simple Zeitbombe, die auf ein bestimmtes Datum wartet, und ab dann einfach das restliche Steuerungsprogramm überspringt. Kleine Ursache, große Wirkung: dies wäre noch schlimmer als ein unkontrollierter Stromausfall an der Steuerung, alle Regelungen kommen zum erliegen, aber der letzte Signalzustand liegt noch an. In diesem Fall kann man nur noch darauf hoffen, dass die physikalischen Sicherungssysteme auch für diesen Fall wie gewünscht greifen. Die Diagnose eines 'unsichtbaren' Fehlers dürfte ebenfalls schwierig werden.


BlackHat Las Vegas 2011 - Embedding Security

BlackHat Las Vegas 2011 - Embedding Security

Jerome "Jay" Radcliffe ist Diabetiker und Hacker. Er trägt eine fest implantierte Insulinpumpe, die per Funk von einem Blutzucker-Messgerät Dosisvorgaben bekommt. Das Messgerät bekommt seine Daten von einem Sensor ("Kontinuierlich messender Glukosesensor "), der ebenfalls im Körper sitzt. Als Hacker interessierte ihn natürlich die Frage, ob es ihm gelingen würde, dieses "menschliche SCADA-System" auszutricksen.

Die richtige Dosierung des Insulins sei durchaus nicht trivial, da der Blutzuckerspiegel einen gewissen Korridor nicht verlassen sollte. Ein zu hoher Blutzuckerspiegel führe zu Kopfschmerzen, verschwommenem Sehen und Schädigung der Nieren. Zu niedriger Blutzuckerspiegel wiederum könne zu Betrunkenheitsgefühl, Ohnmacht, Atem- oder Herzstillstand führen. Eine hohe Insulingabe kann also lebensgefährliche Konsequenzen haben.

Durch Reverse Engineering der Hardware, öffentliche Dokumentation und Patentschriften konnte er die Frequenzen herausfinden, auf denen die Geräte kommunizieren. Mit einer selbst gebauten Arduino-basierten Lösung gelang es ihm, Signale aufzufangen und zu senden. Seine Theorie hat sich voll bestätigt, dass das System in keinster Weise gesichert ist, lediglich eine leicht zu ermittelnde individuelle Gerätenummer muss bekannt sein, um manipulierte Signale abzusetzen.

Im Moment müsse der Patient die Insulindosis noch "manuell" bestätigen. In Zukunft solle die Insulingabe vollkommen automatisch geschehen. Neuere Geräte würden auch teilweise mit Bluetooth arbeiten, was Vor- und Nachteil zugleich seien könne. Bleibt zu hoffen, dass bis dahin auch entsprechende Sicherheit in die Geräte integriert wird.


Das (schwarze) Lamm

Bild (c) Don & Tonya Christner

Gestern berichtete heise online über aktuell aufgetauchte Sicherheitslücken in SCADA-Produkten . Luigi Auriemma hat eine Liste mit 35 Schwachstellen in SCADA-Produkten von SIEMENS Tecnomatix (FactoryLink ), Iconics (Genesis32 und Genesis64), 7-Technologies (IGSS ) und DATAC (RealWin ) veröffentlicht.

Der Löwe

Desweiteren hat Gleg Ltd. das Agora SCADA+ Pack herausgegeben, das neben öffentlich bekannten Sicherheitslücken auch 9 Zero-Day-Exploits enthält. Davon betroffen sind u.a. Produkte von Atvise , ClearSCADA , DataRate und InduSoft .

Der schlafende Drache

Im Januar dieses Jahres war die Sicherheitspolitik des Herstellers WellinTech, der die hauptsächlich im chinesischen Markt verbreitete Prozessvisualisierungs-Software KingView vertreibt, öffentlich in die Kritik geraten. Dieser wusste offenbar seit September letzten Jahres um die Sicherheitslücken in seinen Produkten. Erst die Veröffentlichung eines Exploits konnte den "schlafenden Drachen" dazu bringen, seine Sicherheitsprobleme zu beseitigen . Offenbar war jedoch nur ein Kommunikationsproblem dafür verantwortlich, dass der Fehler nicht früher beseitigt wurde. Inzwischen ist jedoch ein weiterer Exploit für das Produkt öffentlich geworden, zu dem es meiner Kenntnis nach keine Berichterstattung gibt. Auch der Status einer Fehlerbehebung ist unbekannt.

Der (ebenfalls schlafende?!) Dickhäuter

Die von uns entdeckten Sicherheitslücken in SIEMENS SIMATIC WinCC & PCS7 sind durch das Sicherheitsupdate (Stand SP1 von Ende Januar 2011) nach wie vor nicht geschlossen.

Advisory-Panne: Wenigstens hat man das völlig unübersichtliche Advisory bereinigt; dabei "bereinigt" wurde auch die neuste Version des Sicherheitsupdates, über die Seite ist nurmehr eine Vorgängerversion Stand Oktober 2010 erreichbar. Eine deutliches Indiz, dass der Hersteller in dem Chaos wohl selbst die Übersicht verloren hat.

Was lange währt wird ... schließlich doch nichts? Die Zeitspanne, mehr als ein halbes Jahr (Juni 2010 bis Januar 2011) an einem Sicherheitsupdate "herumzudoktoren", dass sich dann immer noch in 60 Sekunden umgehen lässt, stellt wohl eine traurige Rekordmarke dar.

Hack me, yes you can! Aber es kommt noch dicker: die Passwörter, die die Ausnutzung des WinCC-Datenbank-Bugs ermöglichen, sind nun wieder frei für jedermann in einem SIEMENS-eigenen Forum zu lesen - obwohl dieser Eintrag zwischenzeitlich bereits gesperrt war. Eine wirklich herausragende Glanzleistung.

Neuer Zero-Day Nebenbei bin ich -quasi zufällig- noch über eine weitere Zero-Day-Lücke durch einen gravierenden Design-Fehler in den Produkten gestoßen, die in unter 10 Minuten gefunden war. Wer sich mit dem Thema schon beschäftigt hat weiß, dass es normalerweise Stunden, Tage oder gar Wochen dauern kann (und sollte), solche Fehler zu finden.

Es bleibt abzuwarten, ob und in welcher Zeit diese Hersteller ihre Sicherheitsprobleme beheben. Falls Sie eines der o.g. Produkte einsetzen und um Ihre Sicherheit besorgt sind, wenden Sie sich gerne an uns. Wir können prüfen, ob Sie von den entsprechenden Lücken betroffen sind und ggf. Maßnahmen zur Beseitigung oder Abmilderung des Risikos anbieten oder ausarbeiten.

UPDATE 25.03.2011: Kaum geschrieben, schon sind weitere Lücken aufgetaucht: betroffen sind BroadWin (WebAccess ), CSE-Semaphore (T-BOX ) RTUs und Ecava (IntegraXor SCADA/HMI ). Während Ecava brav war, und einen Fix veröffentlicht hat, meint BroadWin offenbar auch, den Fehler verneinen zu können, woraufhin ein Exploit veröffentlicht wurde.

UPDATE 04.04.2011: In SIEMENS Tecnomatix FactoryLink sind weitere Lücken entdeckt worden, nur wenige Tage nachdem bei den oben angesprochenen nachkorrigiert wurde (ICS-CERT Advisory 11-091-01 , SIEMENS Advisory SSA-630126 , Updates ). Ob diese Updates die Mängel zuverlässig beseitigen, ist weder dem ICS-CERT noch uns bekannt, da uns weder die Software noch ein Auftrag zur Prüfung vorliegt. Details zu den neuen Lücken liegen noch nicht öffentlich vor.

Ebenfalls unbekannt ist, wie viele weitere Sicherheitsmängel sich noch in dem Produkt befinden. Es spricht schon Bände, wenn ein Sicherheitsforscher innerhalb von 2 Manntagen mit einfachsten Mitteln bereits 6 hochgefährliche Lücken entdecken konnte. Wenn dann aber kurz nach der Veröffentlichung eines Updates ein weiterer Forscher innerhalb von Minuten noch weitere gleich geartete Lücken findet, deutet dies m.E. auf generelle systemische Mängel im Sicherheitsmanagement hin. Bei Microsoft etwa ist es selbstverständlich, ähnliche Fehler im Zuge eines Updates ebenfalls zu beseitigen. Im README zum Update heißt es bezeichnend "this module is being made available AS IS WITH NO WARRANTY OF ANY KIND" – das macht Mut.

Interessanter Weise befindet sich der Link zum FactoryLink-Advice auch noch völlig unvermittelt inmitten des Stuxnet-Advisories , bei dem es ja um ein völlig anderes Produkt und um eine völlig andere Problematik geht. Womöglich ist das ein neues Kommunikationskonzept "Confusion redefined" ;-)

UPDATE 14.04.2011: Nun kommen auch noch das Honeywell ScanServer ActiveX Control (ICS-CERT Advisory 11-103-01 , Updates ) und das Invensys Wonderware InBatch Client ActiveX Control (ICS-CERT Advisory 11-094-01 , Invensys Security Bulletin LFSEC00000054 , Updates ) hinzu. Beide Fehler sind lt. ICS-CERT mit den vorgenannten Updates behoben. Die Nummerierung lässt erahnen, dass demnächst noch so einiges folgt...

UPDATE 19.04.2011: Iconics hat ebenfalls reagiert und schließt in Genesis32 und Genesis64 die 13 ursprünglich entdeckten sowie eine weitere, nachträglich entdeckte Sicherheitslücke (ICS-CERT Advisory 11-108-01 , Updates ). Das ICS-CERT konnte die korrekte Fehlerbeseitigung verifizieren.

UPDATE 21.04.2011: DATAC schließt die Sicherheitslücken in RealWin ebenfalls (ICS-CERT Advisory 11-110-01 , Updates ). Das ICS-CERT konnte die korrekte Fehlerbeseitigung verifizieren. Von den Problemen sei nur die Demo-Version betroffen gewesen.

UPDATE 26.04.2011: Gleg Ltd. hat das Agora SCADA+ Pack v1.1 herausgegeben, das neben Exploits zu einigen bekannten Lücken in SIEMENS Tecnomatix FactoryLink, Iconics Genesis32/Genesis64, 7-Technologies IGSS, DATAC RealWin und WellinTech KingView und einer ZeroDay-Lücke in Beckhoff TwinCAT ENI Server v1.1.6.0 enthält.

UPDATE 02.05.2011: 7-Technologies hat Updates zu IGSS veröffentlicht (ICS-CERT Advisory 11-119-01 , Updates ). Die Software kann auch über die Update-Funktion in der Applikation aktualisiert werden. Der Entdecker der Sicherheitslücke hat die korrekte Fehlerbeseitigung durch das Update bestätigt.


Die Hackercommunity "Anonymous" geriet im Zusammenhang mit den Angriffen auf Paypal , Visa, MasterCard und andere erstmals in den Fokus der Medien. Diese Angriffe erfolgten als Reaktion auf die Einstellung der Transaktionen für die Enthüllungsplattform WikiLeaks durch diese Unternehmen.

Die der US-Regierung nahestehende Sicherheitsfirma HBGary kündigte die angebliche Veröffentlichung der Klarnamen der Mitglieder der Hackercommunity an und wurde daraufhin selbst angegriffen . Dabei wurde die Website des Unternehmens Ziel eines sogenannten Defacements , über das gehackte Twitter-Konto von HBGary's CEO Aaron Barr wurden kompromitierende Nachrichten sowie das Dokument mit den angeblichen Mitgliedern verbreitet . Sämtliche Server des Unternehmens seien abkopiert und anschließend gelöscht worden.

Unter den entwendeten Daten befanden sich auch über 75.000 Emails, die zwei Schritten veröffentlicht wurden. Einige Quellen berichten, aus diesen Emails ginge hervor, HBGary sei unter anderem an der Vermietung von Botnetzen und der Entwicklung eines geheimen Rootkits mit dem Codenamen "Magenta" beteiligt, und habe versucht, die Untersuchung des Stuxnet Wurms zu behindern.

HBGary sei inzwischen 'untergetaucht' und habe seine Beteiligung an der RSA-Konferenz abgesagt . Die ehemaligen Kooperationspartner Palantir und Berico haben sich inzwischen von HBGary und den weiteren Plänen zur 'Unschädlichmachung' von WikiLeaks distanziert. Weitere Hintergründe bei heise online.

Als weitere Drohung hat Anonymous nun den Quellcode des Stuxnet Wurms für jedermann frei zugänglich ins Netz gestellt . Es ist damit leichter denn je, eine Neuauflage des Wurms in den Umlauf zu bringen. Die Veröffentlichung ist diesmal real und kein bloßes Gerücht .

Neue Sicherheitslücken, die zur Infektion von Systemen verwendet werden können, werden immer wieder bekannt, jüngst beispielsweise der bisher unbehobene Fehler in Windows-Dateifreigaben . Zudem sind alle SIEMENS PCS7 und WinCC Systeme unseres Wissens nach wie vor über die von uns entdeckten Sicherheitslücken angreifbar, mehr als ein halbes Jahr nach dem wir SIEMENS davon berichteten. Weitere Sicherheitsmängel wollte man sich bis heute nicht einmal anhören. Dennoch sind viele Kunden in der Industrie augenscheinlich erstaunlich entspannt.


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