Forensic Investigations / Fi Blog

Fi Blog

Die Hersteller der Automatisierungsbranche sind in puncto Sicherheit der IT-Branche immer noch weit hinterher, obwohl sie hier noch wichtiger ist als in der Office-IT. Die IT-Sicherheit ist essentielle Grundlage jeder Betriebssicherheit („Safety“). Dennoch tauchen immer wieder gravierende Sicherheitsmängel auf, die hier schon oft thematisiert wurden. Die Branche übernimmt nicht in ausreichendem Maße die Verantwortung für Ihre Produkte und wälzt somit Kosten und Risiken auf die Anwender ab.

ReVuln "0day" video

Unabhängige Sicherheitsforscher, die solche Risiken aufdecken, sehen in aller Regel keinerlei Lohn für ihre Arbeit oder werden gar noch juristisch bedroht. Fehler werden gerne lieber klein geredet statt sie konsequent zu beheben. Nun ziehen einige Akteure die Konsequenzen daraus. Die Firma ReVuln verkauft die Schwachstellen nun einfach – mit positiven wie negativen Konsequenzen.

Hinter ReVuln stehen Donato Ferrante und Luigi Auriemma – letzterer ist u.a. bereits durch die (kostenlose) Erforschung und Veröffentlichung einiger Sicherheitslücken im Industriebereich und die Entdeckung einer Lücke im Remote Desktop Protocol (RDP ) von Windows kein Unbekannter.

Entsprechend dem Video sollen konkret folgende Hersteller betroffen sein:

Eaton

  • 2x Remoteausführung beliebiger Befehle/Remote Shell
  • 1x Übernahme bestehender Sitzungen ("Session Hijacking") mit Remote Shell

General Electric Energy

  • 2x Remoteausführung beliebiger Befehle
  • 2x Herunterladen von beliebigen Dateien

Kaskad

Bild aus der ReVuln "0day" Demo

  • 1x Remoteausführung beliebiger Befehle

Rockwell Automation

  • 1x Remoteausführung beliebiger Befehle

Schneider Electric

  • 1x Remoteausführung beliebiger Befehle

SIEMENS

  • 1x Remoteausführung beliebiger Befehle

"Null Disclosure"

In welchen Produkten diese Lücken konkret enthalten sind, gab ReVuln naturgemäß nicht an. Im Gegensatz zu den bisherigen Veröffentlichungen, die nur "Proof of Concepts" (PoCs) waren, handelt es sich bei den Vorführungen im Video offenbar um vollwertige Exploits . PoCs können nur von Experten zu vollwertigen Exploits ausgearbeitet werden – PoCs selbst eignen sich nicht, ein System vollständig zu kapern. Mit fertigen Exploits ist dies jedoch auch für einen Laien leicht möglich.

Die Firma arbeitet offenbar – ähnlich dem französischen Schwachstellen-Broker VUpen – nach dem nicht unumstrittenen, sogenannten "Null Disclosure" Prinzip.

Schwachstellen werden dabei nicht an den Hersteller gemeldet, sondern auf dem Graumarkt (Schwarzmarkt?) gehandelt. Erfährt der Hersteller von der Sicherheitslücke und kann diese entsprechend beheben, ist die Lücke "verbrannt". Aufkäufer solcher sogenannter "Zero Days" sollen dabei hauptsächlich Geheimdienste sein. Diese nutzen sie mutmaßlich, um in Netze in anderen Staaten einzudringen oder Trojaner auf die PCs Ihrer Bürger einzuschmuggeln.

Wie es kommen musste

Nach der bisherigen Haltung der Branche ist es kaum verwunderlich, dass nun nach diesem Prinzip gearbeitet wird. Die Hersteller haben ihre Hausaufgaben nicht erledigt, diese von anderen erledigen lassen, und dann abgeschrieben – für die geleistete Arbeit hat wohl keines der allgemein gut verdienenden Unternehmen bezahlt, teilweise wurde die Fehlerbehebung gar noch boykottiert .

Ich kenne das nur zu gut, beispielsweise habe ich SIEMENS mehrmals angeboten, bei der Behebung der Mängel in ihren Produkten zu helfen – ohne Erfolg. Man vertraut weiterhin felsenfest den eigenen Leuten, die sich seit Jahren nicht gerade mit Ruhm bekleckern (Zitat eines US-Kollegen: „fundamentally flawed product“).

Sicherheitsforschung: Geschäftsmodelle und Verantwortungsbewusstsein

Es ist nur dem Verantwortungsbewusstsein von uns Sicherheitsforschern zu verdanken, dass bisher noch wenig ernsthaftes passiert ist – dennoch möchten wir unsere Arbeit wie jeder andere gerne bezahlt bekommen. Prinzipiell gibt es fünf Möglichkeiten:

  1. an den Hersteller geben (der will aber nichts zahlen, und ich habe nichts zu verschenken)
  2. an die Anwender geben (die können aber nichts dagegen machen, wollen ebenfalls nichts bezahlen, da ja ihr Hersteller verantwortlich ist)
  3. an irgend wen geben (will aber ich wieder nicht, da dies m.E. verantwortungslos ist)
  4. veröffentlichen (bringt kein Geld und birgt Risiken, wenn Details angegeben werden – falls nicht werden die Bugs einfach ignoriert)
  5. auf den „Zero Days“ sitzen bleiben (dafür habe ich mich momentan entschieden)

Würden wir die Lücken einfach an jemand beliebigen geben, der dafür zahlt, wäre der GAU wohl schon längst eingetreten – dies ist jedoch leider das einzige Modell, das momentan wirtschaftlich funktioniert. Wenn die Hersteller Probleme ignorieren, spielt die Zeit in jedem Fall gegen ihre Anwender – auf dem Schwarzmarkt gibt es ebenso Leute, die Sicherheitslecks finden können, und diese werden sicher keinerlei solche Skrupel haben, diese gewinnbringend zu nutzen.

Die Stunde der Wahrheit

Microsoft hat seine Lektion bereits vor über 10 Jahren gelernt . Für die Automatisierungsbranche steht dies nach wie vor aus. Da diese Systeme traditionell isoliert(er) waren, jetzt aber zunehmend vernetzt werden (Machine2Machine-Kommunikation , Manufacturing Execution Systeme , Enterprise Resource Planning , Fernwartung, ...), sind sie genauso von der allgemeinen Entwicklung betroffen wie die IT, wenn auch etwas zeitverzögert.

Die Stunde der Wahrheit ist gekommen – wer jetzt nicht handelt, wird vielleicht vom Markt weg konsolidiert werden. Hersteller, die die Sicherheit ihrer Kunden wirklich ernst nehmen, sollten ein "Bug Bounty" Programm anbieten, das Sicherheitsforscher angemessen für ihre Arbeit entlohnt, wie ich es seit Jahren fordere – alles andere ist nur hohles Marketing-Geschwätz ("Selbstverständlich nehmen wir die Sicherheit unserer Kunden sehr ernst" – nicht nur sagen, zeigen!).

Es ist bedauerlich für alle Anwender, die jetzt unter Umständen die Leidtragenden sind, dass es so weit kommen musste. Ein solch brutaler Weckruf für die Branche war aber abzusehen und ist scheinbar auch unausweichlich.

Ein solches Risiko für die Anwender war absolut vermeidbar, hätten die Hersteller die Verantwortung übernommen – auch in finanzieller Hinsicht, schließlich sind dies letztendlich Kosten, die man bei der Produktentwicklung eingespart hat, offensichtlich aber hätte investieren müssen.

Sollte ein Vertreter der betroffenen Unternehmen dies lesen – wir sind auf der SPS/IPC/Drives 2012 und bereit zu helfen (Terminabsprache zwingend erforderlich – wir haben keinen eigenen Stand).


RuggedCom, Hersteller von Netzwerktechnik, die besonders für den Einsatz in den kritischen Bereichen Energie, Militär, Transportwesen und produzierendem Gewerbe angepriesen wird, schreibt die neueste Posse bei den nicht abreißenden Pannenserien in der Leittechnik.

Bereits vor über einem Jahr war der Hersteller von dem Sicherheitsforscher Justin W. Clarke benachrichtigt worden, dass sich die Zugangspassworte zu seinem mit dem "Rugged Operating System" (ROS) ausgerüsteten Geräten ganz leicht anhand deren MAC-Adressen berechnen lassen. Der Hersteller räumte die Sicherheitslücke zwar offenbar ein, boykottierte aber deren Beseitigung. Nicht einmal die Einschaltung des US-CERT konnte den Hersteller dazu bewegen, diesen Mangel zu beheben, obwohl dessen Beseitigung -zumindest für den Hersteller- sicherlich trivial und mit vergleichsweise geringem Aufwand verbunden gewesen wäre.

Die Bezeichnung "Rugged" (dt. robust, stabil) mutet in diesem Kontext deshalb einmal mehr wie ein schambefreiter Marketing-Hype an. Es lässt sich nicht genau festmachen, ob es mangelndes Sicherheitsbewusstsein, Fehlorganisation, mangelnde Kultur beim Umgang mit eigenen Fehlern, bloße Ignoranz, gar Absicht oder eine Kombination dieser Faktoren ist, die dazu führen, dass hier nicht gehandelt wird. Vielleicht sollten sich solche Herstellerfirmen hier an den Weisheiten der Shaolin-Mönche orientieren:

  • Lernen ohne zu denken ist umsonst,
    denken ohne zu lernen ist gefährlich.
    Einen Fehler zu begehen und ihn nicht zu korrigieren,
    erst das heißt wirklich einen Fehler zu begehen.

Es ist eigentlich fast unmöglich, dass einem ein solcher gravierender Mangel selbst bei einer nur einigermaßen gewissenhaften Prüfung der eigenen Produkte "durch die Lappen" geht. Das ein solch gravierendes Problem aber nach über einem Jahr nicht abgestellt wurde, kann selbst mit Unfähigkeit schwerlich noch erklärt werden. Dabei kann es sich fast nur noch um gezielte Politik oder integrale, unter Umständen die eigene Existenz bedrohende Strukturmängel innerhalb des Unternehmens handeln.

Diese Politik kommt schon in der verwendeten Sprache zum Ausdruck - im Hersteller-Advisory spricht man lieber von einem "Problem" statt von einer knallharten Sicherheitslücke und sichert natürlich zu, dass dies überprüft wird. Es ist für mich äußerst fraglich, was man -nach mehr als einem Jahr- noch überprüfen möchte und noch nicht weiß, oder längst hätte wissen müssen.

Womöglich wird einmal mehr solange überprüft, bis wieder Gras über das "Problem" gewachsen ist, wenn das Thema wieder aus den Medien verschwunden ist. Dem Sicherheitsforscher, den man bei Dutzenden Zuschriften kaum mehr als ignoriert hat, dankt man noch recht höflich oder erklärt gar, dass diesem der Einblick in die Materie oder das Wissen um die Zusammenhänge fehle. Diese Strategien riechen irgendwie nach einem Deja Vu.

Ironie des Schicksals: RuggedCom war erst kürzlich von SIEMENS übernommen worden. Na dann - auf das zusammenwächst, was zusammen gehört!

UPDATE 30.04.2012: Das ICS-CERT hat ein aktualisiertes Advisory veröffentlicht, lt. dem der Hersteller beabsichtigt, innerhalb des nächsten Monats einen Patch zu veröffentlichen. RuggedCom hat seine Advisory-Seite aktualisiert und spricht nun klar von einer "factory backdoor". Der Hersteller will zudem die unsicheren (und in aller Regel unnötigen) Telnet- und RSH-Zugänge standardmäßig abschalten. Warum nicht gleich so.


SCADA Security Scientific Symposium (S4)

Im Rahmen des „Project Basecamp“ des „SCADA Security Scientific Symposium (S4)“ in Miami wurden Speicherprogrammierbare Steuerungen (SPSen, engl. Programmable Logic Controller (PLC)) und Remote Terminal Units (RTUs) wohl das erste mal unabhängig untersucht. Den Auftakt machte bereits letztes Jahr Dillon Beresfords Vortrag auf der BlackHat-Sicherheitskonferenz 2011 , der diverse Fehler wie Passwort-Replay und Backdoors in S7-Steuerungen von SIEMENS nachwies. Nun wurden Geräte verschiedenster Hersteller einer Untersuchung unterzogen. Wie nicht anders erwartet, sind dabei diverse Mängel aufgeflogen.

Eklatante Mängel in vielen Bereichen. Bild (c) Dale G. Peterson.

Von diesen Geräten wurden wieder hunderte Geräte am öffentlichen Internet gefunden. Bereits letztes Jahr hatten wir davor gewarnt , die Warnung scheint jedoch einige Anwender nicht erreicht haben.

Faktenlage ein offenes Geheimnis

Es ist ein offenes Geheimnis, dass in der Industrie eingesetzte Leittechnikkomponenten wie SPSen und RTUs extrem fehleranfällig sind. Dies ist jedem bekannt, der schon einmal ein Security Audit bzw. einen Penetrationstest im Industriebereich durchgeführt hat. Auch vielen Anwendern ist die Problematik bekannt. Selbst simpelste Tests wie Ping Sweeps oder übergroße Pakete bringen derartige Hardware oft zum Stillstand (Denial of Service (DoS)).

Entschlossenes Handeln leider Fehlanzeige

Trotzdem handeln sowohl Hersteller als auch Anwender nicht entschlossen genug, um eine bekannte Problematik in den Griff zu bekommen. Selbst der Stuxnet-Weckruf scheint nicht ausgereicht zu haben, dass die Hersteller ihre Geräte endlich sicher machen.

Obwohl die Hersteller zig Millionen mit ihren Geräten verdienen, müssen Sicherheitsforscher ohne jedes Budget Ihre Freizeit opfern, um solche Mängel im Sinne der Endanwender herauszufinden.

Die Anwender müssen hier darauf beharren, dass die Fehler beseitigt werden. Es kann nicht sein, Probleme als gegeben hinzunehmen, die im IT-Bereich niemals akzeptabel wären, obwohl die Auswirkungen im ICS-Bereich noch gravierender sein können.

Es bleibt abzuwarten, ob sich andere Hersteller hier professioneller verhalten als SIEMENS nach Beresfords Vortrag. Beim Elektroriesen verläuft offenbar alles im Sande: Probleme werden entweder ignoriert oder als Nicht-Problem umdefiniert.

Ich empfehle vorsorglich einen Blick auf das gute alte „Security Excuse Bingo “ - wenn Sie solche oder ähnliche Sprüche hören, läuft eindeutig etwas falsch...

UPDATE 11.04.2012: Aktualisierte Alerts des ICS-CERT; zu General Electric D20ME, Rockwell Automation / Allen-Bradley ControlLogix und MicroLogix, Schneider Electric Modicon Quantum und Koyo / Direct LOGIC H4-ES sind öffentliche Exploits erschienen. Informationen oben ergänzt und Links aktualisiert. Konkrete Problemlösungen sind bisher leider immer noch nicht vorhanden.

UPDATE 12.04.2012: Als wollten Sie mich Lügen strafen veröffentlicht Koyo als erster Hersteller Firmware-Updates; Abschnitt oben entsprechend ergänzt.


Innerhalb weniger Tage wurden zwei verschiedene Angriffe auf Betriebsstätten von US-amerikanische Wasserver- und Entsogungsbetriebe bekannt.

Pumpenschaden in Springfield, Illinois

Beim ersten Angriff wurde laut Bericht von The Register eine Pumpe mutmaßlich durch wiederholtes Ein- und Ausschalten zerstört. Die betroffene Anlage soll sich in Springfield, Illinois befinden und bereits mehrere Monate von Hackern infiltriert gewesen sein.

Die Angaben sollen aus einem offiziellen Regierungsbericht stammen, der einem Sicherheitsspezialisten zugespielt wurde. FBI und Department of Homeland Security (DHS) würden ermitteln, hieß es in einem offiziellen Statement des DHS.

Die Behörde hat jedoch offenbar darauf verzichtet, die Öffentlichkeit oder andere Betreiber solcher kritischer Infrastrukturen zu informieren.

Einbruch in South Houston, Texas

Durch den Vorfall und die Vorgehensweisen offizieller Stellen wurde offenbar ein weiterer Hacker auf den Plan gerufen. Er drang nach eigenen Angaben in die Systeme der Wasserver- und Entsorgung von South Houston, Texas ein und fertigte einige Screenshots des Systems an. Eine Beschädigung der Anlage lag jedoch offenbar nicht in seiner Intention.

Zu seinen Beweggründen sagte er, er sei es leid, dass das DHS dazu tendiere, den "absolut erbärmlichen Zustand der nationalen [kritischen] Infrastrukturen herunterzuspielen".

Der Hacker sagte im Interview mit ThreatPost, sein Angriff sei "kein Advanced Persistant Threat", kein Ergebniss "unglaublicher technischer Fähigkeiten", sondern "krasser Dummheit".

HMI-Bild der Abwasseraufbereitung Michigan Street, Satelitenfoto zum Vergleich

Er benötigte "so gut wie gar keine Kenntnisse", "ein zweijähriger mit SIMATIC-Grundkenntnissen könne einen solchen Angriff reproduzieren" ergänzte er in seinem Statement bei Pastebin.

Ursache für den Einbruch war offenbar ein direkt über das Internet erreichbare HMI-Bedienoberfäche des Wasserwerks in Kombination mit mangelhafter Kennwortsicherheit. Das Kennwort sei nur drei Zeichen lang gewesen, behauptet der Hacker.

Bewertung, Hoax oder nicht?

Solche Angriffe benötigen auf einer Kenntnisskala von 1 bis 10 sicher nur 1-2 Punkte. Mit 3-4 Punkten lassen sich gegen solche schwach geschützten und mit gravierenden Designfehlern behafteten Systeme schon Angriffe gegen Sicherheitslücken durchführen, die weltweite Auswirkungen haben könnten. Aber selbst viel trivialere Mittel als solche Exploits genügen oft bereits.

HMI-Bild Tank und Wasserturm in der Nevada Street, Satelitenfoto und Street View zum Vergleich.

Bestätigt wurde der zweite Angriff bisher nicht. Es wäre aber nicht das erste Mal, dass Automatisierungssysteme über das öffentliche Internet erreichbar sind . Die HMI-Bilder der Anlage entsprechen auf den ersten Blick bei der

HMI-Bild mit Rechtschreibfehler, Wassertank in der Virginia Avenue, Satelitenfoto und Street View zum Vergleich

Das Anlagenbild enthält hier zwar einen Schreibfehler ("Virgina" statt "Virginia"), was auch auf einen Hoax hindeuten könnte. Allerdings wäre für einen solchen Scherz sehr viel Aufwand erforderlich, weshalb ich nicht an ein Fake glaube.

Fraglich bleibt dann allerdings, warum die zuständigen Behörden einen solchen gravierenden Sicherheitsmangel nicht entdeckt haben, der noch dazu einfach und bequem vom Büroschreibtisch aus aufzuspüren ist.

UPDATE 29.11.2011: Der erste Fall (Pumpenschaden) passierte im Curran-Gardner Water District, Springfield, Illinois. Eine Warnung des Illinois State Terrorism and Intelligence Center (STIC) war in die Öffentlichkeit gelangt und bennante als Ursache einen Hackerangriff von russischen IP-Adressen. Das Dokument liegt Forensic Investigations vor. Der Vorsitzende der Wasserbetriebe, Don Craver, hatte in einem Interview ebenfalls bestätigt , dass es Anzeichen eines Einbruchs gegeben habe.

Das ICS-CERT verneint den Vorfall nun nicht explizit , sondern führt lediglich an, das dafür keine Beweise vorlägen. Kleiner aber feiner Unterschied. Es wäre auch ein ungutes Signal, wenn bekannt würde, dass kritische Infrastrukturen oftmals sehr leicht angreifbar sind. Forensic Investigations liegen weitere nicht-öffentliche Dokumente vor, aus denen hervorgeht, dass man genau solche Angriffe befürchtet.

Zu dem zweiten Vorfall in South Houston, Texas wird keine Stellung bezogen, was für sich ebenfalls aussagekräftig ist.

UPDATE 02.12.2011: Beim ersten Fall, dem Pumpenschaden im Curran-Gardner Water District, Springfield, Illinois handelte es sich nicht um einen Hackerangriff. Vielmehr war Jim Mimlitz, Techniker bei einem Dienstleister des Wasserwerks, gebeten worden, sich die Probleme mit der Pumpe anzuschauen. Er befand sich gerade im Urlaub in Russland - daher verzeichneten die Logs Zugriffe von russischen IP-Adressen unter seinem Login-Namen.

Das Wasserwerk alarmierte die Terrorismusabwehr Illinois State Terrorism and Intelligence Center (STIC), das FBI ermittelte, und das ICS-CERT bei der Heimatschutzbehörde DHS entsandte ein Einsatzkommando mit dem Flugzeug. Keiner dieser vier Akteure war schlau genug, das Offensichtliche zu tun: den Dienstleister anzurufen und zu fragen, ob und von wo er sich eingeloggt hatte. Das STIC machte sich offenbar auch mehr Sorgen darum, wie sein vertraulicher Bericht an die Öffentlichkeit gelangen konnte, als um die Verifikation des Inhalts. Mit dem angeblich gehackten Dienstleister hat man vor der Veröffentlichung der Warnung noch nicht einmal Kontakt aufgenommen.

Laut Mimlitz' Aussage war es außerdem klar ersichtlich, dass ein mechanischer oder elektrischer Schaden Ursache für das Pumpenversagen war. Das eigentlich Interessante in dem Interview mit Jim Mimlitz ist jedoch, dass das System für den Remote-Zugriff uralt und offenbar völlig fehlkonfiguriert war, was ständig Probleme bei der Anmeldung verursachte. Mangelnde Wartung und fehlerhafte Konfiguration solcher Systeme kann tatsächlich leicht die Tür für einen Hackerangriff aufreißen. Ebenfalls fraglich bleibt, warum Anmeldungen aus Russland überhaupt möglich sind, wenn man sich doch so sehr vor ihnen fürchtet.

Entgegen einigen Medienberichten, die beide Fälle miteinander in Verbindung brachten, ist der zweite Fall in South Houston, Texas bisher nicht als Fehlalarm enttarnt.

UPDATE 03.12.2011: Im Gegenteil ist der zweite Fall in South Houston, Texas bereits am 16.11.2011 durch ein Interview des örtlichen Bürgermeisters Joe Sato mit der Lokalzeitung The Houston Chronicle bestätigt worden . Amerikanische Lokalzeitungen sind etwas unterhalb meines Radars; danke an die US-Kollegen für den Hinweis. Der Hacker hat dort keinen Schaden angerichtet, da er das auch nicht beabsichtigte. Das betroffene System wurde erstmal vom Netz genommen.


Während der Datenbank-Bug in WinCC große öffentliche Aufmerksamkeit gefunden hat , ging dabei ein anderes Thema völlig unter: ein Programmierfehler (Video 2.2) sorgt dafür, dass Projektdateien von WinCC, WinCC Web Navigator, PCS7 und anderen Tools des SIEMENS SIMATIC Pakets so manipuliert werden können, das beim simplen Öffnen einer solchen Datei Schadcode ausgeführt werden könnte.

Wir hatten hier entsprechende Demo-Exploits angefertigt, die das belegen, aber natürlich statt Schadcode nur den Taschenrechner starten wie im Video zu sehen. Diese dienen auch dazu, als Gegenbeweis die korrekte Funktion des FixIt zu auditieren.

Das Problem ist deshalb so brisant, weil dies Schadcode von am Internet hängenden Engineering-PCs auf Anlagen einschleppen könnte. Dienstleister könnten von diesem Problem besonders betroffen sein.

Wir haben uns deshalb an die Arbeit gemacht, um SIEMENS SIMATIC WinCC und PCS7-Anwender vor diesem Risiko zu schützen. Eine Lösung für dieses Problem ist fertiggestellt.

Solange SIEMENS jedoch die Verweigerungshaltung in Bezug auf uns und das Thema Sicherheitslücken nicht ändert, sehen wir uns ausserstande, den Fix zu veröffentlichen. Durch die Veröffentlichung würden Details zum Problem in weiten Kreisen bekannt. Dies könnte Anwender, die nicht regelmäßig bei uns vorbeischauen, oder die aus Haftungsgründen den Einsatz eines inoffiziellen FixIt scheuen, in ernsthafte Gefahr bringen.

Der Teufelskreis ist nur durch Sie, die Anwender zu durchbrechen: bitten (oder falls erforderlich nötigen) Sie Ihren Automatisierungshersteller seine Verweigerungshaltung aufzugeben, es geht um Ihre Sicherheit.

SIMATIC Code-Execution Bug: Schweregrad nach CVSS-Standard

Berechnung des Schweregrads für eine typische Automatisierungs-Umgebung nach dem CVSS -Standard (Ihr CISO sollte Ihnen helfen können, diese Metriken und Vektoren zu interpretieren, weitere Informationen finden Sie auch hier ):

  • CVSS Overall Score: 10 /10

Vereinbaren Sie jetzt einen Termin für die SPS/IPC/DRIVES Messe 2010 , die dieses Jahr vom 23. bis 25. November im Nürnberger Messezentrum stattfindet. Gerne erläutere ich Ihnen dort, wie sich die hier im Blog geschilderten Sicherheitslücken in Automatisierungssoftwarelösungen auswirken können und diskutiere Lösungswege mit Ihnen persönlich.

Ein paar Termine sind kurzfristig noch zu vergeben. Ich freue mich sehr auf ein persönliches Kennenlernen.

UPDATE 26.11.2010: Vielen Dank an alle für die interessanten und konstruktiven Gespräche auf der Messe!

Ein paar Aufnahmen von der diesjährigen SPS/IPC/Drives:

Der Stand von Vacon in Halle 1

Frequenzumrichter Vacon NX Serie

Frequenzumrichter Vacon NX Serie (Nahaufnahme)

Siemens glänzte mit einem riesigen Stand in Halle 2 ...

...zumindest für Präsentation ist offenbar immer Geld genug vorhanden.

Eine Bildgalerie mit weiteren Impressionen von der Messe finden Sie hier:


Die Datenbanksicherheitslücke in WinCC (Video 2.1) ist offenbar nicht in jeder Situation von Remote ausnutzbar. Unter Windows XP ist der TCP-Port des SQL-Servers in der Standardkonfiguration durch die Windows-Firewall geschützt, was die Ausnutzung des Konfigurationsfehlers zumindest von aussen verhindert.

Wurde der Port jedoch geöffnet, beispielsweise um mit einem ERP-System auf die Daten zuzugreifen, ist besondere Vorsicht geboten.

Unter Windows XP scheint die Datenbanksicherheitslücke deshalb normalerweise 'nur' zu einer lokalen Privilegieneskalation (EoP) zu führen. Unter den vielen noch laufenden älteren Windows 2000-Systemen, die aufgrund der dort noch nicht standardmäßig vorhandenen Windows-Firewall normalerweise ungeschützt sind, kann die Lücke von Remote ausnutzbar sein.

Bewertung

Unter Windows 2000 muss die Lücke nach wie vor als 'kritisch' eingestuft werden, da standardmäßig kein Firewall installiert ist, was sie von Remote ausnutzbar machen könnte. Unter Windows XP ist die Gefahr immer noch als 'hoch' anzusehen, da sie einem Angreifer Administrator-Rechte verschaffen könnte. Ursache für das Problem sind die in beiden Fällen mit vollen 'sysadmin'-Rechten ausgestatteten Benutzer "WinCCAdmin" und "WinCCConnect". Dies entspricht wohl nicht der üblichen 'Best Practice' oder den Empfehlungen von Microsoft . Da der primäre Infektionsweg von Stuxnet ('LNK-Bug') geschlossen ist, besteht zumindest durch die bisher bekannten Varianten keine akute Gefahr.

Vorsichtsmaßnahmen

Überprüfen Sie unbedingt, ob der SQL-Server TCP-Port auf Ihren Systemen von außen erreichbar ist. Eventuell können Sie den Zugriff auf diesen Port auf dem System oder zumindest auf einer vorgelagerten Hardware-Firewall blockieren, um die Angriffsfläche zu vermindern. Falls bei Ihnen keine SQL-Kommunikation über TCP/IP stattfindet, können Sie mit dem SQL Server-Konfigurations-Manager auch die Bindung des SQL-Servers an TCP/IP entfernen. Achten Sie in jedem Fall darauf, eventuell erforderliche Kommunikation nicht zu blockieren.

Wenn Sie den Port nicht schließen können, beschränken Sie den Zugriff auf die Systeme, die tatsächlich Zugriff benötigen (z.B. ERP/BI Serversystem(e) statt ganzem Subnetz).

Achten Sie sorgfältig darauf, keine infizierten Rechner oder Datenträger in Ihr Netzwerk einzuschleppen.

Weitere Informationen auch zur Codeausführung beim Öffnen von Projekten (Video 2.2) folgen in den nächsten Tagen. Sie können auch unseren RSS-Feed nutzen, sich registrieren und über Änderungen benachrichtigen lassen , oder persönlich mit uns in Kontakt treten. Demnächst hier auch ein SCADA-Security-Forum.

UPDATE 10.12.2010: Weitere Informationen zur Codeausführung beim Öffnen von Projekten finden sie hier .

WinCC Datenbank-Bug: Schweregrad nach CVSS-Standard

Berechnung des Schweregrads für eine typische Automatisierungs-Umgebung nach dem CVSS -Standard (Ihr CISO sollte Ihnen helfen können, diese Metriken und Vektoren zu interpretieren, weitere Informationen finden Sie auch hier ):

  • CVSS Overall Score Windows 2000: 8.9 /10
  • CVSS Overall Score Windows XP (SQL Server Port closed=default): 8.4 /10
  • CVSS Overall Score Windows XP (SQL Server Port open): 8.7 /10

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