Warum wird eine Webcam zu einer Hintertür?
Berichte über erfolgreiche Hacks gegen Geräte des Internets der Dinge (IoT) nehmen zu. Bei den meisten dieser Versuche ging es darum, zu demonstrieren, wie man Zugang zu einem solchen Gerät erhält oder dessen Sicherheitsbarriere durchbricht. Die meisten dieser Angriffe werden als relativ unbedeutend angesehen, da die Geräte selbst keine wirklich wertvollen Daten (wie Kreditkartennummern oder personenbezogene Daten) enthalten. Die fraglichen Geräte bieten den Botnet-Besitzern in der Regel keinen großen Wert, da sie in der Regel über viel Bandbreite, aber nur über sehr wenig CPU und RAM verfügen.
Diese Geräte werden jedoch für raffinierte Angreifer noch interessanter, wenn sie dazu verwendet werden können, einen dauerhaften Zugangspunkt in einem Netzwerk einzurichten. Durch den Einbau einer Callback-Backdoor in eine Webcam erhält ein Hacker beispielsweise einen dauerhaften Zugang zum Netzwerk, ohne einen Laptop, eine Workstation oder einen Server infizieren zu müssen, die in der Regel streng überwacht werden und oft gepatcht sind. Auf einem winzigen Gerät gibt es keinen Virenschutz und keinen endpoint Schutz. Tatsächlich denkt niemand daran, dass auf dem Gerät überhaupt Software installiert ist. Das macht diese Geräte zu einem idealen Ziel für hartnäckige Angreifer, die ihre Angriffe über verdeckte Befehls- und Kontrollkanäle steuern.
Der Nachteil für den Angreifer besteht darin, dass diese Geräteklasse in der Regel über keinen wirklich brauchbaren dauerhaften Speicher verfügt. Stattdessen verwenden sie das Nvram zum Speichern der Konfiguration und das Flash-ROM zum Speichern des laufenden Codes. Die Hoffnung des Angreifers auf echte Persistenz beruht also darauf, dass er kontrollieren kann, was im Flash-ROM gespeichert wird. In diesem Blog werden wir untersuchen, wie schwierig es ist, ein neues Flash-Image zu erstellen, das alle Tools enthält, die wir benötigen, um eine wirklich persistente Hintertür in das Netzwerk, in dem das Gerät installiert ist, einzurichten. Sobald wir ein solches Flash-Image haben, könnten wir es einsetzen, indem wir ein bereits eingesetztes Gerät "aktualisieren" oder die Hintertür irgendwo in der Lieferkette auf dem Gerät installieren - d. h. bevor es vom Endkunden empfangen und installiert wird. Damit dieses Experiment sinnvoll ist, muss das Gerät unbedingt weiterhin seine normale Funktion erfüllen, sonst würde es sofort Verdacht erregen oder den Kunden veranlassen, das Gerät durch eine funktionierende Version zu ersetzen.
Erste Schritte
In diesem Szenario kaufte das Team von Vectra Threat Labs eine WiFi-Webkamera von D-Link für etwa 30 US-Dollar*. Das Aufbrechen des kleinen, wunderbaren Plastikgehäuses war eine erstaunliche Erfahrung und eine freundliche Erinnerung daran, dass ein Leatherman nicht das richtige Werkzeug für jeden Job ist...
Ein kurzer Blick auf die Platine zeigt:
- WiFi-Antenne
- Ralink RT5350F
- SDram M12L2561616a-6t
- Flash Rom MX25L3205
Dumping des Flash-Speichers
Da sich der Flash-Speicherchip auf der Platine befindet, vermuten wir, dass die Daten bzw. der Code wahrscheinlich dort gespeichert werden, damit sie erhalten bleiben. Als Erstes müssen wir also den Inhalt dieses Chips auslesen, um zu sehen, was darauf gespeichert ist.
Nachdem wir einen Buspiraten an das Board angeschlossen haben, können wir Flashrom verwenden, um den Inhalt auszulesen.
#flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1Mflashrom v0.9.7-r1782 auf Linux 4.0.0-kali1-amd64 (x86_64)flashrom ist freie Software, den Quellcode gibt es unter Kalibrierung der Verzögerungsschleife... OK. Macronix Flash Chip "MX25L3205(A)" (4096 kB, SPI) auf buspirate_spi gefunden.Macronix Flash Chip "MX25L3205D/MX25L3208D" (4096 kB, SPI) auf buspirate_spi gefunden.Macronix Flash Chip "MX25L3206E" (4096 kB, SPI) auf buspirate_spi gefunden.Mehrere Flash-Chip-Definitionen passen zu dem/den gefundenen Chip(s): "MX25L3205(A)", "MX25L3205D/MX25L3208D", "MX25L3206E "Bitte geben Sie mit der Option -c an, welche Chip-Definition Sie verwenden möchten.
Jetzt können wir den Inhalt der Flash-Chips für weitere Analysen auslagern.
#flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=1M -c 'MX25L3205(A)' -r MX25L3205-A
Analysieren des Flash-Dumps
Sobald wir einen schönen Dump des Flashs haben, können wir binwalk verwenden, um festzustellen, was sich darin befindet.
#binwalk -Me MX25L3205-A DECIMAL HEXADECIMAL DESCRIPTION--------------------------------------------------------------------------------0 0x0 uImage header, header size: 64 bytes, header CRC: 0x11BEF629, created: Tue Feb 3 11:07:53 2015, Bildgröße: 111116 Bytes, Datenadresse: 0x80200000, Einstiegspunkt: 0x80200000, Daten CRC: 0xCD95F789, OS: Linux, CPU: MIPS, Image-Typ: Eigenständiges Programm, Komprimierungstyp: keine, Image-Name: "SPI Flash Image "91040 0x163A0 U-Boot Versionsstring, "U-Boot 1.1.3"105424 0x19BD0 HTML document header105777 0x19D31 HTML document footer105780 0x19D34 HTML document header105979 0x19DFB HTML document footer106140 0x19E9C HTML document header106840 0x1A158 HTML document footer210495 0x3363F PEM certificate211671 0x33AD7 PEM RSA private key327680 0x50000 uImage header, header size: 64 bytes, header CRC: 0xABF213A9, created: Tue Feb 3 11:07:48 2015, Imagegröße: 3730981 Bytes, Datenadresse: 0x80000000, Einstiegspunkt: 0x8038B000, Daten CRC: 0x2829F3C1, OS: Linux, CPU: MIPS, Image-Typ: OS Kernel Image, Kompressionstyp: lzma, Image-Name: "Linux Kernel Image "327744 0x50040 LZMA komprimierte Daten, Eigenschaften: 0x5D, Wörterbuchgröße: 33554432 Bytes, unkomprimierte Größe: 6394309 Bytes327744 0x50040 LZMA-komprimierte Daten, Eigenschaften: 0x5D, Wörterbuchgröße: 33554432 Bytes, unkomprimierte Größe: 6394309 Bytes
Das Format dieser Firmware besteht also aus einem U-Boot und einem Linux-Kernel und -Image.
Wir hätten dd, lzma oder cpio verwenden können, um den Inhalt der Firmware zu extrahieren, oder wir können binwalk diese Arbeit machen lassen. Wir müssen noch den letzten Schritt des cpio-Images extrahieren, um den Inhalt des Images zu sehen.
#cpio -ivd --no-absolute-filenames -F. 0.cpio
Sobald dieser letzte Schritt erledigt ist, können wir auf das Linux-Image-Dateisystem zugreifen.
Ein interessantes Binärprogramm im Dateisystem ist /bin/upgradefw. Dies scheint die ausführbare Datei zu sein, die für die Überprüfung und Aktualisierung der Firmware verwendet wird.
#file ./bin/upgradefw./bin/upgradefw: ELF 32-bit LSB executable, MIPS, MIPS-II Version 1 (SYSV), dynamisch gelinkt, Interpreter /lib/ld-uClibc.so.0, stripped
Analysieren der upgradefw-Binärdatei
In diesem Abschnitt werden wir uns auf IDA Pro als das Tool der Wahl für das Reverse-Engineering der Upgrade-Binärdatei verlassen.
IDA ist in der Lage, einen sehr guten ersten Durchlauf der Binärdatei zu machen, was die Analyse erheblich erleichtert. Folgt man dem Codepfad von der Hauptfunktion aus, gelangt man ziemlich schnell zu einer Funktion namens "check", die den größten Teil der Arbeit erledigt, um zu überprüfen, ob das Flash-Image gültig ist, bevor es an mtd_write gesendet wird.
Die von der upgradefw-Binärdatei durchgeführte Validierung scheint einige crc32-Prüfungen, memmem/strstr-Prüfungen und eine Schleife zu umfassen, die einen Wert berechnet und ihn mit einem oder zwei festen Werten vergleicht.
Der logische Ablauf der Prüffunktion zwischen dem Einstiegspunkt und einer erfolgreichen Rückkehr sieht in etwa so aus:
1. Prüfen Sie, ob die Datei korrekt geöffnet wurde
2. Größe der Datei prüfen
3. Datei laden und prüfen, ob das Lesen funktioniert hat
4. Markieren Sie das Feld "Unterschrift": "
5. Prüfen Sie das Feld "Freigabe": "
6. Vergleichen Sie das Release mit dem aktuellen Release
7. Uboot/uimage Prüfroutine
Wechsel zu x86 hier für die 55AA55AA Prüfsumme.
Hinzufügen einer Hintertür
An diesem Punkt wird das Hinzufügen einer Backdoor in etwa zum Hinzufügen eines Dienstes innerhalb eines Linux-Systems - in unserem Fall wollen wir nur einen einfachen Socks-Proxy mit Rückverbindung. Dies kann entweder mit einem srelay und netcat im Startskript oder mit optimiertem C-Code erreicht werden, oder man könnte eine einfache Callback-Backdoor mit einer Shell verwenden, die netcat und busybox nutzt, die bereits auf dem System vorhanden sind.
Es ist immer eine gute Idee, die hinzugefügten Funktionen so gering wie möglich zu halten - schließlich haben wir es hier nicht mit einem kompletten Laptop zu tun, sondern mit einer kleinen Webcam mit 4 MB ROM. Wenn man also zu viele Funktionen hinzufügt, macht man die Software einfach kaputt. Während wir die Änderung vornehmen, können wir auch die Möglichkeit entfernen, das Gerät in Zukunft neu zu flashen. Dies würde ein vom Administrator initiiertes Firmware-Update verhindern, das unsere Hintertür entfernen würde.
Neu verpacken
Nachdem wir einige Zeit damit verbracht hatten, ein Skript zum Umpacken zu erstellen, fanden wir ein nettes Skript auf der Ralink-Website, das sich als ziemlich nützlich erwies.
verwenden:
make -f Makefile.4M
Danach muss nur noch die Prüfsumme in der Datei korrigiert werden. Dies kann entweder mit einem RaLink-Dienstprogramm namens addchecksum oder durch manuelle Korrektur der Prüfsumme erreicht werden. Der Offset/Bereich, den die Prüfsumme verwendet, kann sowohl in der upgradefw- als auch in der addchecksum-Binärdatei ermittelt werden. Und wie immer... überprüfen Sie Ihre Endianness.
Testen einer Rückverbindung
Mithilfe von telnetd / busybox / netcat können wir einen Telnet-Socket zu einem externen Host zurückbringen, um die Webcam aus der Ferne zu überwachen. Da die Webcam als Proxy fungiert, kann der Angreifer nun Kontrollverkehr in das Netzwerk senden, um seinen Angriff voranzutreiben, und ebenfalls die Webcam nutzen, um gestohlene Daten abzuschöpfen.
Escape-Zeichen ist '^]'.(none) login: adminPassword:BusyBox v1.12.1 (2015-11-11 05:41:04 UTC) built-in shell (ash)Geben Sie 'help' ein, um eine Liste der integrierten Befehle zu erhalten.# ls /biniwpriv pcmcmd nvram_daemon ntpclient sounddb ipush touch pwd ls cpov7740 switch mii_mgr mtd_write notifystream schedule sync ps login chmoduvc_stream gpio ated msmtp mydlinkevent lanconfig sleep ping kill catmail nvram_set reg mDNSResponder imagetp iperf sh mount grep ashi2c nvram_get pppoecd lld2d upgradefw inadyn sed mknod echo busyboxswing ralink_init openssl disablebonjour audiopush umount rm mkdir date alphapd
Schlussfolgerung
Bedeutet all dies also, dass die Webkamera von D-Link ein großes Sicherheitsproblem hat? Nicht unbedingt - wir bekommen das, wofür wir bezahlen, und von einem Anbieter, der eine Webcam für 30 US-Dollar auf Amazon verkauft, sichere Firmware-Update-Funktionen zu verlangen, die ein TPM oder einen speziellen Chip zur Überprüfung des Inhalts und der Signatur eines Software-Updates erfordern würden, ist nicht sehr realistisch. Der Sinn dieser Demonstration besteht vielmehr darin, die tatsächlichen Auswirkungen von IoT-Geräten auf die Angriffsfläche eines Netzwerks zu verdeutlichen. Wie wir gezeigt haben, sind die Hürden für das Hacken dieser Geräte relativ niedrig, und selbst die einfachsten Geräte können die Grundlage für einen dauerhaften Befehls- und Kontrollkanal bilden. Auch wenn diese Geräte nur geringe Kosten verursachen, sind sie dennoch wichtig für die Sicherheit des Netzwerks, und Teams müssen sie im Auge behalten, um Anzeichen für bösartiges Verhalten zu erkennen.
*Vectra informierte D-LInk Anfang Dezember 2015 über das Problem. Bis zum 7. Januar 2016 hat das Unternehmen noch keine Lösung bereitgestellt.