SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 7
Es geht immer noch um Vorträge zu SCADA-Systemen und Industriesteuerungen auf den Sicherheitskonferenzen "Black Hat" und "Hack in the Box".
Nach den Konferenzen in den Jahren 2010/2011, 2011, 2012, im März, April und dem ersten Vortrag aus dem August 2013 geht es weiter um Vorträge aus dem Jahr 2013. Genauer: Um die von Lucas Apa und Carlos Mario Penagos auf der Black Hat USA 2013 vorgestellten Probleme mit der drahtlosen Kommunikation der Industriesteuerungen.
Im ersten Teil ging es unter anderen um die Anforderungen an die Schlüsselverteilung und die verschiedenen Arten von Schlüsseln, im zweiten Teil um die vom restlichen System unabhängige Verschlüsselung der Kommunikation durch die verwendeten Funk-Module und im dritten Teil um die Schlüsselverteilung von ZigBee. Nach diesen Vorbereitungen geht es nun um die von Lucas Apa und Carlos Mario Penagos gefundenen Schwachstellen.
August 2013 - Black Hat USA
Der Vortrag von Lucas Apa und Carlos Mario Penagos hatte den Titel "Compromising Industrial Facilities From 40 Miles Away". Auch dieser Text basiert auf den dort vorgestellten und im Whitepaper beschriebenen Problemen.
Hersteller 1: Schwacher Zufallszahlengenerator erleichtert Angriff
Die drahtlosen Geräte des ersten Herstellers (Namen werden von Lucas Apa und Carlos Mario Penagos nicht genannt) werden über ein Konfigurationstool eingerichtet. Beim Einrichten eines neuen Funk-Netzwerks wird eine zufällige Passphrase erzeugt und die Verschlüsselung auf 128-Bit AES eingestellt. Der für die Erzeugung der Passphrase verwendete Zufallszahlengenerator ist fehlerhaft, so dass sich die möglichen Passphrases berechnen lassen. Statt wie im Fall eines normalen Brute-Force-Angriffs 2570 müssen dadurch nur 156 Millionen Passphrases durchprobiert werden.
Das ist kein Problem, sofern der Benutzer eine eigene Passphrase verwendet. Aber oft wird der Einfachheit wegen die vom Tool gewählte Passphrase beibehalten. Vor allem, da im Handbuch steht
"Default values built into the software work well for initial installation"
und das Konfigurationstool
"... manages all important settings to ensure that the network performs correctly"
Hersteller 2: Systemzeit liefert den Funk-Schlüssel
Die Geräte des zweiten Herstellers werden über ein "project configuration file" konfiguriert, das von einem Konfigurationstool erstellt wird. Die Konfigurationsdatei wird über ein spezielles Kabel auf den Geräten installiert. Die Geräte verwenden eine "Enhanced Site Security", die in der Dokumentation folgendermaßen beschrieben wird:
"Enhanced Site Security - Enabling site security reduces the chance that transmitted information can be accessed by unauthorized devices or cross-talk between other devices operating in the area. By default, site security is enabled and it is recommended to keep this default setting."
(Hervorhebung vermutlich von Apa/Penagos)
Damit stellt sich die Frage, wie ein Gerät den autorisiert wird, Daten zu übertragen. In der Projekt-Datei könnte ein Pre-Shared Key enthalten sein, der dann allen zum Netzwerk gehörenden Geräten bekannt wäre. Es gibt da aber noch eine andere Information in der Dokumentation:
"The Enhanced Site Security feature is designed to provide an additional level of protection for RF packets sent and received between <Family> System devices and minimizes the possibility of interference from other devices in this area. This feature is not available on some older versions of legacy devices."
(Hervorhebung vermutlich von Apa/Penagos)
Die Verschlüsselung ist auf älteren Geräten also nicht verfügbar, wurde also erst im Laufe der Entwicklung irgendwann hinzugefügt.
In einer Setup-Anleitung wurden von Lucas Apa und Carlos Mario Penagos weitere Hinweise auf einen Pre-Shared-Key gefunden:
"1. If the project file name is changed, a new Site Security Key will be assigned.
2. DO NOT change the file name if you are planning to use the retrieved file to update the Gateway you retrieved the file from. Other Wireless End Nodes that may be connected to that Gateway will no longer be connected if the Security Key has been changed. "
(Hervorhebung vermutlich von Apa/Penagos)
Der Site Security Key scheint also vom Namen der Projekt-Datei abhängig zu sein. Da auf NTFS-Dateisystemen keine zwei Dateien den gleichen Namen haben können, wird so automatisch verhindert, dass es zu Kollisionen bei den Schlüsseln kommt und zufällig zwei verschiedene Netze (=Projekte) am gleichen Ort den gleichen Schlüssel verwenden. Diese Vermutung ist aber leider völlig falsch, die Schlüsselerzeugung ist sehr viel banaler. Schließt aber auch weitestgehend aus, dass zwei Projekte den gleichen Schüsssel verwenden.
Lucas Apa und Carlos Mario Penagos konnten über Reverse Engineering herausfinden, wie die Schlüssel erzeugt werden: Es handelt sich um die aktuelle Systemzeit beim Speichern der Dateien. Und in der Tat haben zwei kurz nacheinander erzeugte Projektdateien ähnliche Schlüssel. Das schränkt die Anzahl möglicher Schlüssel gewaltig ein, so dass ein Angreifer sie im Rahmen eines Known-Plaintext-Angriffs ermitteln kann. Mit dem Schlüssel kann der Angreifer dann mit den Geräten kommunizieren (sofern die Funkverschlüsselung überhaupt eingeschaltet ist, was sie im Allgemeinen aber sein sollte).
Zumindest ist es äußerst unwahrscheinlich, dass zwei Projekte den gleichen Schlüssel verwenden. Wenn überhaupt, könnte eine Kollision nur passieren, wenn die Projektdateien auf zwei verschiedenen Rechnern erzeugt werden. Die Wahrscheinlichkeit dafür, dass das bei der exakt gleichen Systemzeit passiert, dürfte verschwindend gering sein.
Die grundsätzliche Sicherheit der Geräte von Hersteller 2 scheint auf einem Per-Site Encryption Key Scheme zu basieren. Ein Angreifer kann diesen Schlüssel nur ermitteln, wenn er sich eines der zum Netzwerk gehörenden Geräte verschafft und dort den Schlüssel ausspähen kann. Wie es mit der Sicherheit dieses Schlüssels aussieht ist Thema der nächsten Folge.
Übersicht über alle Artikel zum Thema
- Die Heimautomation auf Sicherheitskonferenzen - als Thema, nicht im Einsatz
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2010
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2011
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2012
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 2
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 3
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 4
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 5
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 6
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 7
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 8
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen ab 2013, Teil 9
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen 2014, Teil 1
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen 2014, Teil 2
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen 2014, Teil 3
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen 2014, Teil 4
- SCADA-Systeme und Industriesteuerungen auf den Sicherheitskonferenzen 2014, Teil 5
Trackbacks