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.


Auch dieses Jahr werden wir wieder auf der SPS/IPC/DRIVES Messe 2011 anwesend sein, die dieses Jahr vom 22. bis 24. November wieder im Nürnberger Messezentrum stattfindet. Der Veranstalter Mesago Messemanagement war so freundlich, uns Dauerkarten zuzusenden.

Die Messe bricht dieses Jahr schon im Vorfeld mehrere Rekorde und vermeldet erstmals über 1.400 Aussteller aus fast 40 Ländern. Mit erstmals 12 Hallen wird die magische Marke von 100.000 m2 Ausstellungsfläche durchbrochen.

Vereinbaren Sie jetzt einen Termin , um mit uns über Themen wie Sicherheits-Auditierung Ihrer Produkte , Auditierung Ihres Produktionsnetzes oder SCADA/ICS-Sicherheit zu diskutieren.

Ein paar Termine sind kurzfristig noch zu vergeben. Wir freuen uns auf ein persönliches Kennenlernen.

Impressionen von der letztjährigen SPS/IPC/DRIVES Messe 2010 finden Sie hier .

UPDATE 25.11.2011: Wir bedanken uns recht herzlich für all die interessanten und konstruktiven Gespräche auf der Messe und die rege Nachfrage. Im Vergleich zum Vorjahr konnten wir ein stark ansteigendes Interesse am Thema Security verzeichnen und rannten bei einigen Herstellern offene Türen ein, während sich manche immer noch bedeckt hielten.

Die Messe selbst konnte mit über 56.000 Besuchern auch in dieser Hinsicht ebenfalls zulegen.

Nachfolgend ein paar Impressionen der SPS/IPC/DRIVES Messe 2011.

Am ersten Tag konnte die Messe mit Kaiserwetter aufwarten (Innenhof Richtung Halle 4A)

Einer der Hauptpublikumsmagneten der Messe war der Festo SmartBird

An der Software-Front bleiben noch Hausaufgaben zu erledigen...

SIEMENS will mit seinem neuen Geschäftsbereich 'Infrastructure & Cities' auch bei kommunalen Ver- und Entsorgern punkten.

Viele weitere Bilder finden Sie in der nachfolgenden Bildgallerie:


Das ICS-CERT hat die "Protokollmängel" und Sicherheitslücken nochmals in dem Dokument ICS-ALERT-11-223-01 ICS-ALERT-11-223-01A zusammengefasst, das leider nur wenig Konkretes und wenig Klarheit liefert. Hier das Wichtigste in Kürze:

Lesen und Schreiben von Speicherinhalten

("Read/Write of Memory")

  • Auslesen von Speicherinhalten der SPS – Bild (c) Dillon Beresford/NSS Labs

    bestätigt für S7-1200
  • unbestätigt für S7-200/S7-300/S7-400
  • dies soll lediglich ein designgemäßer Mangel des ISO-TSAP Protokolls sein, unklar warum es also nicht für andere Geräte bestätigt wird

 

Ausführen von Befehlen über nicht-verschlüsselte und nicht-authentifizierte Kanäle

("Execution of commands over a clear-text, unauthenticated protocol")

  • bestätigt für S7-1200/S7-200/S7-300/S7-400
  • dies soll lediglich ein designgemäßer Mangel des ISO-TSAP Protokolls sein

Umgehung des Passwort-Authentifizierungsverfahrens

("Bypass of a PLC password protection algorithm")

  • bestätigt für S7-1200/S7-200/S7-300/S7-400
  • soll für S7-1200 behoben sein

Unautorisiertes Abschalten des Passwort-Authentifizierungsverfahrens

[durch Schreiben des Speichers, Anmerkung des Verfassers] ("Unauthorized disabling of a password protection mechanism")

  • Die SPS gibt bereitwillig Auskunft über Typ, Seriennummer und Firmwarestand, sodass etwaige Sicherheitslücken einfach und automatisiert ausgenutzt werden können – Bild (c) Dillon Beresford/NSS Labs

    bestätigt für S7-1200

  • soll für S7-1200 behoben sein
  • unbestätigt für S7-200/S7-300/S7-400
  • unklar warum hier kein konkreter Status (betroffen/nicht betroffen) für diese Geräte benannt wird

Denial-of-Service (DoS) Schwachstelle im eingebetteten Webserver der SPS Firmware

("Denial-of-service (DoS) vulnerability in the Web server embedded in the PLC firmware")

  • bestätigt für S7-1200
  • soll für S7-1200 behoben sein
  • es fehlt ein expliziter Hinweis, dass andere Geräte nicht betroffen sind

Authentifizierte Diagnosefunktionen über TELNET und HTTP mit hartcodiertem Passwort

[konkret auch Hintertürchen genannt, Anmerkung des Verfassers] ("Authenticated diagnostic command shell through both TELNET and HTTP using hardcoded credentials"

  • bestätigt für S7-300 (nur bestimmte ältere Versionen, siehe ICS-ALERT-11-204-01B )
  • Benutzername und Passwort sind bereits öffentlich bekannt
  • es fehlt ein expliziter Hinweis, dass andere Geräte nicht betroffen sind

Mysteriosum: das Transportprotokoll ist an allem Schuld

Es stimmt zwar, dass das ISO-TSAP v3 Protokoll (RFC 1006 ) Authentifizierung und Verschlüsslung nicht vorgesehen hat und damit im wahrsten Sinne des Wortes für 'offene Kommunikation' steht. Es wurde im Mai 1987 letzmalig überarbeitet und ist damit seit nahezu einem viertel Jahrhundert unverändert.

Aber: ISO-TSAP definiert lediglich den Transport, aber nichts zum Lesen und Schreiben von Speicherinhalten, Passwortsicherungen, oder dem Ausführen von Kommandos. Es ist, als würde man behaupten, TCP/IP wäre daran Schuld, dass die Kennwortsicherung meines FTP-Servers nicht funktioniert.

Die Authentifizierung und Verschlüsslung muss auch nicht auf Ebene des Transports passieren; dies ist sogar die Regel, wenn wir prominente Internet-Protokolle wie HTTPS oder SSH betrachten, die alle nicht auf der Transportebene sichern.

Warum ist die Information immer noch so vage?

Sowohl dem ICS-CERT als auch SIEMENS als Hersteller stehen Dillons Exploits und entsprechende SPS'en zur Verfügung. Welche Geräte von welchen Problemen betroffen sind, läßt sich locker in weniger als einer Stunde ermitteln. Der geneigte Leser mag sich die Frage stellen, wieso fast drei Monate nach dem Bekanntwerden der Probleme immer noch so wenig Information verfügbar ist und das Papier des ICS-CERT für einige Probleme auf einigen Maschinen immer noch ein "unconfirmed" ("unbestätigt") enthält.

Der Hersteller, der nicht will, und das CERT, das nicht darf?

Dale G. Peterson gibt hierzu eine eigene Theorie ab . Er erklärt, dass ICS-CERT sei identisch mit dem Idahoe National Laboratory (INL). Das INL hätte seit Jahren Sicherheitsuntersuchungen mit hohen Budgets für die großen Hersteller durchgeführt und Equipment im Wert von Hunderttausenden von Dollar für Ihre Labore erhalten.

Anschließend sei das INL mit der Aufgabe als Industrial Controls Systems Computer Emergency Response Team (ICS-CERT) betraut worden, da dies der richtige Platz für die Ansiedlung zu sein schien.

Die vorhandenen Kontakte zu den großen Herstellern seien jedoch kein Kapital für das INL gewesen, sondern Verpflichtungen. Zudem sei das INL aus früheren Zeiten mit Geheimhaltungsvereinbarungen geknebelt, sodaß es seine Aufgabe gar nicht wahrnehmen könne, und darüber hinaus in einem riesigen Interessenskonflikt stünde.

Hier noch die Dokumente von Dillon Beresford. Für Insider: es lohnt sich besonders, den Abschnitt "Disclosure Process" im White Paper zu lesen und zu überdenken.

UPDATE 23.08.2011: Das ICS-CERT hat Update A zum ICS-ALERT-11-223-01 veröffentlicht, Link oben aktualisiert. Statt mehr Transparenz in die Sache zu bringen, als einzige Ergänzung die zweizeilige Ansage, das es "auf Grund der getroffenen Designentscheidungen" nicht möglich sei, alle Probleme kurzfristig zu lösen. Ich hätte da schon einen Tipp, auf was das hinausläuft...

Der Kollege Ralph Langner hat nun auch einen Artikel, in dem er die "fehlerhafte Analyse und irreführenden Ratschläge " des ICS-CERT viel ausführlicher beschreibt, als ich das oben getan habe. Er kommt zur gleichen Schlussfolgerung, dass eben nicht das offene Transportprotokoll ISO-TSAP der Grund für die Mängel ist und hat sogar den selben Vergleich mit FTP + TCP/IP herangezogen wie ich.


Nach Angriffen auf das Sony Playstation Network , dem Ausspähen von 90.000 Passwörtern des US-Militärs und dem vor kurzem erfolgten Leak von über 2500 Datensätzen mit Namen, Anschriften, Telefonnummern und Email-Adressen von Mitarbeitern und Kontakten des Agrar-Patent-Giganten Monsanto hat Anonymous nun offenbar die Ölindustrie ins Visier genommen.

Zu den Zielen der "#operationgreenrights" genannten Aktion sollen die Firmen Exxon Mobil, ConocoPhillips, Canadian Oil Sands Ltd., Imperial Oil, die Royal Bank of Scotland und "viele andere" gehören. Dies kündigte die Verbindung in einem Video an.

Die Aktivisten beklagen die "Gier" dieser Firmen, die Wildniss in Wüsten verwandeln würden. Gerade die Gewinnung von Öl aus Ölsand steht immer wieder in der Kritik, da sie enorme Mengen an Trinkwasser und Energie verbraucht und schwer aufbereitbares Abwasser hinterläßt.

Die Gruppe hatte in der Vergangenheit bereits den Code des Stuxnet-Wurms in den Umlauf gebracht und auch mit Angriffen auf kritische Infrastrukturen gedroht.

UPDATE 22.07.2011: Offenbar haben die kürzlich erfolgten Verhaftungen mutmaßlicher Anonymous-Mitglieder in den Vereinigten Staaten , den Niederlanden und Großbritannien wenig Wirkung gezeigt. Bei den Verhaftungen in USA ging es behördenangaben zufolge primär lediglich um die DDoS-Angriffe auf den Bezahldienstleister PayPal Ende letzten Jahres. Der Angriff erfolgte als Reaktion auf die Einstellung aller Zahlungsabwicklungen an WikiLeaks. Den übrigen Verhafteten wird Computersabotage in verschiedenen Fällen vorgeworfen.

Nun behauptet die Bewegung via Twitter, in Computersysteme der NATO eingedrungen zu sein und dadurch über ungefähr ein Gigabyte teils vertraulicher Dokumente zu verfügen. Diese sollen teilweise in den nächsten Tagen veröffentlicht werden. Ein angeblich vertrauliches Dokument wurde bereits veröffentlicht, die Echtheit ist bisher jedoch nicht bestätigt.


Laut englischem Bericht des Wired Magazine wurde ein Vortrag auf der Takedown Sicherheitskonferenz in Dallas vergangenen Mittwoch kurzfristig abgesagt, nachdem das Department of Homeland Security (DHS) und SIEMENS Bedenken angemeldet hätten.

In dem Vortrag "Chain Reactions - Hacking SCADA " von Dillon Beresford von NSS Labs und dem unabhängigen Sicherheitsforscher Brian Meixell sollte über vier neu entdeckte Sicherheitslücken in SIEMENS Kontrollsystemen berichtet werden. Mindestens eine der Lücken soll sich eventuell auch auf Kontrollsysteme anderer Hersteller auswirken.

Dem Bericht zufolge nach geht es -im Unterschied zu den von uns entdeckten Sicherheitslücken - um Sicherheitsprobleme direkt in Speicherprogrammierbaren Steuerungen (SPS) . SIEMENS würde noch an Sicherheitsupdates arbeiten und hätte zwischenzeitlich eine Methode gefunden, die die Ausnutzung der Sicherheitslücke verhindern sollte. Beresford konnte diese Methode nach eigenen Angaben jedoch ohne Weiteres ebenfalls überlisten, irgendwie ein "Déjà Vu" für mich.

NSS Labs hätte betont, das es entgegen der Gerüchteküche auf Twitter keinen juristischen Druck seitens des Department of Homeland Security (DHS) oder SIEMENS gegeben hätte und man die Entscheidung, den Vortrag abzusagen, frei aus eigenen Erwägungen getroffen hätte. Dies ist womöglich eine weise Entscheidung.

Fi Untersuchung: meherere Dutzend SPS frei zugänglich im Netz!

Noch vor kurzem hatte ich bei einer kurzen Websuche mehrere Dutzend Webadministrationsoberflächen von SPS'en frei zugänglich in Netz gefunden. Stichproben ergaben, dass einige Administrationsoberflächen noch nicht einmal durch ein Kennwort gesichert waren – darunter unter anderem mehrere Energieversorger und Unternehmen der Lebensmittelindustrie. Über diese Oberflächen wäre es direkt möglich gewesen, die Steuerungen herunterzufahren oder -schlimmer- manipulierte Firmware einzuspielen. Ein sträflicher Leichtsinn der mich in größtes Erstaunen versetzt hat.

Fazit

Es bleibt abzuwarten, um welche Mängel es sich hier tatsächlich handelt. Womöglich sind dies auch einige, die schon lange Zeit bekannt sind, ohne dass es jemanden zu interessieren scheint. Das mit den frei zugänglichen Administrationsoberflächen ist prinzipiell auch ein Fehler des Herstellers, zumindest einer, den der Hersteller einfach vermeiden könnte. Hersteller, die WLAN-Router für unter 100€ verkaufen, machen vor, wie es gehen könnte ;)

Das Idaho National Laboratory und SIEMENS haben sich bei Ihrer großen Security-Untersuchung 2008 mit Millionenetat und allem erdenklichen Equipment wahrscheinlich nicht gerade mit Ruhm bekleckert. Meines Erachtens nach hat sich selbst fast ein Jahr nach Stuxnet nichts Wesentliches getan. Die von uns entdeckten Sicherheitsprobleme sind unserer Kenntnis nach weiterhin nicht behoben, jedenfalls hat man es nicht für nötig erachtet, eine eventuell vorhandene Lösung mit uns zusammen zu verifizieren.

UPDATE 26.05.2011: Bisher ist lediglich öffentlich bekannt, dass Dillon Beresford die Mängel zumindest in kleineren S7-1200-Steuerungen belegen konnte, die wohl kaum in hochsensitiven Bereichen eingesetzt werden. Es bleibt abzuwarten, ob davon auch größere Systeme betroffen sind, bei denen ein potentiell hoher Schaden entstehen könnte. Offenbar ist man sich seiner Sache aber selbst nicht so sicher, sonst hätte man Beresford wohl nicht dazu bewegen müssen, seinen Vortrag abzusagen.

Unterbleibt eine klare Kommunikation, entstehen Spekulationen und Bedenken. Zudem wurden die Sicherheitsmängel als „durch Außenstehende schwer zu beurteilende“ „unter Laborbedingungen entstandene“ „Unregelmäßigkeiten“ bagatellisiert, die bei „normalen IT-Sicherheitsmaßnahmen kein Risiko darstellen“ und „nicht leicht von jedermann auszunutzen“ seien. Statt dieser äußerst wackeligen Argumentationsweise wäre es womöglich angebrachter gewesen, konstruktiv Risiken, betroffene Systeme und Konfigurationen sowie Möglichkeiten zur Schadensbegrenzung zu nennen und eine Problemlösung anzupacken.

Laut Beresford sei es bei den betroffene(n) Steuerunge(n) möglich

  • sie zu stoppen, sodass lediglich eine Unterbrechung der Stromzufuhr die Steuerung wieder aktivieren kann (DoS )
  • den Speicher auszulesen und zu beschreiben
  • eine Reprogrammierung durchzuführen

UPDATE 15.06.2011: Wie schon gemutmaßt betrifft das Problem S7-1200 Steuerungen (ICS-CERT Security Alert 11-161-01 , SIEMENS Security Advisory 625789 , Updates ). Die S7-1200 ist ohne das Update anfällig für das Abspielen aufgezeichneter Passwortfolgen ("Password-Replay") und kann zudem durch "Denial of Service (DoS)"-Attacken lahm gelegt werden. Das ICS-CERT konnte die Beseitigung der Probleme durch das Update bestätigen.

UPDATE 06.07.2011: Nun meldet das ICS-CERT (ALERT 11-186-01 ), dass die Passwort-Replay-Attacken offenbar doch nicht nur S7-1200er Steuerungen betreffen, sondern auch alle Modelle der S7-200er, S7-300er, und S7-400er Serien. Dies ist dem Hersteller seit 8 Wochen(!) bekannt oder wäre seitdem zumindest in 10 Minuten ermittelbar gewesen. Besonders für die größeren S7-400er hätte ein Update aufgrund der Einsatzbereiche wesentlich höhere Priorität gehabt als für die S7-1200er-Serie, bei der das Problem mittlerweile behoben ist. Hinzu kommt, dass selbst jetzt weder beim SIEMENS CERT noch auf dem Industrial Security-Portal des Herstellers vor dem Problem gewarnt wird. Das ist es, was ich mit unklarer Kommunikation und mangelnder Transparenz meinte.

UPDATE 04.08.2011: Auf der Industrial Security Seite hat SIEMENS mittlerweile einen Hinweis eingefügt, dass auch Modelle der S7-200er, S7-300er und S7-400er Serien mit ähnlichen Problemen zu kämpfen haben wie die S7-1200er Modelle. Updates stehen noch aus.

Durch die Berichterstattung zur laufenden BlackHat-Konferenz ist das Thema von offen im Internet zugänglichen Automatisierungssystemen hochgekocht, das eigentlich nur eine "Randnotiz" dieses Blog-Artikels war. Dies ist natürlich erst einmal eine Fehlkonfiguration seitens des Kunden bzw. Implementierers. Die Hersteller hätten jedoch leicht die Möglichkeit, die Geräte so vorzukonfigurieren, dass selbst eine solche Fehlkonfiguration nicht zum Desaster führen kann. Es ist häufig eine Verkettung von Fehlern auf seiten der Hersteller und der Benutzer, die zu einem potentiell angreifbaren System führen.

UPDATE 19.08.2011: Aktuellere Erkenntnisse hier , fortlaufende Berichterstattung im Blog .

Read this article in English - Google Translate sry for bad English!


Diesen Monat haben zwei Institutionen unabhängig voneinander Studien zur IT-Sicherheit in der Energiewirtschaft bzw. in der Energie- und Wasserwirtschaft veröffentlicht. Deren wichtigste Ergebnisse will ich im Folgenden zusammenfassen und einordnen. Insgesamt waren die Ergebnisse aus meiner Sicht wenig überraschend.

Q1 Labs/Ponemon Institute Studie

In einer von Q1 Labs und dem Ponemon Institute durchgeführten Studie wurden international 291 zufällig ausgewählte IT-Verantwortliche aus der Energiewirtschaft befragt. Die Studie kommt u.a. zu folgenden Ergebnissen:

  • 75% der Organisationen hätten mindestens einen erfolgreichen Cyberangriff in den letzten 12 Monaten verzeichnet
  • 71% der IT-Verantwortlichen sagten, Ihr Management verstünde oder würdige IT-Sicherheit nicht
  • 72% sagten, bisherige Ansätze seien nicht effektiv, aussagekräftige Daten über tatsächliche oder mögliche Attacken (z.B. Echtzeitalarme, Bedrohungsanalysen und Priorisierung) zu erhalten
  • nur 21% glaubten, dass ihre existierenden Mechanismen ausreichend seien, um Attacken aus SmartGrids oder von SmartMeter -verbundenen Geräten zu verhindern
  • nur 39% glaubten, gegen Advanced Persistent Threats (APTs ) ausreichend abgesichert zu sein
  • 67% seien eigenen Angaben zufolge nicht auf dem aktuellen "Stand von Wissenschaft und Technik "

McAfee/CSIS Studie

In einer zweiten, von McAfee und dem Center for Strategic and International Studies (CSIS) durchgeführten Studie wurden die Antworten von 200 zufällig ausgewählte Führungspersonen privater Betreiber aus der Energie- und Wasserwirtschaft in insgesamt 14 Ländern analysiert. Um einen vollständiges Bild erfassen zu können, habe ich die Veröffentlichung der gesamten Studie in der Woche vor Ostern abgewartet, statt die auszugsweise Vorab-Berichterstattung anderer Medien aufzugreifen.

Mehr Erpressungen, mehr Angriffe, neue Risiken

  • 25% wären Opfer von Erpressungen innerhalb der letzten 24 Monate geworden, 2009 lag die Zahl noch bei 20%. Regional angeführt würde die Statistik von Mexiko und Indien, wo gar 80% bzw. 60% Opfer von Erpressungen gewesen seien.
  • die Frequenz der Angriffe steige
  • die Einführung von SmartGrids und SmartMetering würde das Risiko zusätzlich erhöhen

Stuxnet: Infektionszahlen und Konsequenzen

Der berüchtigte Stuxnet-Wurm sei

  • bei rund 40% aller befragten Unternehmen gefunden worden
  • mit 46% aller Unternehmen sei die Elektrizitätsbranche besonders betroffen gewesen
  • Spiegel Online hatte unter Berufung auf McAfee vorab berichtet , in Deutschland seien gar 59% der Energie- und Wasserversorger befallen gewesen; in der Studie selbst finden sich jedoch keine auf Länder heruntergebrochenen Zahlen.

Die größten Konsequenzen aus dem Stuxnet-Vorfall seien in den Vereinigten Arabischen Emiraten, Italien und Japen gezogen worden, die vergleichsweise geringe Infektionszahlen gehabt hätten. Diese gehören jedoch zu den Staaten, die lt. der Studie allgemein die meisten Sicherheitsmaßnahmen implementiert hätten, mehr dazu im Folgenden.

Risikoeinschätzung der Branche und Realität

  • Malware: fast 80% sähen sich "sehr gut" oder "gut" vorbereitet, dennoch wurden 40%+ alleine Opfer von Stuxnet (Gesamtzahlen inklusive anderer Malware liegen leider nicht vor). Hinzu kommt, dass Stuxnet über ein Jahr sein Unwesen treiben konnte, ohne das irgendjemand etwas bemerkt hatte. Gute Vorbereitung sieht m.E. anders aus.
  • Netzwerkeinbrüche: knapp über 60% sähen sich "sehr gut" oder "gut" gewappnet, dennoch wurden 85% Opfer eines solchen Angriffs. Die o.g. Einschätzungen aus der Ponemon-Studie scheinen ebenfalls ein deutlicher Widerspruch zu diesem Wert zu sein.
  • Denial of Service (DoS ): lediglich ca. 50% sähen sich "sehr gut" oder "gut" vorbereitet, 80% wurden in der Praxis mit dem Problem konfrontiert, über die Auswirkungen gibt es aber leider ebenfalls keine Daten.

Erstaunlich finde ich hier, dass sich 80% bzw. 60% Malware und Netzwerkeinbrüchen entspannt gegenüber sehen, während dies bei der aus meiner Sicht wesentlich geringeren und einfach zu beseitigenden Gefahr der DoS-Attacken nur bei 50% der Fall ist. M.E. zu Recht werden in der Studie DoS-Attacken als "Kinderkram" bezeichnet, verglichen mit moderner Malware.

Besonders bei den Themen Malware und Netzwerkeinbrüchen legen die Zahlen auch eine deutliche Schere zwischen "gefühlter" und "realer" Sicherheit nahe. Dies bestätigt meine schon häufig geäußerte Beobachtung eines überzogenen Glaubens an Firewalls und Virenscanner .

Regional gibt es ebenfalls interessante Beobachtungen:

  • in Brasilien, wo 2005 und 2007 große Stromausfälle beobachtet wurden, die nicht wenige Experten auf Malware-Befall zurückführen, fühlen sich 91% unvorbereitet für Malware-Attacken
  • in Australien, wo große Aufklärungskampagnen in Sachen Cybersecurity und Schutz kritischer Infrastrukturen seitens der Regierung durchgeführt wurden, fühlten sich 90% unvorbereitet auf Netzwerkeinbrüche

Umsetzung von Sicherheitsmaßnahmen zu langsam

Alle Branchen hätten die Sicherheitsmaßnahmen seit 2009 erhöht. Gemessen wurde hier jedoch nur die Zahl der eingesetzten Technologien, nicht jedoch deren Effizienz, Ausgewogenheit oder technische und organisatorische Umsetzung. Diese Zahlen können also nur als Anhaltspunkt zur Sicherheitslage gesehen werden und geben nicht unbedingt direkt Auskunft über das absolute Sicherheitsniveau.

  • die Wasserver- und Entsorgungsbranche hätten nominell die meisten zusätzlichen Maßnahmen von 38% auf 46% verzeichnet, bildeten aber dennoch weiter das Schlusslicht unter den untersuchten Branchen
  • Öl und Gas hätten nominell von 45% auf 48% zugelegt
  • die Elektrizitätsbranche hätte sich von 50% auf 51% nominell lediglich minimal gesteigert

Die Studie kommt dabei zu dem Schluss, dass die Adaption von Sicherheitstechnologien mit dem Fortschreiten der Bedrohungslage nicht Schritt halten könne.

Regional gibt es ebenfalls signifikante Unterschiede:

  • China (59%), Italien (55%) und Japan (54%) führten die Statistik an
  • Mexiko, Frankreich und Brasilien bildeten die Schlusslichter
  • die restlichen Staaten, u.a. Deutschland, lägen im Mittelfeld um 43%

Staatliche Kontrolle und Regulierung

Staatliche Audits sind in vielen Ländern in unterschiedlichem Ausmaß üblich.

  • Japan (100%), China (70%) und die Vereinigten Arabischen Emirate (ca. 65%) hätten hier die höchsten Quoten
  • Deutschland läge mit 40% abermals im Mittelfeld
  • die geringste Anzahl staatlicher Audits fänden in Italien, den Vereinigten Staaten, Spanien und im Vereinigten Königreich statt

Interessanter Weise stiege das Vertrauen in staatliche Institutionen mit der Dichte der Kontrollen. Einen Ausnahmestatus hätte das japanische Modell inne, bei dem man durchgängig auf "Public-Private Partnerships" setzte, die die Autonomie der Infrastrukturbetreiber ausdrücklich anerkennen, und eher motivieren statt regulieren möchten.

Staaten als Bedrohung

Die Unternehmen befürchteten auch Spionage oder Sabotage fremder Staaten. Dies ist nicht verwunderlich, können Cyberwaffen doch – im Gegensatz zu konventionellen – mit relativ geringem Budget auch von kleineren Staaten hergestellt werden, und ohne wesentlich erhöhten Aufwand mehrere Ziele parallel anvisieren.

  • China (30%), Russland (16%), die Vereinigten Staaten (12%) und Nordkorea (11%) würden global am häufigsten gefürchtet
  • die deutlichste Veränderung hätte sich bei den Vereinigten Staaten (12%) ergeben, die 2009 noch von 36% gefürchtet worden wären

Naturgemäß gibt es besonders hier regional signifikante Unterschiede

  • in China sähen 3/4 die Vereinigten Staaten als größte Gefahr
  • in Japan hätten 2/3 aller Befragten China oder Nordkorea als am gefährlichsten benannt
  • in den Vereinigten Arabischen Emiraten sähen 2/3 die Nachbarn im Mittleren Osten mit Argwohn
  • in Australien sähe man Russland als größte Bedrohung (40%)
  • in Indien fürchtete man erstaunlicher Weise das Vereinigte Königreich (fast 1/3) deutlich mehr als China (14%)

Fazit

Mit zunehmender Aufklärung oder praktischer Konfrontation mit einem konkreten Problem steigt auch das Risikobewusstsein der Unternehmen. Dies untermauern auch die o.g. Beispiele von Brasilien und Australien. Nicht selten sind auch Kommunikationsprobleme zwischen IT-Bereich und Management die Ursache für mangelnde oder wenig sinnvolle Investitionen in die Sicherheit, was auch die Ponemon-Studie verdeutlicht.

In unseren Security Audits und Penetrationstests setzen wir theoretische Szenarien praktisch um und veranschaulichen damit, wie ein Angriff durch Insider, Hacker oder Schadsoftware ablaufen würde und welche Konsequenzen dies hätte. Hieran lassen sich die Effizienz vorhandener Sicherheitstechnik oder geplanter Anschaffungen praktisch erfassen und eventuell vorhandene Schutzlücken aufdecken. IT-Abteilungen können so Ihr Management effektiv von der Notwendigkeit einer Maßnahme überzeugen. Umgekehrt kann das Management den Nutzen der Maßnahmen der IT-Abteilungen direkt nachvollziehen. Nehmen Sie Kontakt mit uns auf, gerne beraten wir Sie individuell, schulen Ihre Mitarbeiter, oder geben verbindliche Gutachten (z.B. herstellerneutrale Produktvergleiche, Aufwand/Nutzen, Machbarkeit, Strategieempfehlungen) zu geplanten Maßnahmen ab.


Das (schwarze) Lamm

Bild (c) Don & Tonya Christner

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

Der Löwe

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

Der schlafende Drache

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

Der (ebenfalls schlafende?!) Dickhäuter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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