Statische Passwörter, Hardcoded Keys, und schwache Kryptografie: Ein hartnäckiges Muster bei OT-Produkten

Bei eines Security Assessments haben wir eine Sicherheitslücke in der Passwortverschlüsselung (CVE-2024-52334) in Siemens Healthineers syngo.plaza VB30E entdeckt – einem in Krankenhäusern eingesetzten Archivierungssystem für medizinische Bilddaten. Die Sicherheitslücke ermöglicht es einem Angreifer, Original-Passwörter aus unzureichend verschlüsselten Speichern mit einem statischen Schlüssel wiederherzustellen und sich so möglicherweise unbefugten Zugriff auf medizinische Daten zu verschaffen.

Entdeckte Sicherheitslücke

Siemens Healthineers hat den Hotfix HF07 veröffentlicht, der das Problem behebt. Betreiber betroffener Versionen sollten gemäß den Anweisungen des Herstellers ein Update durchführen.

Siemens Healthineers Security Advisory: SSA-016040 

Diese spezifische Erkenntnis ist zwar relativ simpel, aber sie ist Teil eines viel größeren und seit langem bestehenden Musters in der OT und bei eingebetteten Produkten. Gemeint ist die Verwendung statischer Passwörter, fest codierter kryptografischer Schlüssel und schwacher oder fehlerhafter kryptografischer Implementierungen. Dieser Blogbeitrag nutzt unsere Erkenntnisse als Ausgangspunkt, um dieses Muster, die Gründe dafür und die Frage zu untersuchen, warum die regulatorischen Rahmenbedingungen (insbesondere in Europa) diese Praktiken bald zu einer ernsthaften Haftung machen werden.

Die Schwachstelle: Schwache Passwortverschlüsselung in syngo.plaza

Die Schwachstelle wird als CWE-261 (schwache Verschlüsselung für Passwörter) klassifiziert. syngo.plaza hat gespeicherte Passwörter nicht ordnungsgemäß verschlüsselt, sodass ein Angreifer mit Zugriff auf die entsprechenden Daten Klartext-Anmeldedaten wiederherstellen konnte.

Wir haben die Schwachstelle im Rahmen einer koordinierten Offenlegung gemeldet, und Siemens Healthineers hat sie mit einem Hotfix behoben.

Ein Muster, keine Anomalie

Diese Erkenntnis überraschte uns nicht. Statische Passwörter, fest codierte Schlüssel und unzureichende kryptografische Schutzmaßnahmen sind seit mehr als zwei Jahrzehnten ein Dauerproblem bei OT-Produkten. Das Problem beschränkt sich nicht auf einen einzelnen Anbieter oder Sektor, sondern ist ein branchenweites Muster, das in historischen Designentscheidungen und den besonderen Einschränkungen dieser Umgebungen begründet ist.

Stuxnet und das hardcoded Passwort, das eine Diskussion auslöste

Das vielleicht bekannteste frühe Beispiel stammt aus dem Jahr 2010: Siemens SIMATIC WinCC und PCS 7 verwendeten ein hardcoded Datenbankpasswort (CVE-2010-2772). Der Stuxnet-Wurm nutzte unter anderem diese Schwachstelle aus, um Systeme in der iranischen Nuklearinfrastruktur zu kompromittieren. Während Stuxnet ein außergewöhnlich ausgeklügelter Angriff war, handelte es sich bei dem hardcoded Passwort um eine ganz gewöhnliche Design-Abkürzung, die bereits seit Jahren offen in Siemens-Benutzerforen diskutiert wurde, bevor sie durch die Stuxnet-Angriffskampagne weltweit bekannt wurde.

S7CommPlus: Der lange Weg von hardcoded Schlüsseln zu TLS

Ein lehrreicheres Beispiel ist die Entwicklung der kryptografischen Schutzmaßnahmen in der Siemens S7-1200/1500-SPS-Produktreihe und ihrem S7CommPlus-Kommunikationsprotokoll. Diese Geschichte, die sich über ein Jahrzehnt Forschung erstreckt, veranschaulicht sowohl, wie diese Praktiken entstehen, als auch, wie schwierig es ist, sie zu lösen.

Als Siemens vor etwa einem Jahrzehnt mit TIA Portal v12 asymmetrische Kryptografie zum Schutz der SPS-Kommunikation und -Konfiguration einführte, war die dynamische Schlüsselverwaltung und -verteilung für die meisten industriellen Steuerungssysteme keine praktikable Option. Der operative Aufwand für Integratoren und Anlagenbetreiber wurde als zu hoch angesehen. Siemens entschied sich stattdessen für feste, hardcoded, kryptografische Schlüssel, die in jedes Gerät derselben Produktfamilie eingebettet waren.

Diese Designentscheidung war im Kontext verständlich: Sie priorisierte einfache Bedienbarkeit und Abwärtskompatibilität und setzte gleichzeitig höhere Maßstäbe als das völlig ungeschützte traditionelle S7Comm-Protokoll, das ihr vorausging. Das bedeutete aber auch, dass alle SPS desselben Modells den gleichen, privaten Schlüssel teilten.

Im Jahr 2019 demonstrierten Forscher des Technion (Israel Institute of Technology) auf der Black Hat USA, dass der S7CommPlus-Handshake nur die Gerätefamilie authentifizierte, nicht aber einzelne Geräte. Sie bauten eine gefälschte Engineering-Workstation, die sich als TIA-Portal ausgeben und Befehle an S7-1500-SPSen senden konnte, darunter auch das Herunterladen gefälschter Logik. Der Forscher Avishai Wool formulierte es so: „Alle SPSen des selben Modells haben den selben Schlüssel, was bedeutet, dass man, wenn man einen knackt, alle geknackt hat.“

Im Jahr 2022 ging Clarotys Team82 noch einen Schritt weiter (CVE-2022-38465, CVSS 9.3). Durch Ausnutzen einer zuvor entdeckten Schwachstelle bei der Remote-Codeausführung (CVE-2020-15782), um native Codeausführung auf S7-SPSen zu erreichen, extrahierten sie den globalen fest codierten privaten Schlüssel direkt aus dem SPS-Speicher. Mit diesem Schlüssel konnten sie die gesamte, geschützte Kommunikation zwischen SPSen und Engineering-Workstations entschlüsseln, konfigurierte Passwort-Hashes wiederherstellen, Man-in-the-Middle-Angriffe durchführen und einen vollständig unabhängigen S7-Client implementieren, ohne TIA Portal überhaupt zu benötigen.

Siemens reagierte mit einer Überarbeitung der kryptografischen Architektur. TIA Portal v17 und entsprechende Firmware-Updates führten in der Folge modernste TLS-basierte Kommunikation und individuelle Passwörter pro Gerät zum Schutz der Konfiguration ein. Dies war eine bedeutende und lobenswerte technische Leistung, zeigt aber auch, wie umfangreich die erforderlichen Abhilfemaßnahmen sind, wenn sich grundlegende kryptografische Annahmen als fehlerhaft erweisen. Betreiber weltweit müssen sowohl die Firmware als auch die Engineering-Software aktualisieren, Gerätepasswörter neu konfigurieren und Projekte migrieren – in großen Anlagen ein mehrjähriger Aufwand.

Schneider Electric: hardcoded Salts und Plaintext-Protokolle

Dieses grundlegende Problem betrifft wahrscheinlich eine große Anzahl traditioneller OT-Gerätehersteller. Im Jahr 2020 fanden Forscher beispielsweise einen hardcoded kryptografischen Salt in Schneider Electrics EcoStruxure Machine Expert (CVE-2020-28214). Da für jede Installation derselbe Salt verwendet wurde, konnte ein Angreifer die Passwörter für den Anwendungsschutz offline mit Brute-Force-Angriffen knacken, sobald das Hash-Schema bekannt war. Der hardcoded Wert wurde durch einfaches Disassemblieren der .NET-Binärdatei mit einem Standard-Decompiler gefunden.

Im Jahr 2022 gab Forescout CVE-2022-46680 bekannt, welches das UMAS-Protokoll von Schneider Electric betrifft, das von den SPSen Modicon M340 und M580 verwendet wird. Das Protokoll übertrug Passwörter im Klartext, eine Designentscheidung, die etwa 30 Jahre zurückliegt. Schneider Electric arbeitete eng mit Forescout an einer Lösung, was angesichts des Alters des Protokolls eine bemerkenswerte Leistung ist. Das Beispiel unterstreicht jedoch, wie sich alte Designentscheidungen über Jahrzehnte hinweg in Produktionsumgebungen halten.

OT:ICEFALL, die systemische Sichtweise

Ebenfalls im Jahr 2022 veröffentlichte Forescout’s Vedere Labs die Studie OT:ICEFALL, die 56 Schwachstellen in Produkten von 10 großen OT-Anbietern, darunter Siemens, Honeywell, Emerson, Omron und Yokogawa, aufdeckte. Mehr als ein Drittel der gemeldeten Schwachstellen (38 %) betraf die Kompromittierung von Anmeldedaten durch Speicherung im Klartext, fest codierte Anmeldedaten oder fehlerhafte kryptografische Implementierungen.

Die wichtigste Beobachtung der Forscher war bemerkenswert: es handelte sich nicht um obskure Fehler, sondern um grundlegende Probleme auf Design-Ebene. Hardcoded Passwörter, fehlende Authentifizierung, clientseitige Authentifizierungsprüfungen und fehlerhafte Kryptografieschemata waren wiederkehrende Muster bei allen Anbietern und Produktlinien. Am auffälligsten war, dass 74 % der betroffenen Produktfamilien über eine Form der Sicherheitszertifizierung verfügten, wie die CISA bei der Veröffentlichung entsprechender Hinweise feststellte. Die gefundenen Probleme hätten bei professionellen Sicherheitsbewertungen, einschließlich technischer Überprüfungen, relativ schnell entdeckt werden müssen.

Warum es immer wieder passiert: Die Beweggründe verstehen

Es wäre einfach, die Schuld für mangelhafte Sicherheitspraktiken einfach den Anbietern zu geben. Die Realität ist jedoch differenzierter. In der Vergangenheit haben mehrere Faktoren diese Designentscheidungen in OT-Umgebungen beeinflusst.

Einfache Bedienung hat Vorrang. OT-Systeme werden üblicherweise von Ingenieuren und Technikern bedient, nicht von IT- (Sicherheits-)Spezialisten. Komplexe Schlüsselverwaltung, Zertifikatsinfrastruktur und Passwortrichtlinien führen zu Reibungsverlusten im Betrieb, die sich direkt auf die Systemverfügbarkeit auswirken können. Wenn eine SPS während eines ungeplanten Ausfalls ausgetauscht werden muss, ist ein gemeinsam genutzter Schlüssel, der sofort funktioniert, eindeutig attraktiv. Wenn ein Außendiensttechniker für die Fehlerdiagnose Fernzugriff benötigt, ist ein fest codiertes Service-Passwort aus betrieblicher Sicht praktisch. 

Lange Produktlebenszyklen führen zu Trägheit. OT-Produkte sind auf eine Betriebsdauer von 15-25 Jahren ausgelegt. Kryptografische Best Practices, die zum Zeitpunkt der Entwicklung als akzeptabel galten, können zum Zeitpunkt der Bereitstellung bereits veraltet und ein Jahrzehnt später eindeutig unzureichend sein. Die Nachrüstung geeigneter Kryptografie in bereits eingesetzten Produkten, insbesondere in eingebetteten Systemen mit begrenzten Rechenressourcen, ist eine erhebliche technische Herausforderung.

Abwärtskompatibilität beschränkt Optimierungspotenziale. Viele Protokolle und Produkte müssen die Interoperabilität mit älteren Geräten aufrechterhalten. Die Einführung einer geeigneten Authentifizierung oder Verschlüsselung bedeutet oft, dass die Kompatibilität mit der bestehenden installierten Basis nicht mehr gegeben ist, was zu einer schwierigen Übergangsphase führt, in der Alt und Neu nebeneinander existieren müssen. Die Protokollkorrektur von Schneider Electric UMAS zeigt, dass dies möglich ist und wie lange es dauern kann.

Security hatte in der Vergangenheit keine Priorität. In der Geschichte industrieller Steuerungssysteme ging man lange davon aus, dass diese Systeme physisch von nicht vertrauenswürdigen Netzwerken getrennt sein würden. Unter dieser Annahme machte es wirtschaftlich wenig Sinn, stark in die Sicherheit auf Produktebene zu investieren. Die Konvergenz von IT- und OT-Netzwerken in den letzten zwei Jahrzehnten hat diese Annahme vollständig widerlegt – die Produktentwicklungszyklen in der OT verlaufen allerdings langsam.

Keiner dieser Faktoren rechtfertigt allerdings die fortgesetzte Auslieferung von Produkten mit fest programmierten Anmeldedaten oder schwacher Kryptografie im Jahr 2026. Aber ihr Verständnis hilft zu erklären, warum das Problem so tief verwurzelt ist und warum regulatorischer Druck zunehmend als notwendig angesehen wird, um Veränderungen voranzutreiben.

Die regulatorische Abrechnung

Für europäische Betreiber und Hersteller wird ein regulatorischer Rahmen geschaffen, der die Bewertung und Ahndung dieser Praktiken grundlegend verändern wird.

EU Cyber Resilience Act (CRA)

Der Cyber Resilience Act (Regulation (EU) 2024/2847) trat im Dezember 2024 in Kraft, wobei die Meldepflichten ab September 2026 gelten und die vollständige Einhaltung bis Dezember 2027 erforderlich ist. Der CRA führt verbindliche Cybersicherheitsanforderungen für alle „Produkte mit digitalen Elementen” ein, die auf dem EU-Markt in Verkehr gebracht werden. Der Anwendungsbereich ist breit gefasst und umfasst Komponenten industrieller Steuerungssysteme, IoT-Geräte, Netzwerkausrüstung und die meisten kommerziellen Softwareprodukte.

Hersteller müssen sicherstellen, dass ihre Produkte so konzipiert, entwickelt und hergestellt werden, dass sie ein angemessenes Maß an Cybersicherheit auf der Grundlage der Risiken gewährleisten. Neben anderen Anforderungen muss ein Produkt nach einer Risikobewertung auf den Markt gebracht werden, ohne bekannte ausnutzbare Schwachstellen, in einer standardmäßig sicheren Konfiguration, mit einer minimierten Angriffsfläche sowie einem angemessenen Schutz der Vertraulichkeit und Integrität von gespeicherten und übertragenen Daten. Darüber hinaus müssen Sicherheitsupdates während der festgelegten Support-Dauer kostenlos zur Verfügung gestellt werden, um sicherzustellen, dass später identifizierte ausnutzbare Schwachstellen im Produkt bei Bedarf gepatcht werden können.

Zwar wird die Verwendung schwacher oder fest codierter Standardpasswörter nicht ausdrücklich verboten, doch angesichts der oben genannten Anforderungen wird es schwieriger sein, solche Designentscheidungen zu verteidigen. Das Hardcoding oder Nichtdurchsetzen einer Änderung von Standardpasswörtern steht im Widerspruch zu „Secure by Default“ und ist eine bekannte ausnutzbare Schwachstelle.

Die Nichteinhaltung der wesentlichen Cybersicherheitsanforderungen in Anhang I wird mit Strafen von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes geahndet, je nachdem, welcher Betrag höher ist. Produkte, die die Konformitätsbewertung nicht bestehen, verlieren vollständig den Zugang zum EU-Markt. IoT-Geräte, die mit hardcoded oder nicht änderbaren Standardpasswörtern ausgeliefert werden, werden ausdrücklich als Beispiele genannt, die die höchsten Strafen nach sich ziehen würden.

Für Hersteller von OT-Produkten sind die Auswirkungen erheblich. Produkte, die mit hardcoded Anmeldedaten, schwacher Passwortverschlüsselung oder gemeinsam genutzten kryptografischen Schlüsseln ausgeliefert werden, werden nicht nur von Security-Forschern, sondern auch von Marktüberwachungsbehörden mit Durchsetzungsbefugnissen genau unter die Lupe genommen. Die Ära, in der „insecure by Design“ als akzeptabler Kompromiss galten, geht zumindest für den europäischen Markt zu Ende.

IEC 62443

Die Normenreihe IEC 62443 ist seit Langem der Referenzrahmen für industrielle Cybersicherheit. Teil 4-1 definiert Anforderungen an einen sicheren Produktentwicklungslebenszyklus, und Teil 4-2 legt technische Sicherheitsanforderungen für einzelne Komponenten fest, darunter explizite Anforderungen in Bezug auf die Verwaltung von Anmeldedaten, die kryptografische Implementierung und Authentifizierungsmechanismen. Die IEC hat die IEC 62443 als „horizontale” Normen genehmigt, was bedeutet, dass sie als Grundlage für die Entwicklung sektorspezifischer OT-Sicherheitsnormen dienen.

Obwohl die IEC 62443-Zertifizierung bereits seit Jahren verfügbar ist, hat die OT:ICEFALL-Studie eine unangenehme Wahrheit ans Licht gebracht: 74 % der betroffenen Produktfamilien verfügten über eine Form der Sicherheitszertifizierung. Dies deutet darauf hin, dass sich die Zertifizierungsprozesse manchmal eher auf die Einhaltung von Verfahren und Funktionstests als auf strenge Sicherheitsbewertungen konzentriert haben.

Standardisierungsgremien arbeiten derzeit an mehreren Normen, um Herstellern von Produkten mit digitalen Elementen klare Anforderungen für die Einhaltung des CRA an die Hand zu geben. In Normen des Typs B werden allgemeine Grundsätze und Sicherheitsanforderungen für Produkte definiert. In speziellen Normen des Typs C werden vertikale Standards für bestimmte Produktgruppen definiert. Die meisten dieser Normen befinden sich jedoch noch in der Entwurfsphase, wobei die Veröffentlichungstermine auf das dritte Quartal 2026 sowie das vierte Quartal 2027 festgelegt sind. Das Warten auf diese Normen ist riskant, da sie sich noch ändern können und am Ende möglicherweise nicht als harmonisierte Norm deklariert werden.

Eine bereits bestehende harmonisierte Normenreihe ist EN 18031-1/2/3 für die in der Funkanlagenrichtlinie festgelegten Sicherheitsanforderungen. In Bezug auf Geheimnisse und kryptografische Algorithmen legt sie fest, dass Algorithmen auf dem neuesten Stand der Technik verwendet werden müssen und dass die werkseitigen Standardeinstellungen entweder für jedes Gerät einzigartig sein müssen oder bei der ersten Verwendung geändert werden müssen.

Die IEC 62443-Reihe kann in ihrer derzeitigen Form zwar keine harmonisierte Norm werden, ist jedoch eine bestehende, vereinbarte Norm, die in der Branche häufig verwendet wird. Sie deckt einen Großteil der in der CRA festgelegten Anforderungen ab. Daher bereiten alle Bemühungen zur Einführung und Einhaltung der IEC 62443-4-1 für organisatorische Aspekte sowie der IEC 62443-4-2 für technische Anforderungen an Komponenten oder der IEC 62443-3-3 für technische Anforderungen an Systeme das Produkt optimal auf die Einhaltung der kommenden Vorschriften vor.

Empfehlungen für Betreiber und Hersteller

Für Betreiber betroffener Systeme

• Wenden Sie den Hotfix für syngo.plaza (VB30E_HF07) gemäß der Empfehlung SSA-016040 von Siemens Healthineers an.
• Überprüfen Sie Ihr OT- und Embedded-Produktinventar auf Produkte mit bekannten statischen Anmeldedaten oder schwachen Kryptografie-Schwachstellen.
• Priorisieren Sie die Netzwerksegmentierung, um die Auswirkungen einer Kompromittierung von Anmeldedaten zu begrenzen.
• Führen Sie regelmäßige Sicherheitsbewertungen durch, die nicht nur Konfigurationsprüfungen, sondern auch Tests auf Produktebene umfassen:
• Penetration Tests sind ein hilfreiches Mittel zur Schwachstellen-Identifikatkion

Für Hersteller

• Entfernen Sie fest codierte Anmeldedaten und statische Schlüssel aus allen Produkten. Dies ist eine grundlegende Anforderung sowohl gemäß CRA als auch gemäß IEC 62443.
• Das Limes Security Product and Solution Security Team kann Ihnen dabei helfen, regulatorische Anforderungen zu klären, das Risikoprofil zu bestimmen, Sicherheitsanforderungen und eine sichere Architektur zu definieren sowie organisatorische Prozesse und Arbeitsanweisungen einzuführen, um sicherzustellen, dass die Produktsicherheit ein integraler Bestandteil des gesamten Produktlebenszyklus ist (vom ersten Entwurf über die Implementierung, das Testen und die Dokumentation bis hin zu Updates).

Wir danken Siemens Healthineers für die professionelle Abwicklung dieser Offenlegung.