Forensic Investigations / Fi Blog

Fi Blog

Die CoDeSys Runtime der Kemptener Softwareschmiede 3S Smart Software Solutions GmbH ist ein Programmiersystem für speicherprogrammierbare Steuerungen (SPS) nach IEC 61131-3 .

Das System wird von Leittechniksystemherstellern (OEMs ) als Software-Basis verwendet. Zu dem Kunden von 3S Smart Software Solutions gehören laut Referenzliste mehr als 250 mehr als 350 Hersteller, u.a. Größen wie ABB, Alstom, Beckhoff, Bosch Rexrodt, Eaton, MAN, Mitsubishi, Schneider Electric und WAGO.

Durch ein Sicherheitsleck ist es u.a. möglich, ohne Authentifizierung

  • Dateien von und zur SPS zu übertragen
  • beliebige Kommandos auszuführen (Root-Shell)
  • Anwendersoftware von der SPS zu stehlen und die SPS neu zu programmieren.

Die Implementierung der CoDeSys Runtime durch den jeweiligen OEM-Hersteller kann gegebenenfalls gar nicht oder nur teilweise für diese Fehler anfällig sein. Welche Hersteller bzw. Produkte genau betroffen sind, ist nicht abschließend bekannt – die Liste der Geräte, die das System benutzen ist lang. Bisher ist jedoch lediglich ein einzelner Hersteller entdeckt worden, dessen Produkte nicht anfällig für die Sicherheitslücken sind.

Wir haben unsere Bestandskunden am ersten Tag des Bekanntwerdens (25.10.2012) hierüber informiert.

Das ICS-CERT hat inzwischen auch eine Warnung veröffentlicht: ICS-ALERT-12-097-02A .

Stellungnahme des Herstellers

Auch CoDeSys reagierte mittlerweile, wenn auch mit einem relativ enttäuschenden Statement :

  • [...] Eine passwortgeschützte und öffentlich zugreifbare CODESYS Steuerung ist trotz Passwortschutz noch ansprechbar. So können [...] weiterhin etwa Kommandos mit der Shell der Steuerung ausgeführt oder Applikationen geladen werden.
    [...]
    Generell stellen wir in CODESYS keine Bordmittel zur Verfügung, die eine Steuerung vor einem ernsthaften Angriff aus dem Internet schützen sollen. Sollten wir dieses mit der vorhandenen Passwort-Funktion suggeriert haben, war das nicht beabsichtigt. [...]

Einschätzungsverfehlung

Noch im ersten Absatz wird noch von einem "Passwortschutz" gesprochen, später nur noch von "Passwort-Funktion". Eine solche Wortklauberei ist nicht zielführend. Welchen Zweck außer dem "Passwortschutz" eine "Passwort-Funktion" ansonsten haben sollte, bleibt die Erklärung ebenso schuldig.

Ist es realistisch, dass der Anwender annimmt, dass eine "Passwort-Funktion" etwa dazu dient

  • seine Fähigkeiten beim Maschineschreiben aufzufrischen oder
  • ihm helfen soll, den Arbeitstag herum zu bekommen?

Natürlich ist das absurd – die Benennung der Funktion und das allgemein Übliche definiert eine ganz klare Anwendererwartung.

Der Anwender konnte gar nicht erkennen, dass die "Passwort-Funktion" kein "Passwortschutz" ist. Gibt man von der CoDeSys-IDE aus das falsche Passwort an, wird der Zugang nämlich – genau wie erwartet – nicht gewährt. Lediglich durch andere Mechanismen wie selbstgeschriebene Programme ist es möglich, ohne Passwort zuzugreifen.

Kommunikationsverfehlung

Leider informiert dieses Statement auch nicht darüber, dass neben v2.3 auch noch andere – wahrscheinlich alle – Versionen betroffen sind, wie mittlerweile aus Fachkreisen zu hören ist. Ebensowenig wird klar kommuniziert, dass dieser Mangel ein kritisches Risiko darstellt, selbst wenn die SPS nicht vom Internet – also "öffentlich" – zugänglich ist und – wie empfohlen – durch Firewall(s) und VPN(s) geschützt ist. Des weiteren benötigt es dafür keinen "ernsthaften Angriff" um die Sicherheitslücke auszunutzen – ein Herumprobieren von 'Skript-Kiddies ' mit frei verfügbaren Werkzeugen genügt. Auch ein verärgerter Mitarbeiter ('malicious Insider') wird die Lücke ebenfalls ohne große technische Kenntnisse nutzen können.

Fazit

In puncto Kommunikation wurde ein Großteil von dem falsch gemacht, was falsch zu machen ist. Das Statement hat m.E. folgende Grundregeln verletzt:

  • die Problematik weder zu verharmlosen noch zu dramatisieren,
  • nicht zu versuchen, unhaltbare Entschuldigungen oder Ausreden zu suchen,
  • objektiv richtig, klar und eindeutig zu sein,
  • konstruktive Hilfestellung statt bekannten Phrasen und Allgemeinplätzen zu bieten
  • einen Ausblick auf eine Problemlösung für den Endanwender zu bieten

Gerne beraten wir Hersteller und Anwender auch in Kommunikationsfragen bei Sicherheitsvorfällen.

Immerhin hat man wohl für OEM-Kunden eine fehlerbereinigte Version bereitgestellt. Ob und wann die OEMs diese Fehlerbereinigung in Ihre Produkte integrieren, bleibt jedoch dem einzelnen Hersteller überlassen. Schön wäre es, wenn CoDeSys seine OEMs aktiv anhalten würde, die Fehlerbereinigung auf Ihre Geräte anzuwenden, aktualisierte Firmware bereitzustellen oder zumindest einen Zeitplan zu nennen – geht dies doch auf ursächlich auf das Unternehmen zurück.

Der Sachschaden für einen offensichtlich vermeidbaren Fehler ist enorm –

  • i Hersteller x j Produkte x k Anwender x m Installationen x n € pro Feld-Upgrade

extrem konservative Abschätzung:

  • 100 Hersteller x 1 Produkt x 100 Anwender x 10 Installationen x 50 € pro Feld-Upgrade = 5 Mio. € +++ verbrannt

– dies zeigt die besondere Verantwortung von Platformanbietern. Kosten für die OEMs sind dabei noch nichtmal mitberechnet.

Leider erfährt der Endanwender bisher noch nicht einmal, ob sein Gerät betroffen ist oder nicht.

Kostenloser Test

Wenn Sie uns ein Exemplar Ihrer Steuerung postalisch zukommen lassen, testen wir diese kostenlos auf den Fehler! (Nur nach vorheriger Absprache , Rückversand erfolgt unfrei. Wir behalten uns vor, den kostenlosen Test auch ohne Angabe von Gründen abzulehnen.)

Automatisierte Tools können dies bei der Vielfalt der unterschiedlichen Implementierungen durch die einzelnen Hersteller gegenwärtig (noch) nicht leisten.

Gerne testen wir Ihre Systeme auch vor Ort (normal kostenpflichtig) professionell und neutral auf die Existenz dieser und anderer Schwachstellen.

UPDATE 23.11.2012: 3S / CoDeSys hat die Homepage überarbeitet. Die Listen der Hersteller und Geräte, die das System einsetzen, lässt sich nicht wieder auffinden, weder über die Homepage noch über Google. Links aktualisiert bzw. entfernt.

UPDATE 19.12.2012: Der 3S / CoDeSys Support hat mir geschrieben, die Homepage sei zur SPS/IPC/Drives 2012 auf das neue CI Design umgestellt worden. Es sei unrichtig, dass die Geräteliste jemals nicht mehr auf der Homepage verfügbar war. Möglich, dass ich sie nur übersehen hatte und Google die neue Seite noch nicht indexiert hatte. Auf jeden Fall ist sie auch auf der neuen Seite online . Hier ist gar von über 350 Herstellern die Rede.

Auf meine Nachfrage, welche Geräte nun konkret von dem Problem betroffen seien und wie der aktuelle Status zur Verfügbarkeit von Updates der einzelnen Hersteller sei, erklärte man, dass man dazu nichts sagen könne, da die OEMs keine Rückmeldung gäben und man nicht wisse, welche Varianten und Versionsstände in Ihren Produkte integriert wurden.


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:


Lange schon war die Nachahmung des Stuxnet-Wurms in der Diskussion . Nun ist den Analysten von Symantec eine Duqu [dyü-kyü] getaufte Software aus dem europäischen Raum zugespielt worden. Die Malware sei Duqu getauft worden, da sie Dateien mit dem Präfix "~DQ" anlege. Symantec hat dazu ein technisches Papier , F-Secure und McAfee berichteten, das ICS-CERT hat ALERT-11-291-01 ALERT-11-291-01A ALERT-11-291-01B ALERT-11-291-01D ALERT-11-291-01E herausgegeben.

Anatomie des Rootkit-Teils von Duqu. Bild (c) Symantec

F-Secure schreibt , der Kernel Rootkit Treiber von Duqu (JMINET7.SYS) sei Stuxnet so ähnlich, dass deren Analyse-Systeme es für Stuxnet (MRXCLS.SYS) hielten.

Während Stuxnet mutmaßlich gestohlene Zertifikate der taiwanesischen Firmen RealTek und JMicron verwendete, sei die Duqu Malware mit einem Zertifikat der ebenfalls taiwanesischen Firma C-Media Electronics Incorporation signiert. Wie die beiden anderen Zertifikate sei es von VeriSign ausgestellt und am 14.10.2011 zurückgezogen worden. Dies dürfte aber nur wenig Wirkung zeigen, da ältere Systeme wie Windows XP dies nicht ausreichend überprüfen.

Symantec berichtet , Duqu sei nicht darauf ausgelegt, Automatisierungssysteme direkt zu sabotieren, sondern vielmehr sehr spezifische Dokumente wie Anlagen- und Gerätedesigns zur Vorbereitung zukünftiger Attacken zu stehlen. Der informationsstehlende Trojaner verfüge über eine Command & Control Infrastruktur, mit der er per HTTP oder HTTPS kommuniziere. Der C&C Server, über den die Steuerung des so gebildeten Botnets erfolgt, stünde in Indien und sei noch aktiv.

Das zurückgezogene Zertifikat der Rootkit-Komponente von Duqu (cmi4432.sys)

Der Verbreitungsweg sei noch unbekannt, die Malware würde sich im Gegensatz zu Stuxnet nicht selbst replizieren, sei also kein Wurm. Die Zahl der Organisationen, auf die die Malware abziele, sei sehr klein (<=2), darunter befänden sich Hersteller von Industrieautomatisierungssystemen. Als wahrscheinlichsten Verbreitungsweg kann man deshalb Social Engineering mittels Email- Scams mutmaßen. Die Schadsoftware würde sich zudem nach 36 Tagen selbst zerstören.

Zu den Fähigkeiten der Schadsoftware gehörten das Sammeln von Systeminformationen, Auswerten der Netzwerktopologie und das Aufzeichnen von Tastatureingaben ("Keylogging"). Es seien bereits mehrere Varianten aufgetaucht.

McAfee's Blogeintrag kann derzeit keine neuen Erkenntnisse beisteuern.

In den Medien wird hier vom "Vorgänger vom Nachfolger", "Sohn" oder "Bruder" von Stuxnet gesprochen. Bruder trifft es wohl am ehesten, da beide "genetisch" ähnlich sind. Ob es tatsächlich der "Vorgänger vom Nachfolger" ist, erscheint aus meiner Sicht spekulativ und unlogisch. Warum man erst von bestimmten Herstellern Informationen stehlen sollte erscheint schleierhaft, da ein weiterer Angriff nach diesem Schema auch so leicht möglich wäre.

UPDATE 21.10.2011: Das ICS-CERT hat einen aktualisierten Alert Alert , der die unzensierte IP-Adresse des Command&Control Servers benennt. Der Server wurde mittlerweile abgeschaltet.

Das Symantec-Papier zeigt keine wirklichen Besonderheiten des Trojaners. Interessant ist aber, dass Duqu die schon von Stuxnet bekannte Liste der zu umgehenden Virenscanner um die zwei chinesischen Hersteller Rising International und 360 erweitert hat. Auch interessant: Symantec hat laut Paper keine Ahnung, wie der Trojaner genau mit dem C&C Server kommuniziert(e), und wo im Code sich ein Selbstzerstörungsmechanismus befinden soll, weiß aber gleichzeitig, dass es genau nach 36 Tagen ist, und der Trojaner es selbst tut, und nicht ferngesteuert. Na dann.

Die Hashsummen der bisher bekannten vier Varianten des Duqu-Rootkits.

UPDATE 22.10.2011: Jetzt ist es offiziell: Duqu zielt NICHT auf Betreiber oder Hersteller von Automatisierungssystemen ab, vermeldet das ICS-CERT in Koordination mit Symantec und CrySyS , den Entdeckern von Duqu. Ich wollte es nicht so direkt schreiben, wie aber schon vermutet handelt es sich wohl um eine PR-Ente von Symantec. Ob die Geschichte mit dem Diebstahl sensitiver Dokumente von Automatisierungsherstellern gänzlich frei erfunden oder eine bloße Vermutung war, die als Faktum verkauft wurde, werden wir wohl nie erfahren. Der ICS-Security-Community wurde damit ein echter Bärendienst erwiesen.

Nebenbei hat das ICS-CERT im aktualisierten Duqu-Papier versäumt zu melden, dass neben den zwei bekannten Varianten noch zwei weitere gefunden wurden, weswegen ich das mit dem "ganz gezielten Angriff" auch nicht glauben konnte.
Die Rootkit-Treiber der vier bisher bekannten Varianten heißen "cmi4432.sys ", "jminet7.sys ", "adpu321.sys " und "nfrd965.sys ". Lediglich "cmi4432.sys" trägt eine vormals gültige digitale Signatur. Das zum Signieren benutzte Zertifikat wurde aber mittlerweile zurückgezogen.

UPDATE 27.10.2011: Aktualisierter Alert des ICS-CERT. Ergänzt werden Informationen aus einem Blog-Artikel von Kaspersky Labs. Berichtet wird dort von einem Infektionsfall im Sudan und drei Fällen im Iran. Dabei seien weitere, jeweils unterschiedliche, Dateinamen des Rootkit-Treibers festgestellt worden, namentlich "adp55xx.sys", "iraid18.sys", "igdkmd16b.sys", "bpmgs.sys" und "noname.sys". Ein Zusammenhang mit industriellen Automatisierungssystemen oder zwischen den Opfern bestünde nicht.

UPDATE 02.11.2011: Aktualisiertes Symantec-Papier zu Duqu. Symantec spricht von mittlerweile 14 Varianten.

Das "Verfallsdatum" des Trojaners lässt sich laut einem Blogeintrag von ESET in dessen Konfigurationsdatei angeben, analog zu Stuxnet. Dieses Verfallsdatum kann offenbar entsprechend verlängert werden.

Der Dropper (Duqu-"Installationsprogramm") wurde mittlerweile ebenfalls entdeckt. Er soll in einem Word-Dokument enthalten sein und nutzt eine bisher unbekannte Sicherheitslücke ("0day") in Microsoft-Betriebssystemen aus. Microsoft hat die Lücke bestätigt und arbeitet an der Behebung .

Command and Control Weiterleitung an das interne Netz mittels RPC-over-SMB. Bild (c) Symantec

Ein weiterer Server zur Fernsteurung ("Command & Control") in Belgien wurde entdeckt und vom Netz genommen.

Symantec und ESET berichten übereinstimmend, Duqu besitze einen zu Stuxnet analogen Kommunikationsmechanismus . Dieser könne Kommandos von einem infizierten Rechner mit Internetverbindung an einen internen Rechner ohne Internetverbindung weiterreichen. Dabei verwende Duqu RPC über SMB ("Named Pipes "), was von keiner Firewall blockiert werden wird.

Insgesamt also viele Parallelen, neben den völlig verschiedenen Payloads und Angriffszielen. Symantec spricht von mittlerweile 3 verschiedenen Payloads, die alle Informationen zu eingesetzten Systemen und/oder der Netztopologie entwenden.

UPDATE 04.11.2011: (!!!WICHTIG!!!) Microsoft hat ein Advisory und ein Fix-It herausgegeben, das die Ausnutzung der Sicherheitslücke (CVE-2011-3402 ) durch den Duqu-Installer verhindern soll. Die Sicherheitslücke betrifft alle Windows-Versionen und ermöglicht Privilegieneskalation. Der Fehler steckt im Windows-Kernel, genauer gesagt dem Parsen von TrueType Fonts. Voraussichtlich wird Microsoft diese Lücke mit dem November-Patchday am nächsten Dienstag (08.11.2011) noch nicht endgültig schließen. Es empfiehlt sich deshalb die Benutzung des Fix-Its, um kein zu großes Zeitfenster für eine Infektion entstehen zu lassen.

UPDATE 05.11.2011: Die im Advisory 2639658 beschriebenen manuellen Workarounds funktionieren unter Windows XP und Server 2003 nur für englischsprachige Windows-Versionen. In nicht-englischen Windows-Versionen ist der Benutzergruppenname "everyone" durch das jeweilige lokalisierte Äquivalent zu ersetzen (z.B. Deutsch: "Jeder"). Das Fix-It funktioniert auch auf nicht-englischen Sprachversionen. Sowohl die manuelle als auch die automatische Methode verhindern den Zugriff auf die Datei "t2embed.dll". Unter Windows XP und Server 2003 führt das zu der unerwünschten Nebenwirkung, dass die Updates KB972270 (MS10-001) und KB982132 (MS10-076) ständig erneut angeboten werden, auch wenn diese schon installiert sind oder nochmals installiert werden. Es empfiehlt sich deshalb, diese Updates entweder zu ignorieren oder auszublenden.

UPDATE 09.11.2011: Neues gemeinsames Papier des US-CERT und des ICS-CERT ("Joint Security Awareness Report"). Keine neuen Erkenntnisse, lediglich Zusammenfassung.

UPDATE 13.12.2011: Microsoft schließt die Duqu-Lücken im Windows-Kernel-Treiber win32k.sys (MS11-087 /CVE-2011-3402 ) wie erwartet im Zuge des Dezember-Patchdays . Das oben beschriebene Fix-It wird damit obsolet. Diese (Symantec PR- und FUD-)Story ist damit beendet.


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.


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.


'Stuxnet 2.0' Demo - Bild (c) Dale G. Peterson

Symantec zeigte auf dem Ausstellungsflur der BlackHat eine 'Stuxnet 2.0' Demo. Hierbei hätten Sie das 'Payload', also die 'Nutzlast' des Stuxnet-Codes ausgetauscht. Ebenso wie beim originalen Stuxnet sei die Manipulation des SPS-Codes durch einen Operator nicht zu erkennen, da diese beim Auslesen versteckt würde.

Die 'Nutzlast' könnte Steuerungen auf vielfältige Weise manipulieren. Die trivialste mögliche Manipulation hatte Ralph Langner schon vor einiger Zeit demonstriert . Mit 14 Bytes implementierte er eine simple Zeitbombe, die auf ein bestimmtes Datum wartet, und ab dann einfach das restliche Steuerungsprogramm überspringt. Kleine Ursache, große Wirkung: dies wäre noch schlimmer als ein unkontrollierter Stromausfall an der Steuerung, alle Regelungen kommen zum erliegen, aber der letzte Signalzustand liegt noch an. In diesem Fall kann man nur noch darauf hoffen, dass die physikalischen Sicherungssysteme auch für diesen Fall wie gewünscht greifen. Die Diagnose eines 'unsichtbaren' Fehlers dürfte ebenfalls schwierig werden.


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.


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!



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