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).


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.



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