Forensic Investigations / Fi Blog

Fi Blog

it-sa - Die IT-Security-Messe

Auch dieses Jahr besuchten wir wieder die it-sa IT-Security-Messe in Nürnberg. Die Messe ist im Vergleich zu den Vorjahren enorm gewachsen und entsprechend in die wesentlich größere Halle 12 umgezogen. Sowohl bei Ausstellern als auch Besuchern hat die Internationalität im Vergleich zu den Vorjahren stark zugenommen. Die it-sa wurde vom SecuMedia Verlag ins Leben gerufen und in Ihrem nunmehr dritten Jahr von der Nürnberg Messe übernommen.

Nürnberg Messe

Parallel zur it-sa fanden noch die Messen POWTECH (Internationale Fachmesse für Mechanische Verfahrenstechnik), TechnoPharm (Internationale Fachmesse für Life Science Prozesstechnologien) sowie der INDEX Safety Congress und der CleanRoomCongress statt.

Freundlicherweise hat mich der SecuMedia Verlag auf die it-sa eingeladen, der dort seine neue Publikation "Informationsdienst SCADA-Sicherheit - IT-Security für Systeme der Automatisierungs-, Leit- und Steuertechnik " erstmals präsentierte, für die ich auch einen Beitrag verfasst habe .

Gleich zu Beginn besuchte ich den Workshop "IT-Security industrieller Netzwerke", der Insidern jedoch nichts wirklich Neues bieten konnte.

Neben diversen Terminen und Standbesuchen habe ich mir einige der Vorträge in den Foren angesehen. Neben Forum "Blau" (Technik) und Forum "Rot" (Management) gab es dieses Jahr erstmals zusätzlich ein Auditorium mit Sonderveranstaltungen, die aber teilweise nur mäßig besucht waren. Konzeptionell ermöglichte das Auditorium mit variablen Vortragslängen jedoch detailiertere Eröterung eines Themas als die Foren, bei denen die Beiträge fast ausnahmslos auf nur 15 Minuten beschränkt waren. Dementsprechend hatten die Referenten wenig Möglichkeiten, in die Tiefe zu gehen, was sich der eine oder andere fachkundige Besucher sicher gewünscht hätte.

Zu den Keyspeakern zählte Dr. Taher Elgamal, Bundesinnenminister Dr. Hans-Peter Friedrich hielt beim MesseCampus die Keynote.

Hier geht's entlang

Dr. Hans-Peter Friedrich bei seiner Keynote (c) Messe Nürnberg/Thomas Geiger

Das BSI präsentierte sich mit einem großzügigen Stand

Ari Takanen von Codenomicon: "Security for the Internet of Things"

Weitere Impressionen von der Messe finden Sie in der nachfolgenden Bildergallerie.

Weitere Bilder finden Sie auch beim Presse-Service der it-sa .


BlackHat Las Vegas 2011 - Embedding Security

BlackHat Las Vegas 2011 - Embedding Security

USB-Angriffe sind nicht neu. Prominente Beispiele sind der 'LNK-Bug ' oder der im Frühjahr auf der BlackHat DC gezeigte Angriff per simulierter Tastatur . Auf noch niedriger Ebene ging Andy Davis von NGSSecure vor.

Mit einem Testgerät, das mit einem selbstgeschriebenen Programm instrumentiert wurde, gelang es ihm nach eigener Aussage, Schwachstellen u.a. in Windows 7, der Xbox 360, Solaris 11 Express, Apple OS X und diversen Embedded-Systemen zu finden. Dies ermögliche "Jailbreaks", Entsperren gesperrter Arbeitsstationen, heimliche Installation von Schadsoftware oder Diebstahl sensitiver Daten.

Da Endpoint Protection Lösungen meist auf höherer Ebene arbeiteten, seien Sie gegen solche Angriffe und Sicherheitslücken in USB-Treibern oft wirkungslos. Der einzig effektive Schutz sei das Abschalten der USB-Schnittstellen im BIOS des Systems oder deren Versiegelung mit Epoxidharz.


BlackHat DC 2011 - "Master Offense"

Das sich Schadsoftware über Wechseldatenträger verbreiten kann, dürfte spätestens seit Stuxnet bekannt sein. Auch unter Linux war es möglich –entsprechende Fehlkonfiguration vorausgesetzt – Rechner durch bloßes Verbinden von USB-Geräten zu hacken .

Die Autostart-Funktion von Betriebssystemen wie Windows zu unterbinden ist nur die offensichtlichste und weithin bekannte Methode zur Linderung des Problems. Microsoft hat dem Problem inzwischen auch Rechnung getragen und die Autostart-Funktion teilweise zu Grabe getragen .

Im Falle des von Stuxnet bekannten 'LNK-Bugs' war auch das Deaktivieren der Autostart-Funktion nicht ausreichend. Zu viele Prozesse laufen implizit im System ab, die der normale Anwender nicht mitbekommt.

Nun haben Angelos Stavrou und Zhaohui Wang auf der BlackHat DC 2011 eine weitere Methode gezeigt, wie sich Rechner durch ein SmartPhone hacken lassen. Das SmartPhone gibt sich gegenüber dem Rechner als Tastatur (USB HID ) aus und kann so Kontrolle über den Rechner erlangen, ohne das der Benutzer eine Möglichkeit zum Eingriff hätte. Statt eines SmartPhones ließe sich auch ein winziges USB-Gerät bauen, das die gleiche Funktion erfüllen könnte.

Selbst eine Endpoint Protection Lösung verhindert diesen Angriff in der Regel nicht, da die Geräteklasse USB-HID normalerweise standardmäßig von allen Beschränkungen ausgenommen ist.

In sensitiven Umgebungen empfiehlt es sich deshalb wenn möglich USB oder andere Hot-Plug Schnittstellen generell abzuschalten. Alternativ lassen sich bei einigen Endpoint Security Lösungen – genauso wie für Wechseldatenträger – Seriennummern für erlaubte USB-HID-Geräte hinterlegen. Jedoch stellen leider nicht alle USB-Tastaturen Seriennummern zu Verfügung um dies zu ermöglichen. Eine Beschränkung auf Hersteller-ID und Typ-ID wird ohne jeden Wert sein, da ein Angreifer mit physikalischem Zugang sicher auch Hersteller und Typ der Tastaturen erkennen wird und somit alle nötigen Daten besitzt.


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 .


Es hat in der Vergangenheit viele Warnungen gegeben, SCADA -Netze besser zu managen, adäquat zu sichern und deren Integrität sicherzustellen, u.a. auch von uns . Mehrfach und seit Jahren weise ich auf die Gefahren hin, bis an höchste Stellen bei SIEMENS. Obwohl den Verantwortlichen eine vollständige Studie zum kompletten LifeCycle-Management der Anlagen vorliegt, die das bisherige Verfahren im Detail mit möglichen Alternativen vergleicht hat SIEMENS diese bis ins Detail durchdachten Empfehlungen leider nicht aufgegriffen, was sich nun im Nachhinein wohl als gravierender Fehler erwiesen hat.

Traditionell herrscht im SCADA-Umfeld geringe Security Awareness, da sich der Mythos vom "Inselnetz" trotz gegenteiliger Erfahrungen und diverser Studien hartnäckig zu halten scheint.

Der beinahe-GAU

Nun ist es gekommen wie es kommen mußte und auch prophezeit war: seit einigen Wochen ist bekannt, dass ein Wurm kursiert, der gezielt die SIEMENS SCADA/Industrial Control Systeme SIMATIC WinCC und PCS7 befällt .

Dieser hat sich u.a. über den sog. "LNK-Bug " (CVE-2010-2568 , Microsoft Security Bulletin MS10-046 ) verbreitet, bei dem es genügt, ein Verzeichnis mit einer speziell manipulierten Verknüpfung zu öffnen(!) um den Exploit auszulösen. Der somit gestartete Schadcode installiert ein Win32.Stuxnet genanntes Rootkit . Findet der Wurm ein SIMATIC System, manipuliert er dieses inklusive dessen Microsoft SQL Server Datenbank und infiziert gezielt alle Projektdateien, um sich auch auf diesem Wege weiter zu verbreiten. Ansonsten infiziert er erreichbare Laufwerke.

Hartcodierte Passwörter und Datenbank-Bugs

Da die Benutzerkonten und Passwörter für die WinCC MSSQL-Server Datenbank hartcodiert d.h. weltweit in allen Anlagen konstant sind (CVE-2010-2772 ), und zudem seit vielen Jahren in SIEMENS-eigenen Foren öffentlich zu lesen waren , ist der Angriff auf die Datenbank besonders leicht. Zumindestens einen dieser Beiträge hat SIEMENS -nach entsprechender "Bedenkzeit"- mittlerweile vom Netz genommen, Belege dafür liegen uns jedoch vor. Zusätzlich haben wir einen weiteren gravierenden Fehler in der Datenbankkonfiguration gefunden, der bis jetzt nach unseren Informationen nicht öffentlich bekannt ist, und eine eigene CVE-Nummer bekommen müßte. Auf unsere Hinweise dazu reagierte SIEMENS bisher jedenfalls nicht mit der Beseitigung der Fehler.

Unzureichendes Update und Fehlinformationen

Das von SIEMENS veröffentlichte SIMATIC Security Update (aktuell: v1.0.0.11 vom 18.08.2010) ist unzureichend, behebt BEIDE Fehler nicht, und verhindert auf älteren Anlagen u.U. noch nichtmal die Weiterverbreitung des Wurms über Projektdateien. Neben der sehr unübersichtlichen Struktur des dazugehörigen Security Advice sind darin auch noch gefährliche Falschinformationen enthalten:

  • "Um eine solche Infektion zu verhindern, wird dringend empfohlen, dass die Anwender nur über Hauptbenutzer-Rechte verfügen. Ein Hauptbenutzer hat nicht die nötigen Rechte, um Code von einem anderen Laufwerk zu starten". (Hervorhebungen durch den Autor)

Wenig Reaktion auf dramatische Probleme, Entdeckung lange später reiner Zufallsfund

Auf diese Hinweise mit dem Zusatz, dass neben diesen drei Sicherheitslücken noch mehr als ein Dutzend weitere vorhanden sind -Sie ahnen es- keine ernsthafte Reaktion.

Durch das von uns seit Jahren angeprangerte fehlende Sicherheits- und Integritätsmanagement wurde der Virusbefall noch nicht einmal von SIEMENS selbst festgestellt, sondern durch Frank Boldewins Zufallsfund bei der Analyse einer Malware, der durch die Presse ging .

Der Wurm soll mindestens seit über einem Jahr (Juni 2009) unbemerkt in mehreren Varianten kursieren und lt. neuesten Informationen sogar SPS -Systeme mit einem Rootkit infizieren und nebenbei auch die 'Conficker'-Sicherheitslücke (MS08-067 ) zur Verbreitung nutzen können.

Da die Reaktion des Herstellers aus meiner Sicht punktuellen Aktionismus statt einer nachhaltigen Problemlösung darstellt, kann ich allen SIEMENS SIMATIC WinCC und PCS7 Nutzern nur dringend empfehlen, Ihre Netze von einer neutralen Instanz auditieren zu lassen und entsprechende Gegenmaßnahmen zu ergreifen.

Security Audit in der Praxis

In von uns durchgeführten Security Audits wurden -auf lediglich mit PCS7 installierten PCs- zwischen 76 und 266 kritische (d.h. von remote ausnutzbare) Sicherheitslücken festgestellt (insgesamt: zwischen 153 und 389).

Für die Auditierung können Sie sich auch vertrauensvoll an uns wenden . Forensic Investigations berät Sie gerne und bietet Ihnen entsprechende Lösungen und Services für Integritäts- und Sicherheitsmanagement , Endpoint Security, Desaster Recovery, Auditierung, Vulnerability Assessment und Patchmanagement – speziell zugeschnitten auf die Anforderungen in SCADA/Industrial Control Systems Netzwerken .

Daneben bieten wir Beratung zu Incident Response Strategien sowie die digitale forensische Sicherung, Analyse und Auswertung solcher Vorfälle an.

Wir verfügen über 25 Jahre Erfahrung im Sicherheitssektor, 10 Jahre Erfahrung beim Softwaremanagement im Anlagenumfeld und über mehr als 30 Jahre Erfahrung im Automatisierungssektor. Wie effizient weltweites Analagenmanagement im konkreten Fall aussehen hätte können, sehen Sie in den folgenden Videos.



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