Forensic Investigations / Fi Blog

Fi Blog

Im Zuge der Auswertung der Stuxnet-Angriffe auf SIEMENS SIMATIC WinCC und PCS7 haben Kaspersky Labs und Symantec weitere Lücken entdeckt, die von Stuxnet ausgenutzt werden . Microsoft hat die Lücken bestätigt .

Dazu gehört der über das Netzwerk ausnzutzbare Fehler im Druckerwarteschlangendienst von Windows (CVE-2010-2729 /MS10-061 ), der mit dem September-Bulletin geschlossen wurde, sowie zwei weitere lokal ausnutzbare Lücken (Laden von Tastaturlayout Definitionsdateien, Taskplaner), die einem Angreifer höhere Rechte verschaffen und höchstwahrscheinlich mit dem Oktober-Bulletin am Dienstag geschlossen werden. Die Lücke beim Laden von Tastaturlayout Definitionsdateien (CVE-2010-2743 /MS10-073 ) wurde mit dem Oktober-Bulletin geschlossen, die weitere Lücke steht noch offen im Taskplaner (CVE-2010-3338 /MS10-092 ) wurde nunmehr mit dem Dezember-Bulletin geschlossen.

Ineffiziente Incident Response

Der SIEMENS Security Advice zu Stuxnet geht auf die nicht-ganz-so-neu bekannt gewordenen Fakten leider in keinerlei Hinsicht ein, alte Falschinformationen wurden immer noch nicht entfernt.

Der mittlerweile lange bekannte Bug (CVE-2010-2772 ) wird durch das dort angebotene 'SIMATIC Security Update' weiterhin ebensowenig beseitigt wie die von Forensic Investigations entdeckte weitere Datenbank-Lücke in WinCC (siehe Video 2.1 "Remote-Einbruch in die WinCC-Datenbank" am Ende dieses Artikels ).

Analysen haben ergeben, dass das sog. 'Sicherheitsupdate' neben der –wie im Video zu sehen– völlig unzureichenden Datenbank-Konfigurationsänderung rein gar nichts aktualisiert, sondern lediglich ein 'getarntes Desinfektions-Tool' oder ein Placebo zur Beruhigung der Kunden darstellt.

Neben diesen uns lange bekannten Mängeln, die neben Anderen, bisher nicht näher spezifizierten Sicherheitslücken bereits Ende Juli von unserer Seite an die SIEMENS AG kommuniziert wurden, kommt nun noch eine weitere von uns Mitte August aufgedeckte Sicherheitslücke dazu.

2 Stunden 200€ Software Audit von Fi bringt weitere gravierende Mängel ans Tageslicht

Ein Software Audit von weniger als 2 Stunden (entspricht Kosten <200€) konnte weitere offensichtliche Mängel zutage fördern, die Projekte infizieren können. Sowohl SIEMENS SIMATIC WinCC als auch PCS7 und weitere Tools aus der Produktfamilie sind davon betroffen. Dies führt dazu, dass Infektionen ohne Weiteres von Engineering Stationen mit Internetzugang an Anlagen-PCs ohne Internetverbindung weitergetragen werden können. Die Auswirkungen sind also durchaus mit denen des "LNK-Bug" vergleichbar, diesmal allerdings liegt die Ursache dafür einzig und allein im Verantwortungsbereich des Automatisierungsherstellers (siehe Video 2.2 "Code-Ausführung beim Öffnen eines WinCC-Projekts" am Ende dieses Artikels ). 'Proof of Concept' Demo Exploits sind auf Anfrage bei uns erhältlich führen wir Ihnen auf Anfrage vor.

Die Legende vom "Inselnetz"

Die Mär vom "Inselnetz" dürfte damit wenigstens für etwas vorausschauende Menschen ein für alle mal widerlegt sein. Selbst auf Inseln läßt man Goldschätze nicht einfach achtlos herumliegen, da es Wasserfahrzeuge, Fluggeräte und Brückenbau gibt. Diese Wasserfahrzeuge, Fluggeräte und der Brückenbau sind in unserem Beispiel Wechseldatenträger, das Roaming von Engineering Stationen, Remote Access Lösungen u.ä. Das nächste Desaster ist schon vorprogrammiert, wenn hier kein grundlegender Mentalitätswechsel stattfindet.

Sicherheit - oft ein menschliches Problem, kein technisches oder betriebswirtschaftliches

Klar hatte bereits Mark Twain (1835-1910) erkannt, dass ein Dutzend verlogener Komplimente leichter zu ertragen seien als ein einziger ehrlicher Tadel, aber es führt kein Weg daran vorbei, sich den Realitäten zu stellen. Wo Menschen arbeiten passieren Fehler, auch bei Weltfirmen.

Die Gründe dafür können vielfältig sein: Zeitdruck, Mangel an Wissen, fehlende Sorgfalt, organisatorische Defizite oder Beratungsresistenz sind nur einige der möglichen Ursachen.

Selbst wenn die gemachten Fehler als trivial und leicht vermeidbar einzustufen sind, ist es nicht unbedingt gleich als töricht einzustufen, solche Fehler zu begehen. Die wirkliche Torheit beginnt erst an dem Punkt, an dem man auf die Fehler aufmerksam gemacht wird und trotz minimalster Kosten nicht handelt, vermeintlich um sich keine Blöße zu geben. Dies birgt jedoch neben hohen Schadenersatzrisiken das Risiko eines irreparablen Vertrauensverlustes bei den Kunden.

Nahezu alle großen Hersteller haben hier mittlerweile Ihre Lektionen gelernt, sieht man einmal von Apples CEO Steve Jobs ab, der das Empfangsproblem beim iPhone unter "no issue" verbuchte und statt einer Problemlösung lieber kritische, aber wohl wahre Forumsdiskussionen löschen ließ .

Do your homework – the OTHER SIDE WILL

Bei all diesen Nachforschungen haben wir aus Kostengründen nur ein kleines bisschen an der Oberfläche gekratzt. Mit einem Etat wie es die Urheber des Stuxnet Wurms wohl hatten – ich schätze die Kosten für den Angriff auf mindestens 200.000€, 0days am Schwarzmarkt und Programmierkosten zusammen – lassen sich sicher Unmengen von Bugs aufdecken. Uns hat schon ein Tausendstel davon gereicht, um einen solchen kritischen Bug zu finden. Die Beseitigung der Mängel ist alternativlos, und von einer Person jeweils innerhalb eines Tages ohne Probleme zu erledigen – inklusive Kaffeepausen und Meetings. Ein einziges Problem durch einen Sicherheitsmangel kostet sicher ein Zigfaches. Und ein solches Problem wird kommen, da Cyberkriminelle SCADA und ICS Netze spätestens jetzt als lukratives Ziel erkannt haben dürften. Mehr zum Thema finden Sie auch in unserer Präsentation "SCADA and Industrial Control Systems (ICS) network security in 2010 ".

Die Automatisierungshersteller sollten womöglich eine Prämie von sagen wir 20.000€ pro gefundenem Bug zahlen – wenn sie Ihrer Software nur ein bisschen vertrauen. Selbst Mozilla oder Google zahlen hier 5.000€ für gefundene Fehler in Ihren Browsern – diese verteilen Ihre Software im Unterschied dazu aber kostenlos und sind in deutlich weniger sicherheitsrelevanten Bereichen beheimatet.

Um es mit den fachfremden, aber auch hier zutreffenden Worten von Phil Taylor zu formulieren:
"If you don't practice every day, the others will".

Maßnahmen

Als minimalstes Minimum sollte neben dem Update zum LNK-Bug unbedingt das schon o.g. Druckerwarteschlangendienst-Update (CVE-2010-2729 /MS10-061 ) eingespielt werden, das der Automatisierungshersteller offiziell autorisiert hat , aber leider nicht im Zusammenhang mit Stuxnet empfiehlt. Dies ist jedoch nur eine punktuelle Maßnahme.

Wie schon in einem vorigen Post berichtet fanden wir jeweils viele Dutzend Lücken, die ebenso als kritisch einzustufen waren. Ich kann allen Kunden, die kritische Infrastrukturen mit SIEMENS SIMATIC WinCC und PCS7 betreiben deshalb nur weiterhin dringendst anraten, Ihre Netze von einer neutralen Instanz auditieren zu lassen und entsprechende Maßnahmen zu ergreifen, die Gefahren für industrielle Systeme nachhaltig ausschließen .

Daneben gibt es ein "Hintertürchen" in Stuxnet, das die Infektion eines Rechners durch die gegenwärtig bekannten Varianten verhindert. Auf Anfrage stellen wir Ihnen gerne Informationen dazu bereit, um Ihre Systeme zu schützen.

Es bleibt abzuwarten, ob der Automatisierungshersteller nun nach fast 3 Monaten endlich reagiert, die Lücken schließt und vor Allem solche Vorfälle durch eine geeignete Maßnahmen nachhaltig verhindert. Unsere Lösungen hierfür liegen seit Jahren auf Halde, da sie [wie man sieht] "nicht benötigt" werden.

UPDATE 13.10.2010: Informationen zum Oktober-Patchday im ersten Absatz ergänzt.

UPDATE 03.11.2010: Wir hatten uns zwischenzeitlich dazu entschlossen aus Sicherheitsgründen die 'Proof of Concept' Demo Exploits erst herauszugeben, wenn ein entsprechender Fix verfügbar ist, Text oben entsprechend abgeändert.

UPDATE 22.11.2010: Inzwischen ist ein öffentlicher Exploit zu der Privilegieneskalation im Taskplaner erschienen. Dies war zu erwarten, da ESET ausreichend Informationen veröffentlicht hatte, um die Lücke nachvollziehen bzw. implementieren zu können. Es bleibt zu hoffen, dass dieser Bug im Zuge des nächsten 'Patch Tuesday' am 14.12. geschlossen wird.

UPDATE 14.12.2010: Die Privilegieneskalation im Taskplaner ist als nunmehr letzte von Stuxnet genutzte Sicherheitsanfälligkeit geschlossen. Entsprechende Informationen zum Dezember-Patchday im ersten Absatz ergänzt


Möglicher Hintergrund: Angriff auf iranisches Atomprogramm!?

Die Spekulationen mehrten sich in den letzten Wochen, Stuxnet sei vermeintlich ein Angriff auf das iranische Atomprogramm , vor allem geschürt durch Frank Riegers Artikel bei FAZ.NET . Rieger stellt darin die Aussage auf, Stuxnet sollte sich bereits im Januar 2009 selbst deaktivieren und sei schon lange vorher im Umlauf gewesen. Entsprechende Belege, Quellenangaben oder wenigstens Indizien fehlen aber leider. Aus anderen Quellen oder eigenen Nachforschungen kann ich diese Aussage nicht bestätigen, obwohl ich alle Berichte zu diesem Thema seit dem Bekanntwerden Mitte Juli akribisch sammle und auswerte.

Ebensowenig geht Riegers Artikel darauf ein, dass Steuerungen in Kernkraftwerken normalerweise nach dem SIL4 Standard gemäß DIN/EN/IEC 61508 ausgerichtet sind, und sich nur in einem manuell zu schaltenden Modus reprogrammieren lassen. Der Wurm würde jedoch automatisch abwarten, bis die Steuerungen in diesen Modus versetzt werden, und dann seinen Schadcode in die Steuerungen implantieren. Bei einem der mutmaßlichen Ziele, dem Kernkraftwerk in Buschehr (Google Maps ), das demnächst ans Netz gehen soll , dürfte dies während der Inbetriebsetzung in den vergangenen Monaten sicher recht häufig der Fall gewesen sein.

Ein IT-Experte des Ministeriums für Industrie und Bergbau erklärte gegenüber der iranischen Agentur Mehr News Agency , insgesamt seien über 30.000 Rechner von Industrieanlagen allein im Iran befallen worden (Wirtschaftswoche , Handelsblatt , Financial Times Deutschland , Welt , Spiegel Online u.a. hatten daraufhin berichtet).

Mehr News Agency hat inzwischen ergänzt , dass sich die Inbetriebnahme des Kraftwerks Buschehr verzögere, dies hinge laut dem Chef der iranischen Atomenergiebehörde Atomic Energy Organization of Iran (AEOI) jedoch nicht mit Stuxnet zusammen.

Stuxnet ein Machwerk des Mossad?

Ob der Angriff nun durch internationale Dienste ausgeführt wurde und tatsächlich dem iranischen Atomprogramm galt, bleibt weiter im Bereich der Spekulation. Die Darstellung, lediglich Nationalstaaten hätten die Resourcen, einen solchen Angriff zu implementieren, greift m.E. aber etwas zu kurz: Mitbewerber, Kriminelle oder Terrororganisationen wären sicher ebenso zu einem solchen Angriff in der Lage, selbst wenn die Kosten in Millionenhöhe gelegen haben sollten und hätten ebenso ein Motiv.

Die Gerüchteküche wurde noch zusätzlich angeheizt, da der Code von Stuxnet das vermeintliche Datum "19790509" enthält. Am 09. Mai 1979 wurde der Präsident der "Jüdischen Gesellschaft Teherans", der jüdisch-iranische Industrielle Habib Elghanian , von einem Erschießungskommando in Teheran hingerichtet. Dies kann auch ein reines Ablenkungsmanöver sein; in der Regel hinterlassen Autoren von Schadsoftware kaum absichtlich Hinweise, die auf Ihre Spur führen.

...oder doch von Cyberkriminellen?

Da Stuxnet befallene Rechner unter die Kontrolle der Angreifer bringt, und prinzipiell jeden beliebigen Code ausführen kann, halte ich einen 'opportunistischen' Ansatz des Angriffs ohne ein konkretes Ziel ebenfalls für sehr wahrscheinlich: erstmal infizieren, dann sehen wen man erwischt hat, und was man für Vorteile daraus schlagen kann. Wäre der Angriff 100% auf Iran gerichtet gewesen, hätte der Wurm womöglich auf die Infektion anderer Anlagen verzichtet, um das Entdeckungsrisiko nicht unnötig zu erhöhen. Ebenso könnte dies jedoch eine Ablenkungsstrategie sein, die das eigentliche Ziel verschleiern soll.

Gegen die Theorie von Cyberkriminellen als Urheber spricht die Tatsache, dass die von Stuxnet verwendete Rootkit -Technologie nicht besonders ausgeklügelt ist. Womöglich hat der Angreifer sich hier auf ein sehr laxes Management der Anlagen-Software verlassen. Das Stuxnet noch den eigentlich uralten Fehler im Server-Dienst (MS08-067 /'Conficker '-Bug) auszunutzen versucht, spricht ebenfalls dafür.

Ebenso ist der Wurm im Vergleich zu anderen im Umlauf befindlichen Schadprogrammen auch sehr leicht zu entfernen. Der Urheber hat offensichtlich damit gerechnet, dass die Mission vor dem Bekanntwerden der Schadsoftware erfolgreich abgeschlossen sein würde, und er sich nicht vehement gegen seine Entfernung zur Wehr setzen müsste.

Die insgesamt vier in Stuxnet enthaltenen Zero Day Exploits legen aber zumindestens Kontakte zur Cybercrime-Szene nahe.

Besonders interessant ist auch die Tatsache, dass der Urheber von Stuxnet einen Mechanismus geschaffen hat, der die Infektion bestimmter Systeme durch ein 'Hintertürchen' verhindert. Es wäre hochinteressant zu wissen, wo dieses schon lange Zeit im Umlauf ist. (Weitere Informationen, wie Sie dieses Hintertürchen zu Ihrem Schutz vor Stuxnet nutzen können erhalten Sie auf Anfrage bei uns.)

Was die vermeintlich gestohlenen Zertifikate betrifft, mit denen die Dateien von Stuxnet signiert sind, wurden beide betroffenen Zertifikate von der US-Firma VeriSign ausgegeben. Statt dem Diebstahl der Zertifikate könnte man -wenigstens theoretisch- auch die Ausgabestelle dazu bringen, Kopien der ausgestellten Schlüssel herauszugeben ('persuade'/überreden, 'compel'/zwingen). VeriSign verdient neben den Zertifikatsdiensten hauptsächlich an Überwachungsdiensten für Behörden nach dem Communications Assistance for Law Enforcement Act (CALEA) , die von vielen Telekommunikationsanbietern an das Unternehmen ausgelagert wurden. Man sagt dem Unternehmen auch deshalb sehr enge Kontakte zur amerikanischen Regierung nach.

Stuxnet-Epidemie in China

Inzwischen ist auch China unter den Opfern von Stuxnet, das einige wohl ebenfalls im Kreise der verdächtigen Urheber des Wurms sehen oder sahen. Chinesischen Medienberichten zufolge seien im Land Millionen von Rechnern und nahezu 1000 Industrieanlagen befallen, berichtete Heise Online. Laut der South China Morning Post wolle die Regierung eine landesweite Untersuchung von Anlagen mit Siemens-Software durchführen und weitere Aufträge an Siemens prüfen.

Belastbare Zahlen zu den Infektionen in China liegen jedoch nicht vor. Jedenfalls dürfte die von SIEMENS immer wieder genannte Zahl von 15 Infektionen fernab der praktischen Realität liegen. Bei genauerem Hinsehen zeigt sich weiterhin, dass es sich hierbei nur um die Anzahl der bei SIEMENS gemeldeten Infektionen handelt, die auch niemand tatsächlich nachvollziehen kann.

Fazit

Viele Spekulationen über die Urheberschaft von Stuxnet wurden angestellt, einige davon sind sicher falsch, gänzlich unbelegt oder rein in die Irre führend, es verbleiben jedoch mehrere gleichermaßen tragfähige Theorien. Dementsprechend läßt sich im Augenblick weder der Urheber des Angriffs, noch ein definitives Ziel mit sehr hoher Wahrscheinlichkeit festmachen.

Lediglich eines ist sicher: sowohl Betreiber kritischer Infrastrukturen als auch Automatisierungshersteller müssen dringend handeln und solche Risiken nachhaltig in den Griff bekommen. Lösungen existieren, der Handlungsbedarf wurde praktisch aufgezeigt. Einfach nur Abwarten ist womöglich die schlechteste aller möglichen Strategien.

UPDATE 21.10.2010:The Registerberichtete unter Bezug auf iranische Quellen , eine als 'nuclear spies' bezeichnete Personengruppe wäre im Iran verhaftet worden, die jedoch lt. Angaben des iranischen Geheimdienstministers Heidar Moslehi in keinerlei Verbindung mit Stuxnet stünden.

UPDATE 16.11.2010: Laut Informationen von Symantec scheint es sich bei der von Stuxnet gesuchten besonderen Konfiguration um 6ES7-315-2 Steurungen zu handeln, die über CP 342-5 Profibus Kommunikationsmodule und Frequenzumrichter der Typen KFC750V3 (Profibus Geräte-ID: 7050h, Hersteller: Fararo Paya - Teheran, Iran) und Vacon NX (Profibus Geräte-ID: 9500h, Hersteller: Vacon AG - Vaasa, Finnland) mindestens 33 Wechselstrommotoren ansteuern.

Diese Frequenzumrichter unterlägen lt. Symantec der Exportkontrolle der Atomenergiebehörde, da sie u.a. zur Ansteuerung von in der Uran-Anreicherung verwendeten kaskadierte Gaszentrifugen verwendet werden könnten. Die Minimalzahl und die hohe Drehzahl der Motoren (807-1210 Hz bzw. 48420-72600 U/min), die Stuxnet sucht und die Art und Weise, wie diese manipuliert werden, könnte ebenso darauf hindeuten. Daneben gibt es im Bereich der Ultrazentrifugation noch Anwendungsgebiete in der Biochemie. Falls ein Leser weitere Einsatzszenarien solcher schnell drehender Motoren in tagelang dauernden Prozessen kennt, bitte ich um Mitteilung .

UPDATE 10.12.2010: Im Gegensatz zu Symantecs Analyse, die anführt weiterer Schadcode für 6ES7-417 Steuerungen sei abgeschaltet oder nicht vollständig schreibt Ralph Langner in seinem Blog, dieser Code könnte dazu dienen, 1000 Megawatt Turbinen des Typs K-1000-60/3000-3 (Hersteller: Power Machines – Moskau, Russland) in Buschehr zu sabotieren, sofern diese nicht über entsprechende Schutzschaltungen verfügten, oder sich gegen eine übergeordnete Schaltung zur Kaskadierung von Gaszentrifugen richten. Zumindest eine Turbine des o.g. Typs scheint in Buschehr zu laufen .

UPDATE 10.12.2010: Bei Anschlägen auf zwei Atomphysiker im Iran sei einer der beiden Physiker getötet worden .

Mehrere Quellen meldeten , Irans Präsident habe mittlerweile bestätigt, dass Stuxnet "begrenzte" Schäden an den Gaszentrifugen in Natanz angerichtet habe, dies aber "nun nicht mehr möglich" sei. Iran ist bezüglich seines Atomprogramms mittlerweile auch an den Verhandlungstisch zurückgekehrt .

Die 'Cablegate ' Veröffentlichungen erweitern die Liste der Staaten, die ein potentielles Interesse an der Beendigung des iranischen Atomprogramms gehabt haben könnten.

UPDATE 20.01.2011: Weitere Nahrung für Spekulationen hier und hier .



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