Hörmann: Tag der offenen Tür für alle...
vulnerability
1. TL;DR
SEC Consult hat mehrere Schwachstellen in Hörmann BiSecur Gateway entdeckt.
Durch einen Logikfehler in einem Protokoll der zugrundeliegenden Architektur ist es einem Angreifer möglich, aus der Ferne Zugangsdaten von registrierten Kunden auszulesen.
Ein lokaler Angriff kann ebenfalls schwerwiegende Folgen haben. Mangels Zeitablaufs einer Verbindung kann ein Angreifer mithilfe einer kurzen Sitzungskennung die Sitzung eines mit dem Gerät verbundenen Benutzers übernehmen.
Ein Angreifer im lokalen Netzwerk kann also mithilfe des BiSecur Gateway-Systems beliebige Türen öffnen. Ein Angreifer außerhalb des lokalen Netzwerkes kann über das Internet mithilfe des BiSecur Gateway-Systems alle Benutzeranmeldeinformationen abrufen und damit Kundentüren öffnen. Der folgende Blog-Beitrag bietet einen Überblick darüber, wie die Sicherheitslücken identifiziert wurden.
Anmerkung: Dieser Artikel enthält externe Links zum persönlichen GitHub-Konto des Autors und sowie zu weiterführenden Projekten.
2. MOTIVATION
Vor einigen Jahren wollte ich einen Garagentoröffner in einer privat angemieteten Garage installieren lassen. Im Leistungsumfang war eine zusätzliche Fernbedienungslösung erwähnt, mit der das Garagentor anstelle eines physischen Schlüsselanhänger auch über ein Smartphone gesteuert werden konnte. Das klang nach einer vernünftigen und vor allem kostengünstigen Alternative. Die beauftragte Firma (ein offizieller Hörmann-Partner), wies mich darauf hin, dass er mir dieses Remote-Feature zwar verkaufen könnte, ich es aber selbst installieren müsse. Aufgrund zahlreicher Beschwerden könnte er bzw. seine Firma keine Verantwortung übernehmen. So blieb mir also nichts andres übrig, als die Installation selbst vorzunehmen.
Während der Inbetriebnahme stellte ich fest, dass das BiSecur Gateway-Gerät nicht ordnungsgemäß funktionierte. Immer wenn ich das Gerät ausschaltete, wurden scheinbar alle benutzerdefinierten Einstellungen (einschließlich WLAN-Profile) zurückgesetzt und somit war eine Kopplung mit meinem Garagentor nicht möglich. Anstatt aufzugeben, wollte ich hinter die Kulissen des Kunststoffgehäuses blicken und dem Problem auf den Grund gehen.
3. SPEZIFIKATION DES ZIELGERÄTES
Hersteller: Hörmann
Produktname: BiSecur Gateway
Beschreibung: Das BiSecur Gateway-Gerät ist ein Microchip-Mikrocontroller, der mit einem offiziellen Hörmann-Schlüsselanhänger ausgestattet ist. Er verfügt über eine WLAN- und Ethernet-Schnittstelle, damit Endbenutzer ihre Garagentore nach entsprechender Kopplung mit der Motorsteuerung auch aus der Ferne öffnen und schließen können. Die mobile Anwendung erlaubt es Benutzern, über ein lokales Netzwerk und remote über das Internet direkt mit dem Gateway-Gerät zu kommunizieren.
Verkäufer: Amazon
4. Hardware
Produktbild:
CPU: PIC32MX695F512H
Flash Chip: 25LC1024
Schnittstellen (Intern): SPI, MDB (Microchip)
Schnittstellen (Extern): WLAN, Ethernet
4.1.1. Auslesen
Zunächst mussten die erforderlichen Pins auf dem Chip identifiziert werden. Eine Möglichkeit, die nicht ganz zum Standardvorgehen gehört, ist es, ein Bus Pirate (BP3)-Gerät direkt an die freiliegenden Pins anzuschließen und mit dem Chip zu verbinden. Leider hat dies bei der vorliegenden Leiterplatte nicht funktioniert, daher musste der Flash-Chip von der Leiterplatte entfernt und auf eine Breakout-Platine gelegt werden.
Für das Auslesen hat sich bis jetzt immer flashrom bewährt, allerdings war die Software in diesem Fall nicht besonders hilfreich. Aus unerklärlichen Gründen reagierte der Chip auf keines der Kommandos des Flashroom-Skripts. Somit blieb nur noch der Weg der manuellen Konfiguration des BP3, um den Chip auszulesen. Auf diese Weise konnte der Inhalt in eine Textdatei ausgelesen und im HEX-Format gespeichert werden. Mit Hilfe eines Python-Skripts konnte das korrekte Binärformat wiederhergestellt werden.
Die Firmware Analyse Plattform IoT Inspector erkennt diese Probleme ebenfalls, und sogar noch viel mehr.
Die Entropie-Analyse lies erahnen, dass es noch weitere Daten gibt, die Binwalk nicht vollständig identifizieren konnte. Deshalb wurde die manuelle Analyse mit xxd fortgesetzt.So wurden einige interessante Speicherbereiche (die eigentlich nur strukturierte Daten enthalten sollten) ausfindig gemacht. Dort wurden Informationen gespeichert, die sich später als hardcodierte Administratorzugangsdaten (Benutzername und Kennwort) entpuppten. Die anfänglich aufgestellte Hypothese, dass hier alle Zugangsdaten im Klartext gespeichert wurden, stellte sich als wahr heraus.
Neben hardkodieren Zugangsdaten des Administrators, wurden weitere wertvolle Identifikationsdaten (z. B. Seriennummern) gefunden. Für eine weitere Analyse waren diese jedoch nicht von Bedeutung. Im nächsten Schritt sollten die Zertifikat- und privaten Schlüsseldaten extrahiert werden. Dafür kam ein eigens geschriebenes Python-Skript zum Einsatz. Später stellte sich heraus, dass binwalk dies auch durchführen hätte können.
4.1.3. Swapping Mechanismus
Nach der ersten Analyse war unklar, was genau passieren würde, wenn ein Aktualisierungsprozess die Originaldaten auf Werkseinstellungen zurücksetzen würde. Schlimmstenfalls müsste der Flash-Chip mehrmals entfernt und neu ausgelesen werden. Ein Schaden am Chip war nicht ausgeschlossen. Erfreulicherweise gab es noch einen anderen Weg: Bei der Überprüfung der Kabel zwischen der CPU (Mikrocontroller) und dem Flash-Chip stellte sich heraus, dass derselbe SPI-Bus auch mit dem WLAN-Modul geteilt wurde. Das waren sehr gute Nachrichten! Da das WLAN-Modul extern war, konnten die Pins für die Plug-in-Flash-Chip-Lösung verwenden werden.
Sind Sie neugierig auf diese Plug-In-Lösung? Machen Sie sich selbst ein Bild:
Um eine „wiederverwendbare“ Flash-Chip-Umsetzung zu erhalten, wurde der Flash-Chip auf einer Breakout-Platine mit einer kleinen Leiterplatte mit einem Sockel zum Anschließen platziert. Dies ist praktisch, wenn Daten auf dem Chip z.B. durch Updates geändert und mehrmals gelesen werden.Auf den ersten Blick ergab die Analyse nichts Besonderes. Warum sollten Sie die Daten auf dem Flash überhaupt ändern, wollen Sie wissen?
- Weil es Spaß macht…
- Das Vorhandensein eines privaten Schlüssels und zweier Zertifikate lässt darauf schließen, dass das SSL/TLS-Protokoll für die Authentifizierung der Benutzer und das Zuweisen von Zertifikaten verwendet wird. Bei einer Man-in-The-Middle (MiTM) Attacke bleibt zu hoffen, dass die Standard-SSL-Konfiguration sicher ist. Alternativ kann mit einem Test überprüft werden, ob die Funktionalität und Integrität des BiSecur-Gateways gegen den Austausch von Zertifikaten und (von Benutzern generierten) privaten Schlüsseln geschützt sind. Diese Art von Angriff würde beweisen, dass das Gerät nicht direkt mit dem Backend-Server von Hörmann kommunizieren kann, sondern nur über unseren Proxy. Der Proxy kann bei Bedarf so konfiguriert werden, dass die richtige Authentifizierungshardware für den erforderlichen Hörmann-Server verwendet wird. Mit dieser Konfiguration haben wir die volle Kontrolle über den Kommunikationskanal sowie die Anforderung von ausgehenden Verbindungen.
Micro-Controller
4.2.1. Auslesen der Firmware
Im Zuge der Analyse bestätigte sich der Verdacht, dass sich die Firmware im Mikrocontroller selbst befindet. Normalerweise bedeutet dies, dass es schwierig ist, die Firmware zu extrahieren, weil Mikrocontroller üblicherweise einen Zugriffschutz auf nichtflüchtige Speicherbereiche besitzen. Diese Funktion wird durch das Abbrennen von Sicherungen aktiviert, die wie einmalig programmierbare Bits funktionieren. Wie sich später herausstellte, wurde keine der Schutzfunktionen aktiviert.
Die Debug-Pins des Mikrocontrollers sind per Werkseinstellung mit dem Header auf der Platine verbunden, aber der Header hat keine Anschlüsse. Zwei der Pins hielten ein kleines Stück Plastik zusammen und den WLAN-Dongle physisch an Ort und Stelle. Nach dem Entfernen der WLAN-Schnittstellenplatine und der Platzhalter-Pins, konnte der Header neu erstellt werden. Mit dem Programmiertool MPLAB PICKIT können Entwickler eine Schnittstelle zu Mikrocontrollern herstellen und Lese-/Schreib-/Debug-Aufgaben ausführen. Da es sich aber um eine proprietäre Debugging-Schnittstelle handelt, ist es empfehlenswert diese zu nutzen (bzw. zu kaufen) wenn Sie an Mikrocontrollern von Microchip basteln möchten. Nach der Installation der erforderlichen Treiber und Software wurde der Debugger mit dem neu erstellten Header verbunden und – siehe da – es funktionierte! Das Lesen der Chip-ID war erfolgreich, ebenso wie das Lesen der Sicherungen. Aus der Liste der Sicherungen war ersichtlich, dass kein Firmware-Leseschutz aktiviert wurde. Mit derselben Software konnte die Firmware gesichert und in Ghidra geladen werden.
5. Ethernet
Zur Kommunikation zwischen dem BiSecur Gateway-Gerät und dem Smartphone des Benutzers sowie zwischen dem Gerät und einem Hörmann-Server im Internet, wird ein Ethernet-Port genutzt. Zur Analyse der verschiedenen Kommunikationskanäle waren daher zwei verschiedene Proxy-Konfigurationen erforderlich:
- Passives Sniffing mit Wireshark
- Ein aktiver MiTM Proxy
5.1. LAN
Um eine Kopie aller Pakete an eine Analyse-Workstation mit Wireshark-Erfassungsfunktionen zu senden, wurde ein Microtik-Router mit Portspiegelung eingerichtet. Das BiSecur Gateway-Gerät wurde dann über Ethernet verbunden, während das Android-Smartphone mit der installierten App vom Router mit dem WLAN-Broadcast verbunden war. Auf diese Weise konnte der gesamte Datenverkehr zwischen dem BiSecur Gateway-Gerät und dem Smartphone erfasst werden.
5.1.1. Analyse der Pakete
Nach dem Start sucht die mobile Anwendung zunächst nach verfügbaren Geräten. Wireshark zeigt, dass zu diesem Zeitpunkt der UDP-Verkehr stattfindet. Beim Überprüfen der erfassten Pakete stellte sich heraus, dass die Anwendung einen eigenen UDP-Broadcast zur Suche nach Geräten nutzt. Der Broadcast-Verkehr selbst ist eine XML-Entität, wie im folgenden Bild dargestellt wird:
Um die neu erfassten Pakete zu analysieren, wurde die Überwachung nach dem Ende des Verbindungsvorgangs pausiert. Ungewöhnlicher Weise nutzte das BiSecur Gateway-Gerät ein benutzerdefiniertes Textprotokoll (Wireshark zeigte die vom/zum Gerät übertragenen ASCII-Zeichen an). Die Zeichenfolgen waren hexadezimal codierte Bytes, die zuerst dekodiert werden mussten, um die Analyse fortzusetzen. Dies bestätigte die Annahme, dass es sich um ein nicht standardmäßiges Protokoll handelt (wie aus der ASCII-Codierung hervorging). Die Vermutung lag nahe, dass es möglicherweise noch weitere Sicherheitsprobleme geben könnte. Benutzerdefinierte Protokolle zu entwerfen ist selten eine gute Idee (dies gilt auch für Kryptographie), denn das Entwerfen eines qualitativ hochwertigen und sicheren Protokolls ist sehr zeitaufwendig. Abgesehen davon, dass es von Dritten überprüft und getestet werden sollte. In 99,99% der Fälle ist es absolut unnötig, sich diesen Aufwand anzutun, weil es bereits eine Vielzahl an getesteten und verifizierten Protokollen gibt, die mit robusten und fertig implementierten Bibliotheken ausgestattet sind. Im vorliegenden Fall konnte der Großteil des Protokolls durch einfaches Beobachten des Datenverkehrs entschlüsselt und reverse-engineered werden. Es würde den Umfang dieses Artikels sprengen, weiter auf Details des Reverse-Engineering-Prozesses einzugehen, daher beschränken wir uns an dieser Stelle auf die Struktur des Protokolls:
Einige Elemente konnten durch das Mitlesen des Datenverkehrs allein nicht identifiziert werden: Bei zwei-Byte-Positionen könnte es sich um CRC handeln, aber der verwendete Algorithmus war nicht eindeutig identifizierbar. Zwar konnten zu diesem Zeitpunkt nur die Verbindungsstrukturen bewertet werden, dies war jedoch ausreichend, um einen Parser zu erstellen. Der Parser bildete die nötige Grundlage für das Lesen und Verstehen der Kommunikation und kann später genutzt werden, um eine vollständige Bibliothek zu erzeugen.
Vielleicht fragen Sie sich jetzt, wie das Mobiltelefon mit dem virtuellen Gerät kommuniziert. Hier kommt die erwähnte UDP-Übertragung ins Spiel.
Probleme, die in der Kommunikation zwischen Gerät und Smartphone bereits festgestellt wurden:
- Die Geräteerkennung ist ungeschützt und verwendet einen UDP-Broadcast.
- Das Protokoll ist Klartext ohne Sitzungsschutz oder Authentifizierung der Clients.
- Das Protokoll nutzt eine zusätzliche Hex-Codierung (erst später sollte sich herausstellen, warum).
5.1.2. Spoofing Device Discovery
Wie bereits erwähnt, setzt die mobile App einen UDP-Broadcast ein, um verfügbare Geräte zu ermitteln. Dies wirft einige Probleme auf:
- UDP-Broadcast funktioniert nur im jeweiligen Broadcast-Netzwerk. Leider ist das Gerät nicht auffindbar, wenn es sich in einem anderen Sendebereich befindet.
- Der gesamte Discovery-Prozess wird im Klartext ausgeführt. Die Geräteantwort beinhaltet auch die Geräte-ID. Die Geräte-ID ist die MAC-Adresse. Da sich das Gerät im gleichen Broadcast-Bereich befinden muss, kann die MAC-Adresse auch mithilfe eines ARP-Scans ermittelt werden.
- UDP-Pakete können leicht gefälscht („gespoofed“) werden.
Was sind die sicherheitsrelevanten Konsequenzen? Unter Zuhilfenahme eines einfachen Python-Skripts kann man auf die Discovery-Broadcasts als ein neues Gerät oder als ein Gerät antworten, das sich tatsächlich im lokalen Netzwerk befindet. Letzteres ist insofern spannend, weil die mobile App bei Erfolg eine Verbindung zu dem „virtuellen“ Gerät herstellt. Da sich viele Inhalte im Klartext auslesen lassen, sollte es möglich sein, die Verbindungsprozedur nachzubauen und damit Anmeldeinformationen abzugreifen.
Das vorgestellte Spoofing-Skript ist hier zu finden.
5.1.3. Kommunikation mit dem Gerät
Die unterstützten Befehle sind in der Grafik links zu sehen. Jeder Befehl zählt doppelt, weil für die Antwort auf den jeweiligen Befehl dieselbe ID und dasselbe Format verwendet werden. Im Falle einer Antwort wird das erste Bit der Kennung auf 1 gesetzt. Die Befehlsstruktur: „Wo ist der Update-Befehl?“
Initiiert wird die Kommunikation zwischen dem BiSecur Gateway und der Smartphone-Anwendung mit dem Befehl GET_MAC, gefolgt vom Befehl LOGIN, der den Benutzernamen und das Kennwort (in Klartext) enthält. Die PAYLOAD-Struktur enthält ein TOKEN-Feld, das fortan zur Benutzeridentifikation genutzt wird. Anfänglich beginnt es mit vier \x00 (Null) Bytes und nach erfolgreicher Anmeldung nimmt es einen „zufälligen“ Wert an. Leider ist diese Zufälligkeit nicht ganz so zufällig. Nach erfolgreicher Anmeldung beginnt das TOKEN-Feld mit zwei Null-Bytes. Da das Protokoll über keinen Anti-Brute-Force-Mechanismus (ausgenommen Sie senden Pakete mit mehr als 1 MBit/s, dann versetzt sich das Gerät in einen DOS-Modus). Ein Angreifer muss im Grunde nur 2 bis 4 Bytes erraten. Erwähnenswert ist auch die Tatsache, dass das TOKEN nur in zwei Fällen ungültig wird:
- Das Gerät wird komplett ausgeschaltet.
- Das Token beinhaltet den expliziten Befehl LOGOUT.
Der Befehl LOGOUT wird nur gesendet, wenn der Benutzer ausdrücklich auf die Schaltfläche zum Abmelden klickt (und dort ist diese Option gut versteckt).
Die Befehle nach der Anmeldesequenz beschäftigen sich damit, Türen zu öffnen und zu schließen sowie dem Benutzer Feedback zu seiner aktuellen Position zu geben. Für die Befehle zum Öffnen/Schließen der Türen (HM_GET_TRANSITION) ist eine Benutzerauthentifizierung erforderlich. Das wirft die Frage auf „Welche Befehle erfordern denn keine Authentifizierung?“
Nach einer komplett angepassten Implementierung des Protokolls, führte das bloße Durchlaufen aller Befehle ohne Argumente zu einem Geräteabsturz. In einer weiteren Iteration der Implementierung und Neustart des Geräts kam es zu einem Timeout. Dabei stellte sich heraus, dass der DEBUGBefehl das Gerät ohne Authentifizierung zum Absturz bringt. Dies ist ein guter Anfang, um herauszufinden, was es noch geben könnte. Es wurden einige interessante Befehle identifiziert, für deren erfolgreiche Ausführung ebenfalls keine Authentifizierung erforderlich ist: DEBUG, ADD_USER, SCAN_WIFI, GET_MAC, PING, GET_USER_IDS. Mal sehen, was wir damit anstellen können!
ADD_USER: Mit diesem Befehl kann ggf. ohne Authentifizierung ein Benutzermit einem Kennwort erstellt werden. Das Gerät unterstützt jedoch nur maximal 10 Benutzerkonten. Obwohl Smartphone-Anwendungen nur ASCII unterstützen, ist nicht sichergestellt, dass Benutzer nur erlaubte Zeichen einfügen. Im schlimmsten Fall führt das Verwenden von Nicht-ASCII Zeichen dazu, dass die Anwendung für ALLE Benutzer nicht mehr funktioniert – d.h. eine Anmeldung und das Bedienen der Türsteuerung nicht mehr möglich ist. Auch die Länge des Passwortes wird nicht überprüft und kann gesetztenfalls zu einem Memory Leak führen (die Anmeldedaten werden direkt in den Flash-Speicher geschrieben, daher kann dieses Problem von einem Angreifer nicht genutzt werden). Zusammenfassend kann ein Angreifer über diesen Befehl einige Bytes der tatsächlichen Firmware abrufen. Mangels entsprechender Schutzmechanismen gibt es aber weitaus einfachere Möglichkeiten, die Firmware auszulesen.
DEBUG: Es ist nicht klar, was dieser Befehl tut. Ohne Parameter aufgerufen, kann das Gerät erfolgreich zum Absturz gebracht werden. Mangels Authentifizierung kann ein Benutzer im selben LAN das Gerät also unbrauchbar machen, bis es zurückgesetzt wird. Es wird daher empfohlen, dieses Gerät in einem verschlossenen Raum aufzustellen.
SCAN_WIFI: Dadurch wird eine Liste der Zugriffspunkte ausgegeben, die das Gerät sehen kann.
5.2. Internet
Die Kommunikation zwischen dem BiSecur Gateway-Gerät und dem im Internet verfügbaren Hörmann-Backend-Server wurde mit derselben Konfiguration wie die Analyse des LAN-Traffics durchgeführt. Zwar verwendet das Gerät einen SSLv3-Sitzungsschutz und Authentifizierung der Clients, aber die Installation und Konfiguration von SSL verbietet die Durchführung eines MiTM zwischen dem Gerät und dem Back-End-Server. Das bedeutete, dass nur verschlüsselter Verkehr sichtbar war.
Um einen MiTM-Angriff mit SSL durchzuführen, waren einige extra Schritte notwendig. Erinnern Sie sich an die Flash-Speicheranalyse? Durch die Einrichtung einer eigenen Certificate Authority („CA“, dt. Zertifizierungsstelle), konnten ein Client-Zertifikat und ein privater Schlüssel an der richtigen Position im Speicher des Flash-Chips hinterlegt werden. Danach konnte das BiSecur Gateway-Gerät nicht mehr mit dem Server kommunizieren. Durch ein kleines Python-Skript, das als generischer TCP-Proxy fungierte, konnte die schadhafte Certificate Authority serverseitig am Proxy eingerichtet werden. Somit wurde das gewünschte Client-Zertifikat auf der Clientseite des Proxys verwendete. Burp oder andere etablierte Webproxy-Lösungen konnten in diesem Fall den abgefangenen Datenverkehr leider nicht richtig interpretieren. Obwohl das Gerät auf Basis TCP/443 und SSL kommuniziert, war das zugrunde liegende Protokoll nicht HTTP sondern entpuppte sich als das gleiche Spezial-Protokoll, das bei der Durchführung der lokalen LAN-Analyse zum Einsatz kommt.
Der TCP-Proxys sollte im Wesentlichen den Datenverkehr zwischen dem Gerät und dem Server in 4096 Byte-Schritten übertragen (zunächst war das verwendete Protokoll nicht bekannt). Als nächstes musste das BiSecur Gateway-Gerät mit dem neuen Proxy-Host anstelle des Hörmann-Servers verbunden werden. Da der Domänenname des Servers in der Firmware des Geräts fest codiert war (was aus Sicherheitsgründen im Zuge des aktuellen Security Audits auch nicht geändert wurde) wurde versucht, die DNS-Antworten während der ersten Auflösung des Namens zu fälschen. Leider hat es nicht funktioniert. Wenn das Gerät keine IP-Adresse innerhalb des „erwarteten“ IP-Bereichs erhielt, war es in einer Endlosschleife mit demselben Domänennamen gefangen. Das war unüblich. Eine solche Einstellung ist entweder ein Schutzmechanismus oder ein Programmierfehler in der Firmware. Nach einigen Stunden war das Problem noch nicht gelöst. Zwar schienen die Erfolgsaussichten eher gering, aber es war einen Versuch wert, einen USB-Ethernet-Dongle auf dem Proxyserver einzusetzen und die IP-Adresse auf den gleichen /24-er Netzwerkbereich wie den ursprünglichen Hörmann-Server einzurichten. Überraschender Weise hat es funktioniert.
Es war also gelungen, ein MiTM zwischen dem BiSecur Gateway-Gerät und dem Hörmann-Server laufen zu lassen und es war an der Zeit, die Kommunikation zu überprüfen. Wie bereits erwähnt, verwendet das Gerät im Internet genau das gleiche Protokoll wie im lokalen Netzwerk, jedoch mit einer zusätzlichen SSL-Schicht. Mit einer passenden Kommunikationsbibliothek für dieses Protokoll könnte man als BiSecur Gateway-Gerät mit dem Remote-Server kommunizieren (ein entsprechendes SSL-Zertifikat und den richtigen privaten Schlüssel vorausgesetzt). Zunächst wollen wir uns noch den Kommunikationsablauf genauer ansehen, um eine Tür (zum Internet) zu öffnen.
Durch das Protokollieren des Datenverkehrs mit dem benutzerdefinierten TCP-Proxy und Einsatz eines Teilparsers, der aus den durch die LAN-Paketanalyse gesammelten Informationen entstand, konnten Nachrichten auf die Konsole geschrieben werden.
Die Verbindung wurde über die Smartphone-Anwendung hergestellt. Der Workflow war dabei wie folgt:
- Verbindung initiiert und erfolgreich
- Remote-Server: GET_MAC
- Client: Antwort GET_MAC mit der MAC-Adresse des Clients
- Telefonanmeldetaste gedrückt
- Remote-Server: LOGIN <unverschlüsselte Anmeldeinformationen>
- Telefon: Erfolgreiche LOGIN-Antwort im Feld TOKEN (Änderung von 0 in zufällige Zahl)
- Remote-Server: GET_INFO
- Client: GET_INFO Antwort
Hinweis: GET_MAC wird als keepalive Kommando verwendet, eine entsprechende Nachricht wird alle 30 Sekunden empfangen.
Was hier seltsam ist? Es wurde ein Client-Zertifikat verwendet, um eine starke Authentifizierung durchzuführen. Dieses Client-Zertifikat enthält die MAC-Adresse des Geräts im Attribut „Common Name“ (CN). An dieser Stelle fragen Sie sich möglicherweise, warum das BiSecur Gateway-Gerät vom Hörmann-Server aufgefordert wird, durch eine separate Anforderung in der aktuellen Sitzung die MAC-Adresse erneut anzugeben. Die erste Vermutung war, um ein Keepalive durchführen zu können (beim späteren Reverse Engineering wurde festgestellt, dass auch ein PING-Befehl verfügbar war) oder um das Gerät anhand dieser Informationen zu identifizieren.
Die (jetzt vollständige) Implementierung der Kommunikationsbibliothek konnte verwendet werden, um diese Theorie zu testen und beim Empfang einer GET_MAC-Anforderung des Servers mit einer falschen MAC-Adresse zu antworten. Leider schlug der anschließende Verbindungsversuch zum BiSecur Gateway-Gerät über ein Smartphone fehl. Um die Infrastruktur von Hörmann für weitere Tests nicht zu beschädigen, musste ein anderes BiSecur Gateway Gerät angeschafft werden. Durch die Installation des zweiten Geräts und die Kopplung mit der Smartphone-Anwendung (gemäß normaler Herangehensweise) konnte das sekundäre Gerät über den Hörmann-Server „übernommen“ werden. Ein Benutzer mit einem sicheren Kennwort auf dem zweiten Gerät des BiSecur-Gateways war schnell konfiguriert. Das virtuelle Gerät konnte mit dem SSL-Schlüssel des ersten Geräts eine Verbindung zum Remote-Server herstellen, hatte jedoch die MAC-Adresse des zweiten Geräts in die GET_MAC-Anforderung eingefügt. Durch Anmeldung über die Schaltfläche der Smartphone-App erhielt das virtuelle Gerät die geheimen Anmeldeinformationen, die eigentlich für das reale zweite Gerät bestimmt waren. Dies bestätigte schließlich die Annahme, dass der virtuelle Client alle Anmeldeinformationen aller Clientgeräte abrufen konnte, die über das Internet mit dem Remote-Hörmann-Server verbunden waren – indem die MAC-Adresse nach der Verbindung gefälscht wurde.
Später stellte sich heraus, dass der Ethernet-Controller-Chip auch von Microchip stammt und in allen Geräten des BiSecur-Gateways verwendet wird. Dies reduziert den Platzbedarf enorm, der zum Auflisten möglicher MAC-Adressen erforderlich ist. Durch eine weitere Schwachstelle könnten außerdem die genauen MAC-Adressen des gesamten Ökosystems zugeordnet werden. Dazu später.
6. WLAN
Die WLAN-Sicherheit des Geräts war nicht Bestandteil des vorliegenden Research-Projekts.
7. HANDY APP
Das BiSecur-Gateway-Produkt kann verwendet und gesteuert werden, indem die entsprechende Anwendung auf Ihr Smartphone heruntergeladen wird, die sowohl für Android als auch iOS verfügbar ist.
7.1. Android Applikation
Es kostete oft viel Zeit, die Dex-Datei der offiziellen APK-Datei zu dekompilieren und die enthaltenen Android-Binärbibliotheken zu überprüfen. Schnell wurde klar, dass dieser Schritt gar nicht nötig war, weil alle Bibliotheken und Klassen nur eine Funktion hatten: eine Flash-Umgebung einzurichten und eine im Ressourcenordner gebündelte SWF-Datei auszuführen.
Nach dem Dekompilieren der SWF-Datei und entsprechendem Code-Review, konnte verifiziert werden, dass die gebündelte SWF-Datei die tatsächlich verwendete Anwendung und nicht nur eine andere virtuelle Umgebung war. Außerdem schienen die Ressourcen in der SWF-Datei einen gewissen „erweiterten Hardcore“-Schutz gegen Reverse Engineering zu enthalten. Aber machen Sie sich selbst ein Bild der Schutzdatei (zu finden im Ordner „Assets“ der apk):
Es schien sich um den Quellcode des Binärprotokolls zu handeln, das für die Kommunikation notwendig ist. Enthalten waren aber nicht nur die Datenstrukturen, sondern auch der verwendete CRC-Algorithmus und die Liste aller verfügbaren Befehle. Mit diesen Informationen war es möglich, eine vollständige Kommunikationsbibliothek namens pysecur3 zu erstellen.
7.2. iOS Applikation
Ein Test der iOS-App war nicht Teil dieses Schwachstellen-Research.
8. Zusammenfassung
Das getestete Gerät (genau wie viele andere IoT-Geräte) würde eine vollständige Neugestaltung auf allen Ebenen, einschließlich Hardware, Protokoll und Back-End-Infrastruktur, benötigen.
Hörmann wurde von SEC Consult über die potenziellen Sicherheitsrisiken des BiSecur-Gateways informiert und reagierte umgehend. Die Registrierungsoption auf dem offiziellen BiSecur-Portal wurde unverzüglich deaktiviert und die Produktion von BiSecur-Gateways vorübergehend eingestellt. Die Produktentwickler haben dem Test der genannten Sicherheitslücken höchste Priorität eingeräumt und sich sofort um die Beseitigung aller relevanten Sicherheitsrisiken gekümmert.
9. Über den Autor
Tamas Jos ist Senior Security Consultant bei der SEC Consult (Schweiz) AG.
Er ist insbesondere auf Hardware-Reverse Engineering spezialisiert.
10. Herstellerinformation
(Auszug)
Der Algorithmus des Prüfcodes zur Registrierung des BiSecur-Gateways wurde unverzüglich nach Benachrichtigung durch SEC Consult angepasst. Der Bestätigungscode ist länger, kryptischer und enthält zufällige Werte.
Alle Kunden, die ein Gateway vor Bekanntwerden der Sicherheitsrisiken über das Portal registriert hatten, wurden darüber informiert. In Übereinstimmung mit den erforderlichen Sicherheitsanforderungen wurde ein neuer Bestätigungscode per Post gesendet.
Die Passwortspezifikation in der BiSecur-App wurde aktualisiert. Es ist nun ein 10-stelliges Passwort mit Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen erforderlich.
Zusätzlich wurde die Software des BiSecur-Gateways um einen Ausleseschutz erweitert.
Hörmann arbeitet ständig daran, die Qualität und Sicherheit aller Produkte zu optimieren. Die Erkennung potenzieller Schwachstellen durch SEC Consult erwies sich als hilfreich, um das gesamte BiSecur-System weiter zu verbessern.