Es liegt in der Verantwortung der Betriebssystemhersteller, die Integrität und Sicherheit der von ihnen bereitgestellten Betriebssysteme zu gewährleisten - und ebenso wichtig - ihre Kunden zu informieren, wenn Schwachstellen identifiziert werden. Leider scheint diese Verantwortung im Fall der Passwort-Hashing-Implementierung von VxWorks nicht erfüllt worden zu sein.
Dieser Blogbeitrag behandelt eine kürzlich entdeckte Sicherheitslücke im Betriebssystem Wind River VxWorks, die Reaktion des Herstellers und unsere Perspektive, wie mit dieser Situation hätte umgegangen werden sollen.
Übersicht der Schwachstelle
Wir sind auf Probleme beim Passwort-Hashing gestoßen, als wir einen Penetrationstest eines auf VxWorks basierenden OT-Geräts durchführten. Weitere Informationen und Proof-of-Concept-Code finden Sie in unserem technischen Security Advisory. Nachfolgend eine Zusammenfassung der verschiedenen Passwort-Hashing-Algorithmen, die in VxWorks 6.9 bzw. 7 verwendet werden, und wie der Hersteller mit unserer koordinierten Schwachstellenmeldung (CVD) umging.
VxWorks 6.9: Schwacher Passwort-Hashing-Algorithmus
Der in VxWorks 6.9 eingeführte Passwort-Hashing-Algorithmus verwendet eine einzige Iteration von SHA-256 in Kombination mit einem Salt. Obwohl dieser Ansatz einen proprietären und kollisionsanfälligen Hashing-Algorithmus (CVE-2010-2965 von HD Moore) ersetzt, ist er nach heutigen Maßstäben immer noch völlig unzureichend.
Schon im Jahr 2011, als die erste Version von VxWorks 6.9 veröffentlicht wurde, galt die Verwendung einer einzigen Iteration für Passwort-Hashing als unzureichend. Zum Vergleich:
- md5crypt (1994): 1.000 Iterationen
- sha256crypt (2008): 5.000 Iterationen
- VxWorks 6.9 (2011): Eine Iteration
Dies macht den Algorithmus von VxWorks 6.9 etwa 600.000 Mal schwächer als die heutigen Mindestempfehlungen für die Passwortspeicherung, wie sie im OWASP Password Storage Cheat Sheet beispielsweise für SHA-256 beschrieben sind.
Angreifer können solche Passwörter leicht mit GPU-basierten Setups knacken. Mögliche Angriffsvektoren, um Passwort-Hashes zu erhalten, umfassen:
- Physischer Zugriff auf den Gerätespeicher (z. B. über UART, JTAG oder das Auslesen von Speicherchips).
- Fernzugriff auf Debugging-Schnittstellen.
- Extraktion von Firmware-Update-Dateien, die fest kodierte Accounts enthalten (z. B. Hersteller-Backdoors, die über die loginUserAdd()-Funktion hinzugefügt wurden).
VxWorks 7: Verbesserungen, aber immer noch nicht ausreichend
VxWorks 7, die aktuellste Hauptversion, führte einen neuen proprietären Hashing-Algorithmus mit 5.000 Iterationen von SHA-256 ein. Dies ist zwar eine Verbesserung gegenüber Version 6.9, hinkt aber immer noch modernen Standards hinterher.
Eingebettete Systeme verfügen heute über ausreichend Rechenleistung, um robustes Passwort-Hashing zu bewältigen. Moderne Implementierungen wie sha512crypt oder PBKDF2 funktionieren in ressourcenbeschränkten Umgebungen und verfügen über einen anpassbaren Cost Factor (= Anzahl der Iterationen).
Reaktion des Herstellers und unsere Einschätzung
Das Wind River PSIRT erhielt unsere Sicherheitsmeldung im Juli 2024, unternahm jedoch keine Maßnahmen und bot keine transparente Offenlegung. Für VxWorks 6.9 behaupteten sie fälschlicherweise, dass das System 5.000 Iterationen von SHA-256 für das Passwort-Hashing verwendet, obwohl unser Proof-of-Concept zeigte, dass nur eine einzige Iteration verwendet wird. Sie spielten die Schwere dieses Problems herunter und begründeten dies mit dem End-of-Life (EOL) des Produkts in drei Monaten.
Für VxWorks 7 wies der Hersteller die Notwendigkeit weiterer Verbesserungen zurück und erklärte, dass der Algorithmus "für ein eingebettetes System geeignet" sei. Der Hersteller behandelte das Problem als "Feature-Request", konnte jedoch keinen Zeitrahmen für die Umsetzung angeben.
Später planten wir ein Meeting mit dem Hersteller und versuchten (auf diplomatische Weise) ihn zumindest dazu zu bewegen, etwas zu diesem Problem zu veröffentlichen - etwa ein Security Advisory, technische Dokumentation oder eine Anleitung für Entwickler. Letztendlich entschied man sich jedoch, weder eine CVE-Nummer zu vergeben noch irgendwelches Material zu veröffentlichen.
Fazit
Der Passwort-Hashing-Algorithmus mit einer einzigen Iteration in VxWorks 6.9 ist nicht nur schwach - er ist praktisch eine Einladung für Angreifer, ihn zu knacken. Während VxWorks 7 leichte Verbesserungen bringt, liegt es immer noch weit hinter den modernen Standards zurück und fehlt an Flexibilität. Schlimmer noch ist die Weigerung des Herstellers, weitere Informationen zu veröffentlichen oder eine CVE-Nummer zu vergeben, wodurch Kunden im Unklaren über dieses Sicherheitsproblem bleiben. Dies ist ein Versagen in Sachen Transparenz und Verantwortlichkeit, das alle Nutzer etwas anfälliger macht, als sie sein sollten.
Glücklicherweise sind die meisten Hersteller, mit denen wir im SEC Consult Vulnerability Lab zusammenarbeiten, deutlich verantwortungsbewusster, wenn es um Produktsicherheit geht. Die Einführung von Vorschriften wie dem EU Cyber Resilience Act (CRA) ist ebenfalls ermutigend, da sie strengere Sicherheitsanforderungen und Transparenz bei Softwareprodukten durchsetzen und Hersteller zur Verantwortung ziehen will. Im Rahmen des EU Cyber Resilience Act werden Betriebssysteme als "wichtige Produkte mit digitalen Elementen" eingestuft - eine spezielle Kategorie, die erhöhte Anforderungen an Hersteller stellt.
Als Forscher im Bereich der Sicherheit von eingebetteten Systemen bleiben wir entschlossen, für bessere Sicherheitspraktiken zu kämpfen, auch wenn einige Hersteller lieber den Kopf in den Sand stecken würden.
SEC Consult unterstützt mit professionellem Penetrations-Testing von IoT-Geräten sowie Embedded-System-Penetrations-Testing, inklusive einem spezialisierten Hardware-Labor in Wien. Wir bieten umfassende Unterstützung für die OT-Umgebung und sind Experten für professionelles Penetrations-Testing für IT-Infrastrukturen und Softwareprodukte.
