tothi/pwn-hisilicon-dvrProof-of-Concept-Exploit und Offenlegung von Schwachstellen für HiSilicon hi3520d DVR/NVR-Geräte. Demonstriert RCE über die Weboberfläche, Backdoor-Zugangsdaten und Buffer-Overflow-Analyse.
= HiSilicon DVR Hack Istvan Toth [email protected] v1.0, 2017-09-06 :source-highlighter: pygments :toc: preamble :toclevels: 5 :toc-title: Inhaltsverzeichnis :image_width: 100%
[abstract] Dieser Bericht legt schwerwiegende Schwachstellen (mit Proof-of-Concept (PoC)-Code) von DVR/NVR-Geräten offen, die mit dem HiSilicon hi3520d und ähnlichen System-on-a-Chip (SoC) aufgebaut sind. Die Ausnutzung der Schwachstellen führt zu unautorisierter Remote-Codeausführung (RCE) allein über die Webschnittstelle, wodurch das betroffene Gerät vollständig übernommen werden kann. Aufgrund fehlender aktualisierter Firmware wird die Verwendung dieser Geräte nicht empfohlen. Der Hersteller wurde vor Dez. 2016 kontaktiert, aber bislang gibt es keine Antwort. Das Veröffentlichungsdatum der Offenlegung ist Feb. 2017.
== Vorwort
Vor ein paar Jahren habe ich ein billiges chinesisches DVR-Gerät bei eBay gekauft. Das Boot-Logo des Geräts zeigt: "SECULINK - Security Monitoring". Als IT-Sicherheits-Enthusiast beschloss ich, mir das Gerät genauer anzusehen, um zu sehen, wie "sicher" dieser Sicherheitsüberwachungsdienst ist. Beim Googeln zu diesem Thema fand ich einige interessante Materialien, grub aber tiefer und entdeckte viel interessantere und ernstere Probleme (0-Days) an dem Gerät.
Werfen wir einen Blick auf die vollständige Hacking-Sitzung von Anfang an. (Die neuen, eigenen Erkenntnisse werden ebenso erwähnt wie die alten, bekannten.)
== Erkundung des DVR
Zuerst sollten wir die offizielle Benutzeroberfläche kennenlernen, dann tiefer graben, vielleicht versuchen, die Firmware zu erhalten. Die Chancen, Schwachstellen zu finden, steigen mit der Firmware.
=== Das DVR-Gerät auf den ersten Blick
Das für Tests vorgesehene DVR-Gerät trägt die Marke "Seculink".
image::./seculink_device.png[Seculink DVR-Gerät]
Verfügbare physische Schnittstellen:
Offizielle Benutzeroberflächen:
Die direkt zugängliche Einrichtungsoberfläche ist durch Benutzerauthentifizierung (Benutzername, Passwort) geschützt. Der Standard-Superuser ist 'admin', das Standardpasswort ist leer.
Nach der Einrichtung eines starken Passworts mag sich der Benutzer sicher fühlen, dass seine/ihre Kameraansicht für andere nicht zugänglich ist. Leute leiten oft den Webport (tcp/80) des DVR-Geräts von ihrem sicheren LAN an die WAN-Seite weiter, um von außen auf die DVR-Streams zuzugreifen (das können wir z. B. mit einer passenden Shodan-Suche überprüfen ;) ).
=== Beschaffung der Firmware
Es gibt möglicherweise viele Wege, um an die Firmware zu gelangen:
Obwohl die letztere (Download-)Methode hier funktioniert und am einfachsten ist, versuchen wir zuerst die erste, weil sie auch andere Informationen über das Gerät liefert.
=== Service-Scan
Führen wir einen vollständigen Portscan auf dem DVR durch. Beachten Sie, dass der (standardmäßig bei Ausführung als root) SYN-Scan sehr langsam ist, weil Pakete verworfen werden, der vollständige TCP-Connect-Scan aber in ein paar Minuten abgeschlossen ist.
Nmap scan report for dvr.lan (192.168.88.127) Host is up (0.028s latency). Not shown: 65529 closed ports PORT STATE SERVICE VERSION 23/tcp open telnet BusyBox telnetd 80/tcp open http uc-httpd 1.0.0 554/tcp open rtsp LuxVision or Vacron DVR rtspd 9527/tcp open unknown 34567/tcp open dhanalakshmi? 34599/tcp open unknown MAC Address: 00:12:12:15:B3:E7 (Plus ) Service Info: Host: LocalHost; Device: webcam
Zusammenfassung und manuelles Testen:
Beachten Sie, dass das Öffnen des RTSP-Streams ebenfalls Anmeldedaten erfordert.
An dieser Stelle sollten wir festhalten, dass das Gerät vermutlich ein Linux-ähnliches System ist.
Eine Verbindung zu 9527/tcp (mit rohem Netcat) zeigt die Anwendungskonsole
mit Logmeldungen und einer Anmeldeaufforderung. Die Anmeldung mit beliebigen der
definierten Anwendungsanmeldedaten funktioniert. Die Eingabe von help nach der
Aufforderung liefert eine kurze Beschreibung der Konsolenbefehle. Der Befehl
shell scheint am interessantesten zu sein. Ja, er gewährt eine Root-Shell auf
den Geräten. ;)
Beachten Sie, dass dies offensichtlich ein schwerwiegendes Sicherheitsproblem ist, denn kein (niedrig privilegierter) Anwendungsbenutzer sollte automatisch eine Root-Shell auf dem Gerät erhalten.
=== Root-Shell
Die Erkundung des Geräts in der Root-Shell (z. B. mit dmesg) macht
deutlich, dass der DVR einen Linux-Kernel (Version 3.0.8) ausführt, eine
ARMv7-CPU besitzt und das SoC-Modell hi3520d ist.
Aus der Liste der laufenden Prozesse (ps) geht hervor, dass die DVR-
Anwendung /var/Sofia ist, die zusätzlich zu den oben genannten, von nmap erkannten TCP-Ports
auch auf 34568/udp und 34569/udp lauscht (netstat -nlup).
Aus der Liste der eingehängten Datenträger (Befehl mount) geht hervor, dass sich das
Firmware-Image in den /dev/mtdblockX-Geräten befindet (wobei X=0,1,2,3,4,5).
Die Firmware ist klein und daher eingeschränkt, also müssen wir kreativ sein, wenn wir Dateien auf das Gerät oder vom Gerät kopieren wollen. Glücklicherweise wird NFS unterstützt, sodass das Einrichten eines NFS-Servers auf unserem Desktop-Rechner und das Einhängen vom DVR aus das Problem löst:
Nun ist die Beschaffung der Firmware unkompliziert:
Wir können die Dateien (nicht nur die Roh-Images) erhalten:
=== Telnet-Schnittstelle
Für den Zugriff auf das Gerät über die Telnet-Schnittstelle (Port 23/tcp)
benötigen wir möglicherweise einige OS-Anmeldedaten. Ein Blick in /etc/passwd liefert den
Passwort-Hash für den Root-Benutzer:
Beachten Sie, dass es außer root keinen weiteren Benutzer gibt; alles läuft mit vollen Rechten. (Wenn also jemand irgendwie in das Gerät eindringt, gibt es keine Barriere; der Angreifer erlangt sofort die volle Kontrolle.)
