Obwohl es viele altruistische Gründe gibt, einen Job in der Cybersicherheit auszuführen, war der Grund, der mich ursprünglich dazu getrieben hat, ein „Hacker“ zu werden, dass es einfach verdammt cool klingt. So ist es auch dieses Mal wieder gewesen, als ich mich dem Thema des Hardware Hackings zugewandt habe. Aber genauso wie in der Cybersicherheit habe ich neben der „Coolness“ des Themas auch hier eine ganz neue Welt entdeckt, durch die man vieles aus einer anderen Perspektive sieht. Meine ersten Schritte, Versuche und Fehlschläge in diesem Thema möchte ich in diesem Blogbeitrag teilen. Vorab sei natürlich erwähnt, dass andere Analysten in unserer Firma deutlich tiefer in diesem Thema stecken. Von unserem Vertrieb werden sie immer liebevoll als „die Lötfraktion“ bezeichnet. Vielen Dank auch an dieser Stelle für die Hilfe beim Lernen dieses Themas.

Dieser Blogbeitrag spiegelt meine Erfahrungen mit dem Lernen des Themas Hardware Security wieder und dient hoffentlich dazu andere für dieses spannende Thema zu begeistern. Am Anfang befindet sich ein OSINT Teil, da ich mich in diesem Thema zu Hause fühle konnte ich es nicht lassen meine OSINT-Erkenntnisse bei der Auswahl einer Hardware aufzuschreiben. Weiter unten folgt dann der Teil, in dem es an das Zerlegen der Hardware geht.

Der Anfang

Wie bei vielem, was man heute lernen möchte, begann auch dieses Abenteuer mit einer Google-Suche. Dabei stößt man recht schnell auf ein Übungsziel, mit dem die meisten Hacker ihren Einstieg wagen: der TP-Link WR841N Router. Für etwas über 15 €, seit Jahren verfügbar und mit entsprechend vielen Tutorials für allen möglichen Schabernack ist er das perfekte Ziel. So wird er auch im ebenfalls erschwinglichen und sehr guten Kurs zum Thema „IoT and Hardware Hacking“ von TCM Academy verwendet. Diesen Kurs kann ich jedem, der sich für das Thema interessiert, wärmstens empfehlen. Er behandelt Grundlagen der IoT und Elektrotechnik und gibt einen guten Überblick über Themen wie Debugging, Schnittstellen, Firmware extrahieren und analysieren und Reverse Engineering. So schafft man es, als Anfänger wirklich schnell mit den Grundlagen des Themas vertraut zu werden.

Stützräder ab

Nach Beenden des Hardware Hacking Kurses wollte ich natürlich sofort mehr, also habe ich mich auf die Suche nach einem echten Ziel gemacht. Dabei musste ich natürlich ein Ziel finden, das interessante Angriffsfläche bietet, aber auch nicht zu schwer zu knacken ist. Der Traum ist hierbei, dass die Entwickler bei der Produktion des Boards zu faul waren, die Debugging-Anschlüsse des Boards zu entfernen, sodass wir als Angreifer eine Shell erhalten (mit der Software des Gerätes interagieren) können. Aber wie findet man so etwas raus, ohne das Gerät zu kaufen?

Vertrautes Terrain

Glücklicherweise sind alle Hersteller, die ein Gerät in den USA verkaufen wollen, das in irgendeiner Art und Weise „funken kann“ (auch WLAN), dazu verpflichtet, Fotos des Innenlebens des Geräts an die FCC (Federal Communications Commission) zu übermitteln und diese stellt das Ganze dann für jeden einsehbar ins Internet. Dadurch sind wir in der Lage, durch die Analyse öffentlich verfügbarer Daten spezielle Fragen zu beantworten. Und da klingeln bei mir die Glöckchen, denn das ist genau die Definition von Open Source Intelligence (OSINT) und damit eines meiner Lieblingsthemen.

Also ab auf Amazon und nach einer „Smart Camera“ suchen. Zu Beginn wollen wir natürlich direkt wissen, ob in der Kamera, die wir gleich bestellen, schon Schwachstellen gefunden wurden, denn am liebsten haben wir natürlich eine grüne Wiese. Ins Auge fallen viele Modelle der „TP-Link Tapo“ Reihe, aber eine kurze Google-Suche ergibt, dass sich hier schon viele Researcher die Zähne ausgebissen haben, also kein gutes Ziel für den Anfang. Danach bleiben im niedrigen Preissektor vor allem Modelle von Firmen mit weniger bekannten Namen und sehr interessanten Firmenstrukturen.

Als Ziel habe ich letztendlich folgende Kamera gewählt, die diesen Punkt ganz gut illustriert:

Der Markenname ist GNCC und auch eine Website findet man unter „gncchome.com“. Uns interessiert brennend, wie es in der Kamera aussieht; das heißt, wir müssen die Datenbank der FCC durchsuchen. Das ist unter anderem auf folgenden Seiten möglich:

Ich habe fccid.io aufgrund der guten Bedienbarkeit verwendet und hier ergab eine Suche nach „GNCC“ genau nichts.

Leider findet sich die FCC ID der Kamera auch nicht in der Produktbeschreibung auf Amazon. Aber hier können wir etwas „OSINTen“, denn eine wirklich wunderbare Sache am Internet ist, dass jeder seine Meinung zu allem kundtun darf und viele das auch tun. So auch zu Produkten und das auch noch mit Bildern aus allen möglichen Winkeln.

Dabei gab es sogar einige Kunden, die leider die FCC ID geschwärzt haben, schade. Aber wie oft im OSINT: „Wer lang genug scrollet, der findet.“ Und so auch dieses Mal:

Da steht unsere FCC ID: 2A3PR-GC1. Ab in fccid.io damit:

Interessanterweise sieht man bei dieser Suche, dass das Gerät von einer Firma namens „Kalado LLC“ angemeldet wurde. Ein bisschen Google-Suche ergibt, das GNCC eine Marke dieser Firma ist. Ihre Adresse haben beide Firmen in einem WeWork Büro in Washington, das wird wohl kaum der Ort sein, an dem die Kameras hergestellt werden. Dem aufmerksamen Leser wird auch schon aufgefallen sein, dass in den FCC Dokumenten gar keine internen Fotos zu finden sind, sondern nur externe. Die Antwort auf dieses Mysterium finden wir in dem Dokument: „FCC Authorization from Original Grantee for ID change V1″.

Das heißt also, die GNCC bzw. Kalado kaufen die Technik der Kamera nur von der „Shenzhen Weizhen Commercial and Trading Co,Ltd.“, packen ihr Plastik drum, ihren Sticker darauf und das Ganze dann in einen Karton mit Firmenlogo und haben mit der ganzen Technik wahrscheinlich nichts zu tun. Aber egal, wir haben die FCC ID, die wir brauchen. Ich glaube, es ist nach der ganzen Abbiegung im Gedankengang nicht mehr so ganz klar, warum wir das hier alles tun. Der eigentliche Grund ist, dass wir in das Innere der Kamera schauen wollen, um zu sehen, ob die Entwickler Debugging-Anschlüsse (sog. „Universal Asynchronous Receiver / Transmitter“ oder UART) auf dem Board belassen haben, die es uns erlauben, mit dem Gerät per Shell zu interagieren.

In Rot markiert sehen wir einige Anschlüsse, welcher die typischen UART Label aufweist. Auch wenn diese keine Garantie für ein Vorhandensein eines UART Anschlusses ist, ist die Wahrscheinlichkeit recht hoch, dass er bei dieser eher günstigeren Hardware vorhanden ist. Theoretisch können diese Anschlüsse für Hardware, die verkauft wird, abgeschaltet werden, allerdings wird dies bei günstigen Geräten oft unterlassen.

Ein erster, eigener Versuch

Wenige Tage später ist die Kamera angekommen und ich konnte meine ersten praktischen Versuche an einer echten Hardware starten. Natürlich ist der erste Schritt, die Kamera einmal komplett zu zerlegen. Das Endergebnis davon sieht so aus:

Im Inneren der Kamera finden wir ein Printed Circuit Board (PCB), auf dem sich alle wesentlichen Elemente der Kamera befinden; an dieses ist ein Ring mit Infrarotlicht (1), ein Lautsprecher (2) und das Kameraobjektiv (3) angeschlossen. Am meisten am Innenleben der Kamera interessiert uns jedoch die UART-Schnittstelle. Diese erlaubt uns, wie bereits erwähnt, in vielen Fällen, mit dem Gerät per Shell zu interagieren und Debug Nachrichten auszulesen. Also der Traum jedes Hackers. Um mit dieser Schnittstelle zu interagieren, werden zuerst Pins auf diese angelötet:

Netterweise haben die Entwickler der Kamera die Pins mit Beschriftungen versehen, die uns deren Belegung offenbaren:

  • GND: Ground, ist der Referenzpunkt für das Messen der Spannung auf den anderen Pins.
  • RX: Ist der Receiver Pin, über welchen das Gerät die Übertragung von Befehlen erwartet.
  • TX: Ist der Transmitter Pin, über den das Gerät Daten überträgt.

Um unsere Hardware zu schützen, ist es empfehlenswert, die höchste Spannung zu messen, welche über den TX Pin übertragen wird, um festzustellen, ob es sich hier um einen UART-Anschluss handelt. Dabei nutzen wir ein Multimeter, welches auf die Messung von Volt (Gleichstrom) eingestellt wird. Das schwarze Ende des Multimeters verbinden wir mit GND (die Metallbeschichtungen an der Seite des Gerätes sind in diesem Fall auch GND) und das rote Ende verbinden wir mit dem TX Pin. Wenn Übertragungen auf dem TX Pin erfolgen, dann schwankt die Spannung merkbar.

Anhand der Messung des Multimeters können wir sehen, dass dieser UART-Anschluss die typische Spannung von 3,3V verwendet..

Für das Anschließen an die UART-Pins benötigt es einen Adapter. Solche Adapter gibt es günstig im Internet zu kaufen.

Dieser Adapter kann mit den entsprechenden Pins wie folgt verbunden werden. Der TX Pin des Adapters zum RX-Pin der Kamera. Der RX-Pin des Adapters zum TX Pin der Kamera und GND zu GND. Entschuldigt bitte die Farben der Kabel im folgenden Bild, das waren die Einzigen, die gerade da lagen:

Anschließend wird der Adapter an den USB-Ports eines PCs angeschlossen. Hier sollte Linux verwendet werden, entweder in einer virtuellen Maschine oder auf einem Raspberry Pi.

Unter Linux ist eine Verbindung zu dem über das folgende Kommando möglich:

sudo screen /dev/ttyUSB0 115200

Dabei steht /dev/ttyUSB0 für das USB Gerät des Adapters und 115200 für die Baud Rate (Bits pro Sekunde). Mehr zu diesen Begriffen findet sich hier.

Erzähl mir über dich…

Nachdem die Kamera an den Strom angeschlossen ist, wird der Bildschirm mit Debug Nachrichten nur so geflutet. Darunter auch eine, die uns als Angreifer sehr freut, denn sie enthält das Passwort des WLAN Netzwerkes, mit dem sich die Kamera verbindet.

Hat jemand „Passwort“ gesagt?

Eigentlich haben wir uns ja mit dem UART Anschluss verbunden, um eine Shell auf dem Gerät zu erhalten. Leider lässt sich dieses Vorhaben nicht So einfach wie gedacht umsetzen, denn wir werden mit einer Login Prompt konfrontiert.

Diese scheint nicht nur zur Deko vorhanden zu sein, denn sie reagiert nicht auf Kombinationen wie admin:admin. Wenn wir als Hacker aber mit einer Mauer konfrontiert werden, dann graben wir einen Tunnel.

Freundlicherweise erlaubt uns das System den Autoboot Prozess zu unterbrechen und in der Bootloader Konsole ein paar Einstellungen anzupassen. Der Bootloader ist eine Software, welche vor dem Start des eigentlichen Betriebssystems startet, um dieses zu laden und zu starten.

Nachdem der Autoboot Prozess unterbrochen ist, ist es unser Ziele einen der Bootparameter so zu verändern, dass die Kamera statt normal zu booten und die Loginmaske anzuzeigen, direkt in eine Shell bootet. In diesem Fall funktioniert das mit dem folgenden Kommando:

setenv boot_normal env set bootargs console=ttySAK0,115200n8 root=/dev/mtdblock5 rootfstype=squashfs init=/bin/sh ${mtdparts} ${mem} ${memsize}\; run read_kernel\; bootm ${loadaddr} - ${fdtcontroladdr}

Der init=/bin/sh Teil sorgt dafür, dass die Kamera direkt in eine Shell bootet. Dieser Bootvorgang wird mit dem folgenden Kommando iniziiert:

run boot_normal

Und schon genießen wir eine Shell mit Rootprivilegien.

Responsible Disclosure

Da wir als IT-Sicherheitsdienstleister eine Verantwortung haben die Schwachstellen offenzulegen, um die Sicherheit für alle zu verbessern, haben wir für diese Schwachstellen CVE Nummern beantragt und einen Advisory veröffentlicht. Leider konnten wir keine Antwort des Herstellers erhalten.

Mehr Details zu diesen Schwachstellen finden sich in diesem Advisory: https://www.nsideattacklogic.de/advisories/NSIDE-SA-2024-001.

Fazit

Auch wenn Hardwareschwachstellen durch die Notwendigkeit von physischem Zugriff auf das Gerät schwerer auszunutzen sind, können sie dennoch gravierende Folgen haben. In diesem Fall könnte die Kamera zum Beispiel im öffentlich zugänglichen Teil eines Geschäftes angebracht werden und mit demselben Netzwerk wie ein altes Kassensystem verbunden sein. In diesem Fall wäre ein Angriff bereits durch kurzes Abmontieren des „Deckels“ der Kamera möglich und könnte somit gravierende Folgen haben.

Des Weiteren ist zu Beginn erwähnt worden, dass die Hardware der Kamera nicht von der Firma hergestellt wird, die diese auch verkauft. Daher ist es für uns unmöglich, abzuschätzen, welche weitere Hardware noch von diesen Problemen betroffen ist. Wahrscheinlich findet sich dieses Problem aber auch noch in anderen, günstigen Kameras.

Was sollte also als Nutzer von günstigen IoT Geräten beachtet werden? Wir empfehlen dazu folgendes:

  • Über die Sicherheit des Produktes informieren: Auch wenn die Sicherheitsbranche wahrscheinlich nicht mit dem Testen all der günstigen IoT-Geräte auf dem Markt hinterherkommt, empfiehlt sich dennoch eine Recherche, ob das zur Auswahl stehende Gerät von Schwachstellen betroffen ist. Dies ist neben Google Suchen auch über die CVE-Datenbank von MITRE möglich: https://cve.mitre.org/.
  • IoT Geräte mit isolierten Netzwerken verbinden: Wenn IoT Geräte mit dem Internet verbunden sein müssen, dann sollte dies in einem separaten Netzwerk erfolgen, welches keinen Zugriff auf den Rest des Heimnetzwerkes hat und auch keine Kommunikation der Geräte untereinander erlaubt. Die meisten Heimrouter bieten dafür ein Gastnetzwerk an.
  • Bei kritischen Funktionen auf zertifizierte Anbieter zurückgreifen: Sobald ein IoT Gerät eine geschäftliche Funktion übernimmt, oder mit sensiblen Daten arbeitet, dann sollte unbedingt auf vertrauenswürdige Anbieter mit zertifizierten Geräten und einer Koordinationsstelle für Sicherheit, sowie der Möglichkeit für Updates zurückgegriffen werden. Selbstverständlich sind diese unter Umständen etwas teurer, aber nicht, wenn in die Kalkulation auch das Risiko der günstigeren Geräte einbezogen wird. Sollten Sie Fragen zur IoT oder Hardware Sicherheit haben, oder Geräte, die sie entwickeln, verkaufen, oder einsetzen testen lassen wollen, dann kontaktieren Sie uns gerne.

Sollten Sie Fragen zur IoT oder Hardware Sicherheit haben, oder Geräte, die sie entwickeln, verkaufen, oder einsetzen testen lassen wollen, dann kontaktieren Sie uns gerne.