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.


Luigi Ariemma hat gestern erneut diverse Sicherheitslücken in Industriesoftwareprodukten veröffentlicht. Bereits im März diesen Jahres hatte er 34 Lücken in SCADA und HMI-Systemen offengelegt . Betroffen sind diesmal die folgenden Produkte und Versionen:

Es ist davon auszugehen, das ältere Versionen der genannten Produkte ebenfalls mit diesen Sicherheitslücken behaftet sein könnten.

Gerne können Sie sich an uns wenden , wenn Sie als Hersteller oder Anwender dieser Produkte betroffen sind. Wir helfen Ihnen gerne bei der

  • Fehlerbeseitigung
  • Auditierung, Risikobewertung und -minderung
  • Signaturentwickelung für Intrusion Detection/Prevention Systeme und
  • Modulentwicklung für Vulnerability Scanning/Vulnerability Assessment Produkte.

Nochmals mein Appell an die Hersteller

Wenn Sie Hersteller sind, bieten Sie ein 'Bug Bounty' Programm. Zeigen Sie Sicherheitsforschern und Kunden damit, das Ihnen die Sicherheit Ihrer Produkte wirklich etwas wert ist und Sie Interesse an entsprechender Zusammenarbeit haben. Sicherheitsforschung dient Ihnen und der Sicherheit Ihrer Kunden, zum Nulltarif kann das aber nicht funktionieren. Als neutral gedachte Stellen wie das ICS-CERT nehmen Ihre Aufgaben leider auch unzureichend wahr . Nur mit einer partnerschaftlichen Zusammenarbeit und finanziellen Anreizen wird man fähige Leute wie Luigi Ariemma überzeugen können, Ihre Arbeit nicht einfach zu veröffentlichen oder gar am Grau- oder Schwarzmarkt zu verkaufen.

UPDATE 19.09.2011: Mittlerweile verfügbare CVE-Nummern ergänzt, Hinweise auf öffentlich kursierende Exploits ergänzt, Konkretisierung zu Progrea Movicon und Azeotech DAQFactory.

UPDATE 20.09.2011: Aktualisiertes Advisory zu Rockwell RSLogix.

UPDATE 21.09.2011: Aktualisiertes Advisory zu Measuresoft ScadaPro, Update 4.0.1 verfügbar.

UPDATE 22.09.2011: Aktualisiertes Advisory zu Azeotech DAQFactory, Update 5.86 verfügbar. Cogent DataHub: Hinweis auf öffentlich kursierenden Exploit ergänzt und Information konkretisiert.

UPDATE 27.09.2011: Zwei weitere 0day-Lücken in Carel PlantVisor sind aufgetaucht. Hinweis auf kursierende Exploits ergänzt.

UPDATE 29.09.2011: Luigi Auriemma hat weitere Lücken in Sunway ForceControl SCADA und ARC Informatique PcVue veröffentlicht. Zu Sunway ForceControl SCADA kursiert bereits ein öffentlicher Exploit. Entsprechende Informationen hinzugefügt.

UPDATE 04.10.2011: Neues Advisory zu Rockwell RSLogix, Security-Updates zu einigen Versionen erhältlich.

UPDATE 07.10.2011: Aktualisiertes Advisory zu Rockwell RSLogix, Security-Updates zu allen Versionen erhältlich.

UPDATE 10.10.2011: Advisories und Security-Updates zu Cogent DataHub und Beckhoff TwinCAT. Betroffene Versionen konkretisiert.

UPDATE 17.10.2011: Luigi Auriemma hat nochmal nachgelegt und weitere Produktlücken veröffentlicht. Betroffen sind diesmal IRAI Automgen, atvise webMI2ADS, Open Automation Software OPC Systems.NET und MICROSYS Promotic. Zudem ist ein öffentlicher Exploit zu PcVue erschienen. Informationen oben ergänzt.

UPDATE 22.10.2011: Advisory zu Progea Movicon, der Hersteller stellt Updates bereit. Informationen ergänzt.

UPDATE 28.11.2011: Zu Beckhoff TwinCat, atvise webMI2ADS, Open Automation Software OPC Systems.NET und MICROSYS Promotic sind Exploits erschienen. Luigi Auriemma hat heute weitere Lücken im Siemens Automation License Manager und in Siemens SIMATIC WinCC flexible SP2 Security Patch 1 veröffentlicht. Diese Versionen liegen uns momentan nicht vor, sodass wir diese Bugs im Moment nicht testen können. Informationen oben ergänzt bzw. aktualisiert.

UPDATE 29.11.2011: Ein weiterer Bug in MICROSYS Promotic: Speicherbenutzung nach Freigabe ("use-after-free"). 3S CoDeSys hat es ebenfalls erwischt. Das ICS-CERT ist aufgewacht und hat Alerts für SIEMENS Automation License Manager, SIEMENS WinCC flexible und Optima APIFTP Server herausgegeben; im letzteren Fall mit kaum mehr als zwei Wochen Verzögerung. Informationen ergänzt.

UPDATE 30.11.2011: Zweiter Alert des ICS-CERT zu MICROSYS Promotic. Link ergänzt.

UPDATE 02.12.2011: Öffentlicher Exploit zu 3S CoDeSys erschienen. Warnung ergänzt. ICS-CERT nach kurzer Wachphase wieder im Tiefschlaf.

UPDATE 03.12.2011: Aktualisierter Alert zu SIEMENS Automation License Manager, SIEMENS WinCC flexible und endlich ein Alert zu 3S CoDeSys. Der Alert zu 3S CoDeSys ist nicht nur verspätet, sondern auch noch falsch und unvollständig: Researcher war Luigi Ariemma, Hinweis auf öffentlichen Exploit fehlt, Liste der Mängel ist unvollständig.

UPDATE 07.12.2011: Advisory des ICS-CERT und Updates zu PcVue verfügbar. Daneben sind die Schwesterprodukte FrontVue/PlantVue ebenfalls betroffen. Informationen zu den Schwachstellen konkretisiert und CVE-Nummern hinzugefügt.

UPDATE 08.12.2011:Das ICS-CERT hat das unvollständige Advisory zu 3S CoDeSys korrigiert.

UPDATE 13.01.2012: Aufgrund unseres Urlaubs diesmal etwas verspäteter Nachtrag: Updates zu CoDeSys, dem SIEMENS Automation License Manger und OPC Systems.NET sind erschienen, das ICS-CERT hat entsprechende Advisories herausgegeben. Um es gleich vorweg zu nehmen: Das SIEMENS-Update lindert zwar scheinbar die gemeldeten Fehler, aber der Automation License Manager bleibt nach wie vor anfällig. Bereits mit dem trivialsten möglichen Test ist es uns gelungen, ALM zum Absturz (Denial of Service) zu bringen, was einen Anlagenstillstand auslösen könnte. Weitere Informationen oben im entsprechenden Abschnitten ergänzt.

UPDATE 17.01.2012: Mit dem Rockwell FactoryTalk RNADiagServer gesellt sich ein weiteres Produkt zur Liste. Hinweise ergänzt.

UPDATE 28.01.2012: Aktualisiertes Advisory zu OPC Systems.NET. Ein weiterer Fehler (Pufferüberlauf) wurde veröffentlicht, der mit dem Update 5.0 aber offenbar ebenfalls korrigiert ist. Advisory zu MICROSYS Promotic, ein Update ist erschienen, das die Fehler korrigieren soll. Nach den vorliegenden Informationen wurden aber scheinbar nur 3 von insgesamt 4 Fehlern behoben. Entsprechende Informationen und CVE-Nummern ergänzt.

UPDATE 12.04.2012: Certec veröffentlicht Updates zu atvise webMI2ADS und MICROSYS beseitigt den verbliebenen, bisher nicht behobenen 'Use-After-Free' Fehler in Promotic. Entsprechende Informationen, CVE-Nummern, Advisories und Update-Links ergänzt.


BlackHat Las Vegas 2011 - Embedding Security

BlackHat Las Vegas 2011 - Embedding Security

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

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

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


Man mag es als 'Dummheit' bezeichnen, Automatisierungssysteme ins öffentliche Netz zu stellen, aber es ist nicht unbedingt Dummheit.

Arroganz der Sicherheitsfachleute

Ich halte es da mit Bruce Schneiers Kommentar (deutschsprachiger Bericht bei WinFuture ), der auf eine Untersuchung , wie viele Benutzer gefundene USB-Sticks arglos in PCs einstecken, feststellte, dass dies keine Dummheit wäre. Schließlich seien USB-Sticks doch genau dafür da. Dummheit wäre es, zu versuchen 'darauf zu spielen wie auf einer Okarina ' oder damit 'ein Omelett zubereiten' zu wollen. Er wirft den Sicherheitsleuten Arroganz vor und hält die Untersuchung an sich für sinnlos. Für ihn ist es, als würde man zu der Erkenntnis gelangen '75 Prozent der Menschen, die eine liegen gelassene Zeitung im Bus finden, lesen diese'. Im Hintergrund eines Computersystems gingen jedoch zu viele implizite Dinge vor sich, von denen der Benutzer im Allgemeinen nichts wüsste. Er sieht hier klar die Hersteller in der Pflicht, nicht einfach Programme von potentiell nicht vertrauenswürdigen Datenträgern zu starten. Microsoft hat hier im Übrigen auch gehandelt .

1 Fehler + noch 1 Fehler = 1 Problem

Ähnlich ist es auch im vorliegenden Fall: SPS'en sind dazu gemacht, sie ans Netz anzuschließen, wenn auch nicht unbedingt ans öffentliche Netz. Dennoch geben weder Beschreibung noch die Administrationsoberfläche einen solchen Hinweis ('Sind Sie sicher, dass Sie eine öffentliche IP-Adresse verwenden möchten?'). Auch ein werksseitig individuell pro Gerät gesetztes Passwort gibt es leider nicht ('secure by default'). Wenn zusätzlich noch eine Sicherheitslücke vorhanden ist, und sich die SPS gar noch ohne ein Passwort stoppen lässt ('Denial of Service'), ist das Desaster perfekt.

Die Legende vom 'Air Gap' oder 'Inselnetz'

Selbst ohne öffentlich im Netz erreichbar zu sein, sind Automatisierungssysteme Gefahren ausgesetzt. Gelingt ein Einbruch in das Firmennetzwerk, kann ein Hacker oder eine Schadsoftware von dort auf die Automatisierungssysteme zugreifen. Die Legende vom 'Air Gap', der physikalischen Trennung von Firmennetz und Anlagennetz, wird zwar immer noch hartnäckig propagiert, dürfte jedoch für Anwender komplexerer oder verteilter Anlagen mit Produktionsplanung-Steuerung, Extranet und Koordination mit Zulieferern/Kunden kaum realisierbar sein. Selbst physikalisch isolierte Netzwerke sind nicht ohne Risiko, da über tragbare Rechner und Wechseldatenträger ebenso Schadsoftware eingeschleppt werden kann, nichts anderes war bei Stuxnet der Fall. Vor fast einem Jahr hatte ich über diese und weitere Fakten bereits geschrieben . Wie einer der amerikanischen Kollegen jüngst festgestellt hatte, existiert ein solches 'Air Gap' nicht einmal in den Sicherheits-Leitfäden von SIEMENS oder Rockwell – er spottete 'Can you spot the air gap [...]? Funny, neither can I.'

Fazit

Überall wo Menschen arbeiten, passieren Fehler. Vorausschauendes und verantwortliches Handeln eines Platformanbieters kann jedoch größeren Schaden durch einen solchen Fehler häufig verhindern. Vor allem flächendeckenden Schaden. Platformanbieter und Implementierer sind hier aus meiner Sicht mehr in der Pflicht als der Endkunde, dennoch muss auch der Endkunde seinen Blick für Gefahren schärfen, da er letztendlich auch immer der primär Betroffene sein wird.

Es gibt jedoch in der heutigen vernetzten Welt keine Alternative – Automatisierungssysteme müssen sicher werden. Hört endlich auf, den Kunden die Schuld zu geben.

P.S.: (!) Wer seine S7-300-Firmware schon Ewigkeiten nicht mehr aktualisiert hat, sollte dies schleunigst tun. Auch hier gab es hart-codierte Passwörter ('Backdoors'), die seit heute öffentlich im Netz stehen (ICS-CERT Security Alert 11-204-01B ). Auffindbar für jeden, der es nicht ohnehin schon wusste.


Das Industrial Control Systems Cyber Emergency Response Team (ICS-CERT ) warnte vor Shodan, einer Suchmaschine zum Aufspüren bestimmter Serverdienste im Internet, heise online hatte berichtet . Zu Recht weißt Daniel Bachfeld in dem Artikel darauf hin, das dies eigentlich ein alter Hut ist.

Zudem ist das Aufspüren von SCADA-Diensten noch viel einfacher: über öffentliche 'Whois' Datenbank-Einträge lassen sich die IP-Adressbereiche bekannter Anwender ermitteln und dann entsprechend durchforsten.

Empfehlungen

Neben den Empfehlungen des ICS-CERT rate ich daher dringend davon ab, solche Dienste im eigenen, öffentlich bekannten IP-Adressraum zu betreiben, selbst wenn diese durch ein vorgeschaltetes VPN abgeschirmt sind. Eine Sicherheitslücke im VPN-Dienst könnte gravierende Folgen haben und gezielte automatische Attacken ("autopwnage") ermöglichen.


TrendMicro hat das Stuxnet Scanner Tool herausgegeben , des es ermöglicht, mit dem Wurm infizierte Rechner im Netzwerk aufzuspüren. Es täuscht dazu einen Stuxnet-infizierten Rechner vor und verwendet reproduzierte Remote Procedure Call Anfragen, wie sie Stuxnet normalerweise nutzt, um andere Rechner im Netz mit aktualisiertem Schadcode zu versorgen. Ein infizierter Rechner antwortet auf diese Anfragen und kann dadurch entlarvt werden.

Finally still not really 0wning Stuxnet

Optimal ist diese Vorgehensweise dennoch nicht, da eine manuelle Entfernung des Virus nach wie vor nötig ist. Unter dem Arbeitstitel "0wning Stuxnet" haben wir hier schon länger ein Konzept erdacht, dass Stuxnet im Netzwerk ein Update zu dessen Konfigurationsblock schicken sollte, der neue Command & Control Server beinhaltet, die unter Kontrolle des betroffenen Anwenders stehen.

Über diese Command & Control Infrastruktur wäre es dann möglich gewesen, Stuxnet infizierten Rechnern im Netzwerk direkt einen Code-Block zu schicken, der Stuxnets interne Deinstallationsroutine aufruft. Dadurch hätte man Stuxnet quasi mit seinen eigenen Waffen geschlagen und eine Selbstzerstörung des Botnets ausgelöst.

Aufgrund mangelnder Ressourcen haben wir das jedoch nie realisiert, da wir als neutrale, unabhängige und objektive Sicherheitsforscher keinerlei Unterstützung durch den betroffenen Hersteller SIEMENS AG erhalten.

Kollektives Versagen oder mangelnde Koordination?

Unklar bleibt, warum die großen AV-Hersteller oder SIEMENS nicht etwas derartiges realisiert haben, Ressourcenmangel kann hier ja wohl kaum der Grund sein.

Symantec gar hat hier die Command & Control Server schon seit mindestens Juli in der Hand, da ich aber die Kollegen nicht ungerechtfertigt kritisieren will, werfe ich lediglich die Frage auf, ob die auf einem solchen Server generierten Daten nicht der Allgemeinheit gehören und allen Sicherheitsforschern zu Verfügung stehen sollten, statt einem einzigen Wirtschaftsunternehmen zum alleinigen Vorteil zu dienen. In jedem Fall stellt sich aber die Frage, ob die Bekämpfung einer solchen Seuche nicht generell besser koordiniert werden sollte; an dieser Stelle sind wohl internationale Anstrengungen erforderlich.

Letzlich lassen sich Stuxnet-infizierte Rechner auch aufspüren, in dem man die DNS-Auflösung mitprotokolliert. Infizierte Rechner versuchen früher oder später, die Domains www.mypremierfutbol.com und/oder www.todaysfutbol.com aufzulösen und eine Verbindung zur entsprechenden IP herzustellen.


Mittlerweile sei die Version 3 des bekannten Banking-Trojaners Zbot/ZeuS in der freien Wildbahn erschienen, berichten CA in ihrem Community Blog . Die neue Version betreibt gezielt Treibjagd auf die am häufigsten mit Trojanern infizierten, wohlhabenden Länder wie USA, Spanien, das Vereinigte Königreich und auch Deutschland und erschwere die Analyse durch Sicherheitsspezialisten weiter.

Unter den betroffenen deutschen Banken befänden sich u.a. die Commerzbank, die Deutsche Bank, und das Finanzportal des IT-Sicherheitsdienstlers Fiducia IT AG aus dem Volksbanken-Reiffeisenbanken Verbund. Eine kurze Überprüfung der betroffenen deutschen Sites hat nebenbei ergeben, das die u.a. betroffene Website commerzbanking.de nicht einmal die PCI-DSS Richtlinien für die Bankensicherheit zu erfüllen scheint und auch als schwach bekannte Verschlüsselungsverfahren zulässt.

Das TAN, iTAN und HBCI -Verfahren konnte der Trojaner bereits in den vorigen Versionen überwinden .

Das iTANplus-Verfahren muss ebenfalls als gebrochen angesehen werden. Beim iTANplus-Verfahren werden die Transaktionsdaten vor der Eingabe der TAN nochmals in einem CAPTCHA zusammen mit dem Geburtsdatum des Kontoinhabers dargestellt. Das Verfahren ist (nahezu) so leicht zu brechen wie das iTAN-Verfahren, lediglich die Information des Geburtsdatums muss der Angreifer erfassen und dem Konto zuordnen. Dies kann entweder über automatische Texterkennung , über Datenbanken mit Geburtsdaten, oder einmalig manuell geschehen. In den Entwicklungs- und Schwellenländern hat sich jedoch bereits eine regelrechte Industrie gebildet, um CAPTCHAs zu brechen . Anschließend ist es ebenso wie die anderen Verfahren per Man-in-the-Middle-Angriff zu überwinden.

Das mTAN-Verfahren , bei dem der Kontoinhaber TAN und ggf. Transaktionsdaten per SMS auf sein Handy bekommt, bietet hier aufgrund des Medienbruchs zwar etwas mehr Sicherheit, ist aber auch zu brechen, wenn die Telefonnummer des Handys online mit Hilfe der PIN geändert werden kann (bad idea™). Werden die Transaktionsdaten gar nicht mitgesendet, hat der Kontoinhaber trotz größter Sorgfalt keine Möglichkeit, einen MITM-Angriff durch einen Trojaner zu erkennen.

Fiducias Pressemitteilung zur kürzlich im Rahmen der InitiativeD21 (N)Onliner-Atlas2010 erschienen Sonderstudie "Online-Banking - mit Sicherheit! " liest sich mit Aussagen wie "Online-Banking wird immer beliebter" sehr positiv. Etwas unter den Tisch fällt dabei, dass obwohl die Kunden lt. der Studie Sicherheit und Datenschutz als die wichtigsten Kriterien überhaupt ansehen, sich der Anteil der Menschen, die Online-Banking aus diesen Gründen kategorisch ablehnen, von 4,3% in 2009 auf 20,2% in 2010 nahezu verfünffacht habe (u.a. Heise Online berichtete ).

Dies ist auch völlig berechtigt, meldet der Sicherheitsdienstleister Secunia doch in seinem Halbjahresbericht 2010 , dass allein in der ersten Jahreshälfte 2010 fast so viele Sicherheitslücken in PC-Software gefunden worden wären, die das Eindringen von Trojanern ermöglichen, wie im ganzen Jahr 2009. Die ohnehin schon höchste Bedrohungslage aller Zeiten wird durch den vermehrten Einsatz von Smartphones, die ebenfalls durch Trojaner und Viren infiziert werden können, zusätzlich angeheizt.

Interessant für die Online-Banking Studie wäre gewesen zu ermitteln, welcher Anteil unter den tatsächlichen Nutzern Bedenken beim Online-Banking hat, und welche.

Nebenbei fiel mir noch zufällig auf, dass die Studie ohne Quellenangabe teilweise wortwörtlich von Wikipedia abzuschreiben scheint (vgl. S. 15 der Studie unten mit "SmartTAN " und "SmartTANplus "), jedenfalls wenn man dem Changelog von Wikipedia glauben darf.

Da die Kunden, wie der Studie ebenfalls zu entnehmen ist, kaum selbst bereit seien, etwas für die Sicherheit zu tun, oder gar dafür zu bezahlen, und Datenschutz und Sicherheit als Selbstverständlichkeit sähen, liegt hier m.E. dringend Handlungsbedarf auf Seiten der Banken, die unsicheren Verfahren auszutauschen.

Ebenfalls Handlungsbedarf sehe ich im Bereich der Politik und der Rechtssprechung, hier für mehr Verbraucherschutz zu sorgen, und zumindest bei Einsatz bekanntermaßen unsicherer Verfahren die Haftung in Richtung der Banken zu verlagern.

Bankkunden, Banken, Bankenaufsicht, Politiker oder Organe der Rechtspflege können sich gerne jederzeit für prophylaktische Beratung, Schulung oder forensische Beweisführung vertrauensvoll an uns wenden .

UPDATE 29.07.2010: Gemäß der von Verizon Business veröffentlichten Studie "Data Breach Report 2010 " sei die Finanzbranche das Angriffsziel Nummer 1 von Online-Kriminellen, berichtet Heise Online.

UPDATE 29.07.2010:McAfee berichteten in Ihrem Blog, dass Zbot/ZeuS mittlerweile den im Zusammenhang mit den Angriffen auf die SIEMENS Simatic WinCC und PCS 7 SCADA -Systeme bekannt gewordenen, hochkritischen 'LNK Bug' (CVE-2010-2568 ) aktiv ausnutzt.

UPDATE 03.09.2010: Die Deutscher Bank Research, GfK und Google hätten eine Studie veröffentlicht, dass der Anteil der Online-Finanzgeschäfte immer höher würde , was den Handlungsdruck m.E. verstärkt oder wenigstens verstärken sollte.

UPDATE 27.09.2010: Die neuste Version von ZeuS nehme nun auch SMS-TAN (auch mobile TAN, mTAN genannt) ins Visier , berichtet heise online unter Bezug auf eine Veröffentlichung von S21sec . Die Malware versuche dabei, dem Opfer ein angebliches Sicherheitsupdate für das Handy unterzujubeln, welches ebenfalls einen Man-in-the-middle Angriff ausführe. Die ZeuS-Handy-Malware sei bisher auf die Infektion von Symbian und BlackBerry SmartPhones ausgerichtet.

UPDATE 09.10.2010:16-jähriger demonstriert Sicherheitslücken bei 17 Banken , er nutzte hierbei XSS -Lücken, die sich auch für Man-in-the-middle Angriffe nutzen lassen. Das bestätigt meinen Eindruck weiter, dass hier nie oder nicht regelmäßig nach Änderungen professionelle Audits stattfinden und selbst triviale Methoden ausreichend sind, die meisten Websites zu überlisten.



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