Der Hype um die kritische Siemens S7-1200/S7-1500 Sicherheitslücke CVE-2022-38465

Hintergrund

Als ich bei ENLYZE zum Jahreswechsel 2018/2019 anfing, wurden wir beauftragt, Prozessdaten aus einer relativ neuen Schweißmaschine auszulesen. Die Maschine basierte auf einer modernen Siemens SPS aus der fehlersicheren S7-1500F Serie. Als Neuling in Sachen Automatisierung suchte ich nach existierenden Implementierungen des S7-Protokolls, fand ein paar und probierte sie aus. Keine davon funktionierte.

Das einzige Programm, was sich mit der SPS verbinden konnte, war die offizielle TIA Portal Software von Siemens. Dies funktionierte erstaunlich gut: Ich musste bloß ein Ethernet-Kabel in einen der ungenutzten Anschlüsse der S7-1500F stecken, die auf der SPS angezeigte IP-Adresse eintippen und ich hatte Vollzugriff. Kein Passwort oder irgendeine andere Art von Autorisierung war erforderlich.

Ich hätte nun einige Dinge mit diesem Zugriff anstellen können, aber ich wollte lediglich Prozessvariablen auslesen und dies funktionierte sehr gut. Die Konsequenz war also klar: Um Daten aus der Schweißmaschine auszulesen, mussten wir alle traditionellen S7-Protokollimplementierungen vergessen und es genau so wie TIA Portal angehen. Und ohne eine frei verfügbare Implementierung von TIA Portal musste ich das Programm selbst reverse-engineeren und das Protokoll auf eigene Faust analysieren.

Die Zerlegung des TIA Portals

Was tut man, wenn man ein Protokoll reverse-engineeren möchte, welches über Ethernet übertragen wird? Man startet Wireshark und überwacht die Kommunikation, in diesem Fall zwischen TIA Portal und der S7.

Es stellte sich schnell heraus, dass Siemens die Komplexität des Protokolls erheblich erhöht hatte, verglichen mit einer alten S7. Dies war keine große Überraschung: Es war klar, dass Siemens etwas unternehmen musste, nachdem 2010 der Stuxnet Computerwurm iranische Nuklearzentrifugen zerstörte und deren Atomprogramm zurückwarf – unter anderem aufgrund der nicht existenten Authentifizierung in den genutzten Siemens S7-400 Steuerungen.

Siemens konnte zwar das Kommunikationsprotokoll neu entwickeln, aber nicht von heute auf morgen die Mentalität in einer Werkshalle ändern. Damals hatten Industriekunden einfach keine Prozesse, um individuelle SPS-Passwörter pro Maschine zu verwalten – und daran hat sich auch bis heute kaum etwas geändert. Die meiste Zeit kam es ausschließlich auf physische Sicherheit an.

Als Konsequenz daraus konnte Siemens zwar immer mehr Komplexität in das Protokoll einbauen, aber keinen Kunden zur Nutzung von Passwörtern zwingen. Ich fand im Protokoll unter anderem einen 6-Wege Handshake mit proprietärer Challenge-Response-Authentifizierung, ein eigens entwickeltes Signaturverfahren zur Validierung der Nachrichten und eine Menge Verschleierung oben drauf. Praktisch ein Paradebeispiel für das “Ausrollen eigener Kryptografie” und “Sicherheit durch Unklarheit” – beides Prinzipien, von denen dringend abzuraten ist. Zugegeben, all dies hilft, um den durchschnittlichen Angreifer von Unfug mit Ihrer SPS abzuhalten. Wenn sich jedoch das TIA Portal weiterhin ohne ein Passwort mit jeder SPS verbinden lässt, ist das gesamte Sicherheitssystem letztendlich hinfällig. Denn es muss an irgendeiner Stelle einen Generalschlüssel geben. Und nach 6 Wochen akribischer Reverse-Engineering-Arbeit fand ich schließlich alle nötigen Details und hatte einen funktionierenden SPS-Client.

Warum erzähle ich Ihnen das alles?

Nun ja, wenn eine einzelne Person wie ich im Jahr 2019 lediglich 6 Wochen brauchte, um das Sicherheitssystem der neuesten Siemens SPS-Reihe zu knacken, dann malen Sie sich einmal aus, zu was ein Team aus Reverse-Engineers die ganzen Jahre über in der Lage war. Die Tür stand praktisch die ganze Zeit weit offen.

Eine Siemens S7 hätte daher nie Teil eines Firmennetzwerks sein dürfen. Eine Trennung der Firmen- und Werkshallen-Netzwerke ist hier Pflicht, entweder physisch oder mittels einer vernünftig abgesicherten Firewall, eines Managed Switch oder eines Routers. Kümmern Sie sich darum, bevor Sie irgendetwas anderes ausprobieren!

Auseinandernehmen des modernen S7-Protokolls -- ein Foto aus den frühen Tagen der ENLYZE-Werkstatt

Die Realität des Passwortschutzes

Wie ich bereits in meiner Einleitung berichtete, ist dies nicht die erste Sicherheitslücke in der Siemens S7-1200 und S7-1500 SPS-Serie. Frühere Security Advisories, wie z.B. SSA-232418, haben oft das Anschalten des Passwortschutzes für alle S7-Kommunikationskanäle empfohlen. Dies hätte tatsächlich ein effektiver Weg sein können, um Bösewichte fernzuhalten, vorausgesetzt die Passwörter wären individuell, lang, zufällig und sicher verwaltet.

Tatsächlich sind aber 90% der Siemens-Steuerungen, die wir in unserem Tagesgeschäft antreffen, nicht über ein SPS-Passwort geschützt. Mir ist nicht bekannt, dass die Empfehlungen aus den Siemens Security Advisories hier einen spürbaren Unterschied gemacht haben. Überdies gibt es keinerlei Anreize zur Aktivierung des Passwortschutzes, nachdem eine Maschine bereits läuft:

• Maschinenhersteller werden erst auf Nachfrage ihrer Kunden aktiv, und wenn ein Kunde dann auch bereit ist zu zahlen. Sie wurden nicht dazu verpflichtet, regelmäßige Sicherheitsupdates auszuliefern. Daher ist es nur verständlich, dass diese nichts an einem laufenden System verändern – anstatt proaktiv ein Problem zu lösen, von dem die Kunden noch nicht mal etwas wussten.

• Kunden sind in einer noch nachteiligeren Position. Zuerst müssen sie einmal wissen, an welchen Stellen überhaupt moderne S7-Steuerungen genutzt werden, mit welchen Firmware-Versionen und Sicherheitsstufen diese installiert wurden und ob irgendwelche Sicherheitsupdates benötigt werden. Danach muss die Produktion gestoppt werden (mit Verlust), das TIA Portal Projekt modifiziert werden und die Änderungen auf alle betroffenen Geräte übertragen werden (SPSen, aber auch HMIs, Peripherie, usw.). Häufig scheitert dies aber schon daran, dass den Kunden die benötigte TIA Portal Projektdatei fehlt – oder sie haben diese, aber mit jeder Modifikation erlischt die Garantie.
  Infolgedessen sind Kunden wieder auf den Maschinenhersteller angewiesen, um den Passwortschutz zu aktivieren – was mit signifikanten Kosten zusätzlich zu den Kosten eines Produktionsstillstands verbunden ist.

Wenn man dann noch bedenkt, dass Versicherer zunehmend Cyberangriffe in ihren Versicherungspolicen mit einschließen, kann man nachvollziehen, warum es oft wirtschaftlich sinnvoll ist, einfach gar nichts zu tun.

Übrigens, die restlichen 10% der Steuerungen, bei denen der Passwortschutz aktiviert war, nutzen ein einfaches kurzes Passwort für alle Maschinen des gleichen Herstellers. Erwarten Sie nicht, dass diese kleine Hürde tatsächlich die Cybersicherheit Ihrer Maschine verbessert.

Die neueste Sicherheitslücke und ihre Lösung

Falls Sie jetzt darüber nachdenken, Passwörter für Ihre S7-Geräte einzuführen und damit die Sache als erledigt betrachten, habe ich leider schlechte Nachrichten für Sie. Das Neue an der aktuellen Sicherheitslücke (bekannt als CVE-2022-38465 / SSA-568427 / SSB-898115) ist das Totalversagen aller existierenden Schutzsysteme. Die Team82 Forschungsgruppe von Claroty hat nicht bloß den privaten Schlüssel einer S7-1500 extrahiert, sondern auch herausgefunden, dass damit das Passwort jeder geschützten Siemens-Steuerung ausgelesen werden kann – was den erheblichen Schweregrad von 9,3 rechtfertigt. Die Tür ist offener als je zuvor.

Daher ist es nicht mehr ausreichend, einfach nur ein Passwort für die S7 zu vergeben. Ein solcher Totalausfall der existierenden Sicherheitssysteme kann ausschließlich durch ein komplett neues Sicherheitssystem behoben werden. Und dies hat Siemens mit dem TIA Portal V17 und den zugehörigen SPS-Firmwares eingeführt.

Die neuen Firmwares schützen ihre Kommunikation mittels TLS 1.3 und individuellen Zertifikaten für jeden Teilnehmer. Im Gegensatz zu Siemens früherem Sicherheitssystem wurde TLS 1.3 in einem offenen Verfahren standardisiert. Die TLS-Familie hat sich bereits über die vergangenen Jahrzehnte zur Absicherung der Kommunikation im Web bewährt.

Es bleibt noch zu prüfen, welche TLS-Implementierung Siemens für seine SPS-Modelle ausgewählt hat, welche Verschlüsselungsmodi unterstützt werden und wie TLS konkret genutzt wird. Aber die Wahl eines offenen Standards gegenüber einem selbst entwickelten Kryptosystem ist schon mal ein großer Schritt in die richtige Richtung.

Hört sich gut an, oder? Wie bekommen wir jetzt das Update auf die Millionen betroffener Geräte da draußen?

Die traurige Wahrheit ist: Dies wird einfach nicht passieren.

Im Gegensatz zu monatlichen Updates für Computer-Betriebssysteme gibt es keine vergleichbar etablierten Prozesse für das Ausrollen von Sicherheitsupdates auf SPS-Geräten. Wie bereits das Setzen eines SPS-Passworts ist auch das Einspielen des Updates ein mühsamer manueller Prozess, der einen Stillstand der Produktion und eine gemeinsame Anstrengung vom Maschinenhersteller und Kunden verlangt. Um konkret eine einzelne Maschine auf TLS-gesicherte Kommunikation umzustellen müssen Sie:

• Ihre Engineering-Workstations auf TIA Portal V17 aktualisieren (welches nebenbei eine neue Lizenz benötigt),

• die Firmwares aller SPSen, Softwarestände aller HMIs sowie weitere mit der S7 kommunizierende Geräte aktualisieren,

• alle Geräte in der TIA Projektdatei updaten,

• die Legacy-Kommunikation abschalten,

• TLS-Zertifikate für jedes Gerät einrichten, und schließlich

• das modifizierte Projekt auf alle betroffenen Geräte laden.

Die Anreize zum Handeln waren bereits niedrig, als es bloß um das Setzen eines Passworts ging. Sie sind leider kein bisschen höher für diese kritische Sicherheitslücke, welche eine deutlich komplexere Lösung erfordert. Aus diesen Gründen erwarte ich für die nahe Zukunft keine große Verbreitung dieses Updates.

Was allerdings tatsächlich hilft, ist wieder einmal die Trennung der Firmen- und Werkshallen-Netzwerke. Wie bereits gesagt sind diese entweder physisch oder mittels einer vernünftig abgesicherten Firewall, eines Managed Switch oder eines Routers voneinander abzuschotten. Diese Lösung ist möglich, ohne die laufende Produktion zu unterbrechen. Sie kann gänzlich ohne Unterstützung seitens Siemens oder des Maschinenherstellers umgesetzt werden, und schützt auch vor zukünftigen noch unbekannten Attacken auf Ihre S7-SPS.

Selbstverständlich sind auch Firewalls, Managed Switches und Router nicht immun gegen Sicherheitsprobleme. Im Vergleich zu SPSen sind diese Geräte jedoch weiter verbreitet, werden ständig auf Sicherheitslücken getestet und haben funktionierende Prozesse zum Einspielen von Sicherheitsupdates.

Ausblick

Wir werden diese Probleme immer und immer wieder haben, wenn das Installieren von SPS-Sicherheitsupdates weiterhin so kompliziert und die Anreize zum Updaten weiterhin so gering bleiben. Der Umstieg auf standardisierte TLS 1.3 Kommunikation bedeutet zwar eine dauerhafte Verbesserung der SPS-Sicherheit, jedoch wird dies beileibe nicht das letzte Sicherheitsupdate sein, welches Sie je benötigen. Die nächste Sicherheitslücke ist bloß eine Frage der Zeit.

Diese vertrackte Situation kann nicht von einer einzelnen Firma gelöst werden. Es benötigt eine gemeinsame Kraftanstrengung seitens Siemens, den Maschinenherstellern und deren Kunden. Im Folgenden daher eine Wunschliste und ein offener Aufruf an alle Beteiligten in der Industrie:

• Kunden müssen regelmäßige Sicherheitsupdates von ihren Maschinenherstellern verlangen. Dies muss Teil des Lastenhefts bei der Bestellung einer neuen Maschine werden.
  Ich bin realistisch genug, um zu verstehen, dass solche Updates nicht jederzeit auf Produktionsanlagen installiert werden können. Aber das Installieren von Softwareupdates sollte zumindest Teil der Wartung bei geplanten Maschinenstillständen werden.

• Maschinenhersteller müssen realisieren, dass sie nicht länger bloß Maschinen sondern vernetzte Computer ausliefern. Solche Geräte benötigen regelmäßige Sicherheitsupdates. Jeder Maschinenhersteller muss einen schlanken Prozess anbieten, um diese Updates einzuspielen.

• Schlussendlich ist Siemens der einzige Beteiligte, der regelmäßige Sicherheitsupdates möglich machen kann. Siemens muss praktikable Prozesse für den Endkunden einer Maschine entwickeln, damit dieser schnell Sicherheitsupdates auf alle betroffenen Komponenten aufspielen kann. Wir haben bereits gesehen, dass Updates einfach nicht eingespielt werden, wenn der Prozess zu kompliziert und damit kostspielig ist.
  Weiterhin sollten Fehlerbehebungen für kritische Sicherheitslücken auch in alte TIA Portal Versionen zurückportiert werden. Aktuell erreichen diese ausschließlich Maschinenhersteller, welche durchgehend für neue TIA Portal Funktionsupdates zahlen und dann all ihre Engineering-Workstations aktualisieren. Jeder andere, der noch TIA Portal älter als V17 einsetzt, liefert jetzt Steuerungen mit einer bekannten Hintertür aus.

Erst vor ein paar Wochen hat die EU 5 Jahre kostenlose Softwareupdates verpflichtend für Smartphones eingeführt. Diese Updates erreichen verlässlich Milliarden von Geräte kurz nach ihrer Veröffentlichung. Es gibt keinen Grund, warum unsere SPS-basierte Produktionslandschaft und die gesamte kritische Infrastruktur hier schlechter gestellt sein sollten.

Aktuell kann niemand mit gutem Gewissen eine SPS in ein öffentliches Netz hängen und auf ihre eigenen Sicherheitsfunktionen vertrauen.

Danksagungen

Vier Jahre, in denen wir erfolgreich unseren eigenen ENLYZE S7-Kommunikationsclient nutzen, und tausende aufgezeichnete Prozessvariablen später sind ein guter Zeitpunkt für einige Danksagungen. Diesmal möchte ich als Erstes dem Team82 von Claroty danken, für ihre kontinuierliche Forschung zu SPS-Sicherheit, ihrer neuesten Veröffentlichung und für die erfolgreiche Überzeugungsarbeit bei Siemens zur Nutzung von TLS 1.3 in der S7-Kommunikation.

Wir bauen alle auf die großartige Arbeit von unzähligen Menschen auf. Der ENLYZE S7-Kommunikationsclient war nicht die erste Implementierung des modernen S7-Protokolls und er wird sicherlich auch nicht die letzte sein. Ich möchte daher insbesondere folgenden Personen danken, deren Arbeit überaus hilfreich während meiner Forschung und Entwicklung an unserem S7-Client war:

• Thomas Wiens für sein außerordentlich wertvolles S7comm Wireshark dissector plugin

• Maik Brüggemann für seine Analyse der unverschlüsselten S7-1200 V3 Kommunikation und von TIA Portal V11

• Cheng Lei, Li Donghong und Ma Lian für ihre grundlegende Analyse der verschlüsselten S7-1200 V4 Kommunikation und von TIA Portal V13

• Eli Biham, Sara Bitan, Aviad Carmel, Alon Dankner, Uriel Malin und Avishai Wool für ihre Veröffentlichung von weitaus mehr Details zur S7-Kommunikation

Über ENLYZE

Die ENLYZE GmbH mit Sitz in Köln versteht sich als vertikal integrierter Industrie 4.0 Lösungsanbieter. Mit ihrer auf die kontinuierliche Fertigung zugeschnittenen Cloud-Plattform ermöglicht sie mittelständischen Unternehmen, Maschinendaten aus heterogenen Anlagenparks zu erfassen, produktbasiert zu analysieren und weiteren Systemen zur Verfügung zu stellen. Auf diese Weise können ENLYZE-Kunden Produktionsprozesse optimieren, wichtiges Produktionswissen digitalisieren und somit Ihren OEE signifikant steigern. Dank des Full-Service-Ansatzes und der Eigenentwicklung von Hard- und Software kann die ENLYZE-Plattform oft 20x schneller und zu wesentlich geringeren Kosten als vergleichbare Plattformen integriert werden. Anstatt über kostspielige Maschinennachrüstungen wird die ENLYZE-Plattform sicher mit den existierenden Datenkommunikationsschnittstellen Ihrer Maschine verbunden. Für weitere Informationen besuchen Sie unsere Website ENLYZE oder schreiben Sie uns eine E-Mail.