Digital Lockpicking – wenn smarte Schlösser jeden rein lassen (könnten)

„Wann immer ein Gerät als ‚smart‘ bezeichnet wird, ist es verwundbar.“ – dieses Zitat von 2016 stammt aus dem Mund von Mikko Hyppönen, Chief Research Officer bei F-Secure, das sich inzwischen als „Hyppönens Gesetz“ etabliert ist. Und in der Tat: einmal mehr haben unsere Kollegen bewiesen, dass sogar mit recht einfachen Mitteln smarte Geräte gehackt werden können. In diesem speziellen Fall handelt es sich um das smarte Türschloss des koreanischen Herstellers KeyWe.

Krzysztof Marciniak, einer der Cyber-Security-Berater von F-Secure, die den Hack durchführten, hat auf dem F-Secure Labs Blog beschrieben, wie er und sein Team den Hack durchgeführt haben. Im Folgenden finden Sie die deutsche Übersetzung des Beitrags:

Einführung

Smarte Geräte sind hip und lassen sich gut verkaufen. Daher werfen viele Unternehmen ständig neue smarte Geräte in so hoher Geschwindigkeit auf den Markt, dass die Sicherheit nur eine untergeordnete Rolle spielen kann. Das KeyWe Smart Lock ist ein solch neues smartes Produkt. Um das Leben komfortabler zu gestalten, wurde es so konzipiert, dass es sowohl über einen mechanischen als auch einen elektronisch steuerbaren Verriegelungsmechanismus verfügt. Das ermöglicht weitere Funktionalitäten. Dazu gehören unter anderem das Generieren von einmaligen Gästecodes, das Entriegeln der Tür aufgrund eines Gerätes in der Nähe usw. Die Bequemlichkeit geht allerdings immer zu Lasten der Sicherheit.

Geräteübersicht

Das Schloss KeyWe Smart Lock besteht aus drei wesentlichen Teilen:

• die Frontplatte – sie dient zur Interaktion mit dem Schloss
• das mechanische Schloss – es wird sowohl von der Software als auch als eigenständiges Gerät verwendet
• die Rückwand – sie dient zur Stromversorgung und Bewegung des mechanischen Teils des Schlosses

Frontplatte und Rückwand sind elektronisch miteinander verbunden. Sollte jemand versuchen die Verbindung gewaltsam zu trennen, wird ein Alarm ausgelöst.

Das Schloss lässt sich auf verschiedene Arten normal öffnen:

• mechanisch – mit einem Schlüssel
• Verwendung der App auf einem mobilen Gerät (keine zusätzliche Bestätigung erforderlich)
• mit einem Transponder-Armband (NFC – Mifare Classic)

Hardware sperren

Zerlegt man das Schloss in Front- und Rückenplatte, zeigt deren visuelle Überprüfung – ohne die Komponenten zu identifizieren –deutlich den Zweck der einzelnen Komponenten.

Abbildung 1 – KeyWe – Boards

Abbildung 2 KeyWe – Board (Rückseite)

Die vordere Platte wird nur für Benutzereingaben verwendet (numerische Tastatur und RFID-Chip). Auf der hinteren Platte, auf die der Angreifer nicht zugreifen kann, wir die gesamte Anwendungslogik gesteuert. Serielle und JTAG-Zugriffsversuche auf die Steuerung führten zu keinen Ergebnissen. Eine Komponentenidentifikation zeigte jedoch, dass ein STM-Mikrocontroller verwendet wird. An einem der freigelegten SWIM-Ports (Single-Wire-Schnittstellenmodul) schien ein verwendetes Debug-Protokoll aktiviert zu bleiben. Nach dem Anlöten des Pins und Verwendung eines ST-LINK-Adapters konnte die Gerätefirmware gesichert werden.

Die folgende Liste nennt einige der verbauten, identifizierten Komponenten – sie ist aber nicht vollständig.

Untersuchung der Brücke

Mit Hilfe eines Brückenbauteils soll die Schloss-Sperre via WiFi aufgehoben werden. Das Ganze wird per Bluetooth Low Energy abgewickelt. Obwohl es äußerlich ziemlich raffiniert ist, enthält es innen ein einfaches ESP32-basiertes Board. Der interessante Teil des Boards sind die Stifte, die sich auf der weißen Tafel befinden.

Abbildung 3 – Übersicht der Tafel

Nach einiger Zeit mit einem Multimeter und einem Pin-Belegungsdiagramm konnten fast alle Pins identifiziert werden:

Abbildung 4 – Foto der Pinbelegung

Obwohl ESP ziemlich ausgereift ist (mit Leseschutz, Verschlüsselung usw.), werden solche Funktionen vom Brückenbauteil nicht genutzt. Der serielle und der JTAG-Zugriff bleiben aktiviert und es wird keine Verschlüsselung verwendet. Dies kann mit der folgenden Ausgabe bestätigt werden:

$ espefuse -p /dev/ttyACM0 summary
espefuse.py v2.5.1
Connecting....
Security fuses:
FLASH_CRYPT_CNT Flash encryption mode counter = 0 R/W (0x0)
FLASH_CRYPT_CONFIG Flash encryption config (key tweak bits) = 0 R/W (0x0)
[...]
JTAG_DISABLE Disable JTAG = 0 R/W (0x0)
[...]
Efuse fuses:
WR_DIS Efuse write disable mask = 0 R/W (0x0)
RD_DIS Efuse read disablemask = 0 R/W (0x0)

Angesichts der Einfachheit des Zugriffs auf die Firmware wurde der Bridge seit der Analyse keine weitere Aufmerksamkeit geschenkt.

Bluetooth Low Energy

Lassen Sie uns eine Stufe höher gehen, natürlich im übertragenen Sinne. Wir gehen jetzt auf die Kommunikations- und Anwendungsebene. Basierend auf öffentlich verfügbaren Materialien (sowie der Verpackung, mit der das Schloss geliefert wurde) wissen wir, dass „Bluetooth Smart“ verwendet wird. Für diejenigen, die es nicht wissen: dies ist nur ein anderer Name für BLE / BTLE – Bluetooth Low Energy.

Das wahrscheinlich bequemste Werkzeug (nach unserer Meinung) für die BLE-Inspektion ist nRF Connect von Nordic Semiconductors. Bevor wir fortfahren, möchten wir noch einige grundlegende Konzepte von Bluetooth Low Energy in einer kurzen Zusammenfassung erläutern:

Im Gegensatz zu Bluetooth Classic (eine Technologie, die wir alle kennen und oft nutzen) gibt es bei BLE kein Konzept für erkennbare Geräte. Jedes Gerät bzw. Peripheriegerät sendet eine Nachrichten (so genannte Advertising-Events) an alle Personen, die nah genug sind, um sie zu empfangen. Ein solches Event bzw. eine Nachricht enthält Informationen über das Peripheriegerät, wie seinen Namen, seine Adresse (die zum Herstellen einer Verbindung verwendet wird), Funktionen usw. Ein solches Gerät zeigt eine Liste gruppierter Objekte an, die als Dienste bezeichnet werden und Merkmale enthalten. Ein Merkmal kann einen Wert (Text, Nummer usw.) enthalten, der entweder gelesen (Lesezugriff), aktualisiert (Schreibzugriff) oder der anderen verbundenen Partei mitteilt, dass sich der Wert geändert hat (Benachrichtigungszugriff).

Die KeyWe-Sperre offenbart einen einzelnen Dienst mit zwei Merkmalen: mit dem Typ read und mit dem Typ notifiy:

Abbildung 5 – nRF Connect: KeyWe

Wir können bereits jetzt davon ausgehen, dass sie zum Senden bzw. Empfangen von Nachrichten zum und vom Schloss verwendet werden. Um dies zu überprüfen, inspizieren wir die mobile Anwendung. In diesem Fall aber nur die Android-App.

Knacken der Software

Auf der Suche nach BLE-bezogenen Funktionen stoßen wir auf die DoorLockNdk-Klasse, die mehrere Methoden enthält. Für diejenigen, die mit Android nicht vertraut sind, steht NDK für Native Development Kit, eine Möglichkeit, nativen (kompilierten, nicht verwalteten) Code mit Java zu verbinden (mithilfe der Java Native Interface, JNI).

Jede der oben genannten Methoden gibt ein Array von Bytes zurück – Bingo! Das war die Goldmine in Sachen Informationen. Denn normalerweise: Wenn wir die Botschaften irgendwie abfangen würden, wäre das umsonst. Jede Nachricht wird vor dem Senden mit AES-128 verschlüsselt. Wenn wir jedoch Zugriff auf diese Klasse haben, können wir Nachrichten schon vor der Verschlüsselung abfangen. Auf diese Weise kann das Kommunikationsprotokoll ausgelesen und analysiert werden. Wie fangen wir aber die Funktionsaufrufe ab? Die Antwort ist ziemlich einfach: mit dem Tool Frida! Wenn Sie die technischen Details hier überspringen (hier erfahren Sie mehr über das Einbinden von Funktionen in Frida), erstellen wir Funktionen, die Argumente sichern und Werte zurückgeben. Den Code finden Sie hier im GitHub-Repository.

Hier ein Protokoll der Nachrichten, die zwischen der Sperre und der mobilen Anwendung ausgetauscht werden – basierend auf den mit Frida erhaltenen Informationen:

Einige Funktionen, die eine besondere Erwähnung verdienen, sind: makeCommonKey, makeAppKey und makeDoorKey. Diese werden entweder innerhalb der Anwendung oder auf der Sperre aufgerufen, führen jedoch nicht direkt zu gesendeten Nachrichten.

Noch als Hinweis: die Funktionen makeAppNumber und makeDoorNumber werden verwendet, um Werte zu generieren, die zwischen den beiden Parteien ausgetauscht werden. Dies dient als einfaches „Schlüsselaustausch“-Protokoll. Dabei generiert jede Seite einen Wert, sendet ihn an das Gegenstück und sobald die andere „Nummer“ empfangen wurde, kann das Schlüsselpaar berechnet werden. Ein Schlüssel wird zum Ver- bzw. Entschlüsseln von Nachrichten verwendet, die von der Sperre (makeDoorKey) stammen, und der andere für das mobile Gerät (makeAppKey). Jede dieser Nummern wird vor dem Senden mit dem gemeinsamen Schlüssel dann verschlüsselt.

Hier eine Liste beispielhafter Aufrufergebnisse für makeCommonKey (allgemeine Schlüsselwerte):

Mit Exec. id wird angegeben, welche Ausführung (erste, zweite usw.) für ein bestimmtes Gerät ausgeführt wurde

Wie man erkennen kann, ändert sich der gemeinsame Schlüssel nicht zwischen den Ausführungen, sondern nur mit der Geräteadresse. Das ist ein schwerer Fehler! Da ein interner Schlüsselaustausch mit nur zwei beteiligten Werten zum Entschlüsseln der gesamten Kommunikation verwendet wird, muss lediglich die Übertragung abgefangen werden. Den gemeinsamen Schlüssel kann man dann einfach anhand der Geräteadresse berechnen.

Das klingt zu einfach? Ist es in der Tat auch teilweise. Dazu muss man auch wissen, wie genau die Schlüssel berechnet werden. Außerdem muss man etwas tiefer im Code wühlen, was wir hier aber nicht vereinzelt vorstellen wollen. Der Code für die Berechnung wurde jedoch auch im oben genannten Repository veröffentlicht. Allerdings wurden dabei aus verständlichen Gründen einige Schlüsselteile entfernt.

Somit wurde aus dem KeyWe Smart Lock ein smarter Türöffner für absolut Jedermann.

Den Traffic sniffen

Im Puzzle fehlt noch ein Teil. Wie bekommen wir tatsächlich die Nachrichten, die zwischen dem Schloss und der Handy-App ausgetauscht werden? Reguläre Anwendungen/Adapter haben eine solche Funktionalität nicht. Glücklicherweise gibt es dafür sowohl Hardware als auch Firmware. Um Bluetooth LE-Verkehr zu sniffen, kann man den hier verfügbaren nRF Sniffer verwenden. Mit einem Board wie Waveshare BLE400 oder USB Armory Mk II (da es über einen nRF-basierten Bluetooth SoC verfügt) ist das Sammeln von LE-Daten so einfach wie das Ausführen von Wireshark mit einem installierten Plugin.

Die Antwort des Herstellers

Der Hersteller hat das Problem erkannt und arbeitet daran, es zu beheben. Seit der Offenlegung des Problems hat sich der Anbieter aktiv an der Kommunikation beteiligt. Leider wurde bis dato keine Funktion zur Firmware-Aktualisierung hinzugefügt und somit bleibt das Problem bestehen, bis das Gerät durch einen Nachfolger ersetzt wird. Davon abgesehen sollten die neuen Geräte auch die Möglichkeit eines Sicherheitsupdates enthalten. Laut Hersteller soll die nächste Version des Schlosses die fehlende Firmware-Upgrade-Funktion haben. Allerdings gibt es noch keine Informationen dazu, wann das Gerät verfügbar sein wird.

Schlussfolgerungen

Man kann nicht sagen, dass der Hersteller des KeyWe Smart Lock der Sicherheit keine Aufmerksamkeit geschenkt hat. Der verwendete AES-Algorithmus ist der De-facto-Standard für die Kryptographie. Das verwendete Protokoll allerdings kann als Eigenbau-Krypto bezeichnet werden. Aber wie die Branche im Laufe der Jahre gezeigt hat, enden diese Basteleien nie gut. Darüber hinaus scheint der Herseller nur eine vage Vorstellung vom Bedrohungsmodell zu haben. Auch sollten die Entwickler bzw. Architekten wissen, dass die Geräteadresse für alle Personen in der Nähe des Schlosses verfügbar ist. Das ist bei der Entwicklung des neuen Schloss-Modells hilfreich.

Die gewonnenen Erkenntnisse und die Empfehlungen für jedes Unternehmen, das mit intelligenten, potenziellen IoT-Geräten zu tun hat:

• Hersteller sollten das Bedrohungsmodell verstehen
• Hersteller sollten keine „interne“ Eigenbau-Krypto nutzen
• Entwickler sollten ihre Werkzeuge kennen und benutzen – sie können so eine Menge Zeit sparen
• Hersteller sollten ihre scheinbar sicheren Geräte einer eingehenden Analyse unterziehen und lernen, wie man Muster in Daten erkennt