Hardware und Firmware im Fokus:

Bei der Sicherheitsanalyse von IoT-Geräten lohnt sich oft ein genauerer Blick auf die Hardware. In diesem Blogpost nehmen wir die serielle UART-Schnittstelle der IoT-Kamera unter die Lupe. Ziel ist es, herauszufinden, welche Informationen sich über diese Schnittstelle auslesen lassen und ob sich darüber eventuell ein tieferer Zugriff auf das System erlangen lässt.

Untersuchung der UART-Schnittstelle

Bereits bei der ersten visuellen Untersuchung der Hardware wurden drei nebeneinanderliegende Pins identifiziert:

Da sich die drei Pins in unmittelbarer Nähe zum Mikrocontroller befinden, liegt der Verdacht nahe, dass es sich hierbei um eine UART-Schnittstelle handelt. UART (Universal Asynchronous Receiver / Transmitter) nutzt in der Regel zwei Datenleitungen – Tx (Transmit) und Rx (Receive) – sowie einen GND-Pin (Ground). In manchen Fällen existiert ein vierter Pin zur Spannungsversorgung (typischerweise 3.3 V oder 5 V).

Um die Funktion der einzelnen Pins zu bestimmen – also GND, Tx und Rx – gibt es mehrere Möglichkeiten. Entweder automatisiert (zum Beispiel mit einem Logic Analyzer) oder manuell mit einem Multimeter. In allen Fällen muss jedoch zumindest GND identifiziert werden.
Zur Identifizierung kann eine einfache Durchgangsprüfung mit einem Multimeter durchgeführt werden. Dabei wird eine Messspitze an den zu testenden Pin und die andere an einen bekannten Massepunkt (z. B. Kontakte um die Schrauben) gehalten. Das Multimeter gibt einen Piepton von sich, damit besteht eine direkte Verbindung – der Pin ist also GND.

Die beiden anderen Pins können identifiziert werden, indem die Spannung beim Booten der Kamera beobachtet wird. Kommt es während des Bootvorgangs in den ersten 10-15 Sekunden zu einer starken Spannungsschwankung, ist dies der Tx-Pin. Ist die Spannung aber relativ niedrig, so ist dies der Rx-Pin.
Mit dieser Methode konnte das folgende Pin-Layout identifiziert werden:

Zur weiteren Analyse wird an jeden Pin ein Kabel angelötet. Zur interaktiven Kommunikation kann ein einfaches TTL-232R-3v3-Kabel (https://ftdichip.com/products/ttl-232r-3v3/) genutzt werden.

Die Standardkonfiguration bei vielen Geräten ist eine Baudrate von 9600 oder 115200, 8 Datenbits, aktivem Stopp-Bit, keine Datenflusssteuerung (Flow Control) und kein Paritätsbit (Parity Bit).

Zur Kommunikation kann zum Beispiel Screen (https://linux.die.net/man/1/screen) genutzt werden:

screen /dev/ttyUSB0 115200

Bingo! Der Bootvorgang wird vollständig durchlaufen und die Ausgabe erscheint in der Konsole.
Bei genauer Beobachtung der U-Boot-Ausgabe ist ersichtlich, dass die Variable bootdelay auf 0 gesetzt ist. Entwickler gehen häufig davon aus, dass dadurch ein Anhalten des Bootvorgangs nicht mehr möglich ist. Das ist jedoch ein Trugschluss: Selbst bei bootdelay=0 prüft U-Boot beim Start weiterhin, ob die Tastenkombination CTRL-C gedrückt wird (siehe: U-Boot Dokumentation – Environment Variables).

Das bedeutet, dass der Bootprozess auch in diesem Fall manuell gestoppt werden kann – sofern im richtigen Moment die entsprechende Tastenkombination gedrückt wird.

Der Bootprozess ist unterbrochen und verschiedene U-Boot-Befehle können verwendet werden - z.B. version (Ausgabe der U-Boot Version) und printenv (Ausgabe der Umgebungs-/Bootvariablen).

Ohne den zuvor erlangten Zugriff auf die Firmware (siehe [Blogpost]) hätte sich auch die U-Boot-Shell nutzen lassen, um direkt mit dem Speicher zu interagieren und die Firmware zu extrahieren.
Der Versuch, die Bootargumente so zu ändern, dass eine unauthentifizierte System-Shell aufgerufen wird, schlug jedoch fehl. Das Ändern der Bootargumente führte sogar dazu, dass das Gerät nicht mehr startete. Erst durch erneutes Flashen der Original-Firmware mittels In-Circuit Programmer konnte die Kamera wieder in Betrieb genommen werden.
Auch das Ändern des Root-Passworts über diverse Methoden (z. B. Aufruf von passwd in HOOK.sh) schlug fehl – letztendlich, weil das setuid-Bit beim passwd-Binary nicht gesetzt wurde. Zudem ist das Dateisystem nur als read-only gemounted, wodurch keine Änderungen vorgenommen werden können.

Durch den Zugriff auf die Firmware (siehe [Blogeintrag]) konnte in der /etc/init.sh folgende Abfrage identifiziert werden:

Die Ausgabe der Logs über die Konsole, kann also aktiviert werden, wenn eine Datei mit dem Namen CONSOLE.ON auf der SD-Karte abgelegt wird.
Die Ausgaben enthalten dann eine Vielzahl an nützlichen Informationen, wie zum Beispiel die einzelnen Partitionen im Speicher (MTD partitions):

Dies bestätigt größtenteils auch die von binwalk identifizierten Speicherbereiche:

Lediglich die uinit-, uid- und data-Partitionen wurden von binwalk nicht korrekt erkannt.
Aus dem Firmware-Dump lassen sich diese jedoch manuell mittels dd extrahieren.
Hier als Beispiel für die data-Partition:

dd if=FM25Q128A.BIN of=data bs=1 skip=$((0xF80000)) count=$((0x1000000-0xF80000))

Mit dem Linux-Tool file kann anschließend bestätigt werden, dass es sich um ein jffs2 Dateisystem handelt, welches mit jefferson (https://github.com/sviehb/jefferson) entpackt werden kann:

Mit Hilfe der Konsolenausgabe konnte so die vollständige Firmware aus dem Flash-Dump rekonstruiert werden.
Die Konsole zeigt nun auch eine Anmeldeaufforderung an. Da es jedoch nicht gelungen ist, das Passwort des root-Benutzers zu knacken, und Änderungen an der Bootloaderkonfiguration zu einem fehlerhaften Bootvorgang führten, ist ein Zugriff auf das Gerät zumindest über die UART-Schnittstelle nicht möglich.

Die Firmware wurde abschließend mit dem Tool EMBA (https://github.com/e-m-b-a/emba) analysiert. Dabei wurden Hinweise auf weitere Schwachstellen in veralteter Software identifiziert.
Der Großteil der Schwachstellen finden sich im veralteten Linux Kernel. Für einige sind Exploits vorhanden.

Zusammenfassung

In unserer Blogpostreihe haben wir gezeigt, wie leicht sich bei unzureichend geschützten IoT-Geräten tiefgreifende Informationen gewinnen lassen. Ein zentrales Ergebnis war die vollständige Wiederherstellung der Firmware aus dem ausgelesenen Flash-Speicher. Damit konnten nicht nur Einblicke in die Funktionsweise des Geräts gewonnen werden, sondern auch Sicherheitslücken identifiziert werden, mittels derer das Gerät vollständig übernommen werden konnte.

Ein vollständiger Zugriff auf die Kamera bedeutet nicht nur, dass sensible Benutzerdaten, darunter die WLAN-Zugangsdaten sowie der in der App verwendete Benutzername bzw. die zugehörige E-Mail-Adresse, ausgelesen werden können. Durch diese Sicherheitslücke könnten Angreifer zudem auf zentrale Funktionen der Kamera zugreifen – etwa auf den Live-Stream der Kamera, das Mikrofon oder die Gegensprechfunktion. Damit wird aus einer einfachen Kamera schnell ein Einfallstor in das gesamte Heimnetzwerk, wodurch nicht nur das Gerät selbst, sondern potenziell auch weitere Systeme im Heimnetzwerk angreifbar wären.

Solche Schwachstellen werfen grundlegende Sicherheitsbedenken im Umgang mit vernetzten Geräten auf – insbesondere, wenn sie keine wirksamen Schutzmechanismen gegen unautorisierten Zugriff bieten. In realen Szenarien könnten Angreifer so nicht nur Privatsphäre und Daten gefährden, sondern auch Angriffe auf andere Geräte im selben Netzwerk vorbereiten.

In einer tiefergehenden Firmwareanalyse könnten nun weitere sensible Informationen sowie Schwachstellen in der Software identifiziert werden – etwa laufende Dienste, unsichere Update-Mechanismen oder Konfigurationsfehler. Auch die Kommunikation zwischen der Kamera, der zugehörigen Cloud-Infrastruktur und der mobilen App wären üblicherweise Teil eines umfassenden IoT-Pentests.

Da der Schwerpunkt dieser Analyse jedoch auf der Hardware lag und weiterführende Tests eine direkte Untersuchung der Systeme des Herstellers vorausgesetzt hätten, wurde in diesem Fall bewusst darauf verzichtet.