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.


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.


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

US-Verteidigungsminister Robert Gates sieht Cyberwar als Bedrohung für kritische Infrastrukturen, Unternehmen und Behörden und will deshalb die Zusammenarbeit staatlicher Stellen und der Privatwirtschaft weiter ausbauen.

Zuletzt hatte auch die ENISA im Rahmen der CyberEurope 2010 eine europaweite Übung zur Cyber-Security gestartet , die aber diesmal noch auf behördliche Stellen beschränkt war. Wie anfällig europäische Infrastrukturen für Hacker-Angriffe sind, war ebenfalls nicht Gegenstand der Übung.

Erstmals wurde in diesem Jahr mit Stuxnet ein Fall öffentlich, dem nicht wenige Experten die Beteiligung eines oder mehrerer Nationalstaaten nachsagen. Das IT-Sicherheitsunternehmen Imperva sieht daher staatlich geförderte oder politisch motivierte Cyber-Angriffe gar als Nummer 1 unter den IT-Security Trends für 2011 .

Daneben wiesen die Veranstalter der DeepSec Security-Konferenz darauf hin , dass auch die GSM-Mobilfunknetze zu den kritischen Infrastrukturen eines Landes zu rechnen seien. Mobilfunk-gestützte Sicherheitssysteme in Banken, Behörden oder Firmen wären ohne dieses nicht mehr einsatzbereit und auch Notrufe könnten nicht mehr abgesetzt werden.


Es gibt entsprechende Warnungen, Stuxnet könnte der Anfang einer gänzlich neuen Kategorie von Malware seien, die auf kritische Infrastrukturen abzielt, u.a. die Europäische Agentur für Internetsicherheit (European Network and Information Security Agency, ENISA ) hatte gewarnt .

Ralph Langner erläutert , dass ein in S7-Steuerungen vorhandener Designfehler vorhandenes 'Feature' den durch Stuxnet durchgeführten Man-In-The-Middle Angriff überhaupt erst ermögliche.

Er weißt m.E. zu Recht darauf hin , dass damit sowohl Überwachung als auch Steuerung der Automatisierungssysteme gänzlich unmöglich gemacht würden, und ein solches Angriffsschema generisch in entsprechenden Crimeware-Paketen implementiert werden könnte, was die Durchführung eines solchen Angriffs praktisch für Jedermann -vollkommen ohne Insider-Kenntnisse- ermöglichen würde.

Die Leute vergäßen zudem, das Stuxnet in der bekannten Form lediglich einen Transportmechanismus darstelle, damit das eigentliche Problem aber nicht beseitigt sei.


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


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