Suche nach Schwachstellen in IoT-Geräten am Beispiel CVE-2022-46527 (Teil 1)

Die Nutzung von vernetzten Objekten ist immer weiter verbreitet, sei es für private Anwendungen, z. B. im Smart Home, oder in Unternehmen, z. B. zum Lkw-Tracking. Da sie vernetzt sind, können diese Geräte Risiken für ihre Nutzer darstellen.

Das COS-Team führte mehrere Prüfungen durch, um potenzielle Schwachstellen dieser Art von Geräten zu identifizieren und so die Sicherheit der Kunden zu gewährleisten. Dieser Artikel, der erste einer neuen Serie, behandelt die Entdeckung eines Zero-Days auf einem dieser Geräte. Die Untersuchung dieses Falls besteht aus zwei Teilen. Der erste Teil erläutert die Einrichtung der Umgebung zur Analyse des Geräts und der zweite Teil schildert die Entdeckung von CVE-2022-46527. Details dazu sind derzeit noch unter Verschluss.

Wie setzt sich ein vernetztes Objekt zusammen?
Vernetzte Objekte können für verschiedene Zwecke verwendet werden, von der Erfassung von Informationen wie Messung der Temperatur oder Ermittlung eines Standorts bis hin zu Umweltschutzmaßnahmen wie der Beleuchtungsregelung. Ein vernetztes Objekt besteht aus mehreren Teilen:

• Versorgung
• Netzwerkteil
• Controller
• Sensor/Aktor

Die verschiedenen Arten von Controllern

Es gibt hauptsächlich zwei Arten von Controllern:

• Mikrocontroller (MCU)
• Mikroprozessoren (MPU)

Abbildung 1: Unterschied zwischen MCU und MPU

Die MCUs sind am umfangreichsten, da sie alles Wesentliche enthalten, um zu funktionieren: einen Prozessor (CPU), flüchtigen Speicher (RAM) und nichtflüchtigen Speicher (ROM). Ihre Integration ist einfacher, ihr Stromverbrauch und ihre Betriebsgeschwindigkeit geringer. Außerdem haben MCUs wenig RAM und ROM, sodass sie sich eher für den einfachen Gebrauch eignen. Diese Art von Controller wird häufig bei vernetzten Objekten verwendet, die einfache Messungen vornehmen und über mehrere Jahre hinweg eingesetzt werden, ohne dass die Batterie ausgetauscht werden muss.
Für eine intensivere Nutzung, beispielsweise Bildverarbeitungsgeräte, werden MPUs verwendet, aber ihre Integration ist komplexer, da ROM und RAM zusätzlich zum MPU separat auf der elektronischen Schaltung integriert werden müssen. Diese Art von Controller verbraucht zwar mehr Strom, kann dank seiner höheren Betriebsgeschwindigkeit und mehr ROM und RAM komplexere Aufgaben bewältigen.

Entdeckung des vernetzten Zielobjekts

Das vernetzte Objekt erfasst Daten zu mehreren Faktoren: Geräuschpegel, Temperatur, Luftfeuchtigkeit, Helligkeit und Anwesenheit. Die Produktreferenz wurde noch nicht veröffentlicht, da derzeit ein Responsible-Disclosure-Verfahren läuft.
 

Abbildung 2: Komponenten auf der elektronischen Karte

Die Schaltung besteht aus einem STM32L151CC-MCU, einem LoRaWAN-Modem und einem NFC-Tag des Herstellers STMicroelectronics. Bei dem NFC-Tag befindet sich die Referenz Tests zufolge nicht auf seiner freiliegenden Seite. Die Pinbelegung scheint der ST25-Reihe des Herstellers zu entsprechen.
Durch die Referenz dieses MCUs erfahren wir, dass die Prozessorarchitektur ARM ist, was uns die Analyse der Firmware erleichtert.

Wiederherstellung der Firmware

Da es sich um einen Mikrocontroller (MCU) handelt, ist der Inhalt des internen Flash-Speichers jedoch nicht direkt zugänglich, während bei MPUs der Flash-Speicher eine separate Einheit ist.

Es gibt mehrere Möglichkeiten, die vom vernetzten Objekt verwendete Firmware wiederherzustellen. Die Mikrocontroller von STM haben einen Debug-Modus, der mit einem ST-Link-Adapter genutzt werden kann. Außerdem gibt es verschiedene Bootloader, mit denen die im internen Flash-Speicher gespeicherte Firmware heruntergeladen werden kann. Zum Beispiel gibt es den Befehl „DFU_UPLOAD“ des Bootloaders per USB DFU.

Um ihre Geräte und ihr geistiges Eigentum zu schützen, können die Hersteller jedoch den Leseschutz für den Flash-Speicher aktivieren, den Debug-Modus deaktivieren und den Bootloader auf externen Schnittstellen ausschalten.

Im Fall der untersuchten Geräte scheint der Debug-Modus deaktiviert zu sein.
 

Abbildung 3: Debugging-Versuch unter Verwendung des ST-Links

Es wurde ein Logikanalysator von Saleae verwendet, um den Datenverkehr zwischen dem Gerät und der Debug-Schnittstelle zu verfolgen.

rotz der Versuche über die Debug-Schnittstelle kommt keine Antwort vom Mikrocontroller.

Abbildung 4: Verwendung eines Logikanalysators zur Überwachung des Datenverkehrs zwischen dem ST-Link und dem Mikrocontroller

Außerdem sind die Pins zur Auswahl des Bootmodus gesperrt. Die Firmware direkt vom vernetzten Objekt abzurufen, ist mit den zur Verfügung stehenden Mitteln nicht möglich.

Der Hersteller bietet die Firmware auf seiner Website sowie einen Adapter für Aktualisierungen an. Bei dieser Untersuchung wurde die Firmware verwendet, die auf der Website des Herstellers verfügbar ist.

Nachdem die Firmware heruntergeladen wurde, kann sie in einen Disassembler geladen werden, wenn man die verwendete Architektur kennt.

Hier wurde Ghidra verwendet, um die Firmware zu analysieren.
 

Abbildung 5: Verwendung von Ghidra zur Firmware-Analyse

Bei der Analyse der Firmware können riskante Funktionen entdeckt werden. Vor einer Vertiefung der Analyse der Firmware kann man mittels Untersuchung der verschiedenen Kommunikationskanäle und ihrer Funktionsweise die Suche nach Schwachstellen besser auf die Funktionen ausrichten, die beim Datenaustausch mit der Außenwelt verwendet werden.

Kommunikationskanäle

Das Gerät lässt sich mithilfe einer Android-App einrichten. Die App sendet eine Nachricht im NDEF-Format in das NFC-Tag. Das NFC-Tag speichert die Nachricht in seinem Speicher. Diese Nachricht enthält in jeder Zeile einen Schlüssel und seinen Wert.
 

Abbildung 6: Auszug aus einer Ndef-Nachricht

Der MCU ruft die Daten, die im NFC-Tag enthalten sind, über eine I2C-Schnittstelle ab.

 Abbildung 7: Abhören des Austauschs zwischen dem NFC-Tag und dem MCU

Nach der Analyse nimmt der MCU die im NFC-Tag enthaltene Konfiguration und fügt sie in die Gesamtkonfiguration ein. In bestimmten Fällen ist die Konfiguration jedoch durch eine PIN geschützt. Nur der Schlüssel „pin“ wird berücksichtigt, um die Konfiguration zu entsperren und eine Kopie im NFC-Tag zu erhalten.
Ein weiterer Kommunikationskanal ist die Schnittstelle zwischen dem MCU und dem LoRaWAN-Modem.

Und dann?

In diesem ersten Teil haben wir das Gerät kennengelernt, das auf Schwachstellen untersucht wird. Der Debug- und Programmiermodus des Geräts scheint jedoch nicht aktiviert zu sein. Die Prozessorarchitektur ist ARM und es liegt eine ähnliche Firmware-Version vor wie die, die von den Geräten verwendet wird.
Als nächstes werden die verschiedenen Teile des Codes, die in den verschiedenen Kommunikationskanälen verwendet werden, auf Schwachstellen hin untersucht.