tezeb/accflyOffenlegung von Schwachstellen in Accfly-Kameras: CVE-2020-25782, CVE-2020-25783, CVE-2020-25784, CVE-2020-25785.
Anfang 2020 hatte ich an meinem damaligen Arbeitsplatz die Gelegenheit, an einem internen pwn2own-ähnlichen Event teilzunehmen. Es standen mehrere Ziele zur Verfügung, aber am meisten interessierte mich die Accfly Wireless Security Camera. Leider konnte ich meine Recherche für das eigentliche Event nicht abschließen, aber da es keine anderen Versuche an diesem Gerät gab, habe ich sie fortgesetzt.
Der Schwerpunkt der Forschung lag auf Schwachstellen, die zu Remote Code Execution (RCE) führen könnten. Diese Art von Schwachstelle ermöglicht es einem Angreifer, die vollständige Kontrolle über das Gerät zu übernehmen und kann bei einer Videokamera zu einem vollständigen Verlust der Privatsphäre des Besitzers führen. Leider stellte sich heraus, dass die Geräte-Firmware mit solchen Problemen übersät ist.
Zunächst bietet das Gerät keinerlei Authentifizierung. Daher kann ein Angreifer, der eine Verbindung herstellen kann, frei darauf zugreifen und es neu konfigurieren. In der einfachsten Form ist es möglich, das Gerät kontinuierlich neu zu starten, wodurch es für den legitimen Benutzer völlig unbrauchbar wird. Der Umfang dieses Angriffs ist etwas eingeschränkt, da das Gerät für die Nutzung in einem WiFi-Netzwerk, in der Regel hinter NAT, ausgelegt ist und daher nicht direkt aus dem Internet erreichbar ist. Das Fehlen einer Verschlüsselung zwischen dem Gerät und der Smartphone-App des Besitzers, zusammen mit der Nutzung des Servers des Herstellers als Proxy für die Kommunikation, bietet jedoch eine Möglichkeit für MitM- oder DNS-Manipulationsangriffe, die die WiFi-NAT-Einschränkung umgehen können.
Darüber hinaus verwendet die Anwendung ein proprietäres binäres Protokoll zur Kommunikation. Es wurde in einer Mischung aus C und C++ implementiert und erwies sich als voll von unsicheren String-Verarbeitungsfunktionen. Die Hauptausführungsdatei enthält eine große Menge ungenutzten Codes, was darauf hindeutet, dass sie auf anderen Geräten wiederverwendet wird. Dies erschwert die Wartung und vergrößert die Angriffsfläche. Die Anwendung aktiviert keine modernen Sicherheitsmechanismen, die sie gegen viele gängige Exploitation-Techniken schützen würden. Darüber hinaus schränkt sie nicht einmal die Benutzerrechte ein und läuft als root – mit den höchsten verfügbaren Privilegien.
Als Ergebnis dieser Forschung wurden die folgenden vier Schwachstellen dokumentiert.
CNetClientManage::ServerIP_Proto_Set bei der Verarbeitung eingehender NachrichtenCNetClientTalk::OprMsg bei der Verarbeitung eingehender NachrichtenCNetClientGuard::SubOprMsg bei der Verarbeitung eingehender NachrichtenCFtpProtocol::FtpLogin während des Update-VorgangsFür drei davon wurden RCE-Exploits entwickelt, die es einem Angreifer ermöglichen, die vollständige Kontrolle über das Gerät zu erlangen. Aufgrund des fehlenden Herstellerfeedbacks auf die Meldung der Schwachstellen enthält dieses Repository jedoch nur begrenzte PoC-Exploits, die lediglich die Anwendung zum Absturz bringen.
Die Probleme wurden in der Softwareversion V3.10.73 gefunden und in der Softwareversion V4.15.77 verifiziert, der zum Zeitpunkt dieser Veröffentlichung (26. Januar 2021) aktuellsten verfügbaren Version.
Bei Fragen zögern Sie nicht, mich per E-Mail (siehe Git-Commit) oder über GitHub Issues zu kontaktieren. Wenn Sie ein IoT-Gerät haben, das Sie für interessant zum Hacken halten, auf der Suche nach einem Security Researcher sind oder einfach nur Hallo sagen möchten, freue ich mich von Ihnen zu hören. Sie können mir auch einen Kaffee kaufen!
Das Zielgerät ist eine Videokamera, die über die zugehörige Mobile-App gesteuert wird. Meine Analyse begann mit dem Netzwerkverkehr der Kamera und setzte sich in der Kamera-Firmware fort. Für die gesamte Kommunikation wird ein benutzerdefiniertes binäres Protokoll verwendet. Befehle werden entweder direkt an das Mobilgerät gesendet, wenn sie sich im selben Netzwerk befinden, oder durch den Server des Geräteherstellers weitergeleitet. Die Kamerasoftware selbst hört auf mehreren Ports TCP (23456,34567) und UDP (34568,34569). Es gibt weder Verschlüsselung noch Authentifizierung für den Netzwerkverkehr, was MitM-Angriffe oder direkten Zugriff ermöglicht, wenn die Kamera über das Netzwerk exponiert ist. Es erscheint wahrscheinlich, dass auch der Zugriff auf den Videostream ohne Authentifizierung möglich ist, aber ich habe das proprietäre Protokoll nicht ausreichend reverse-engineered, um dies auszuprobieren.
Nach einer kurzen Übersicht über die Kommunikation bestand der nächste Schritt darin, Zugriff auf die Geräte-Firmware zu erhalten. Mein erster Versuch war, sie direkt durch Hijacking des Geräte-Update-Prozesses herunterzuladen, aber im Netzwerkverkehr passierte nichts dergleichen. Ich wäre in dieser Phase stecken geblieben, wenn nicht die dringend benötigte Hilfe eines Kollegen gewesen wäre, der die Firmware aus dem Flash-Speicher extrahierte, was es mir ermöglichte, mit dieser Forschung fortzufahren.
Die Firmware erwies sich als Linux auf einem MIPS-Little-Endian-Prozessor. Es gibt genau einen interessanten Prozess namens Alloca, der für die Videoaufnahme zuständig ist und auch die gesamte Netzwerkkommunikation abwickelt. Die Anwendung ist in C++ erstellt und enthält viel Code, der auf diesem Gerät ungenutzt ist. Dies deutet darauf hin, dass dieselbe Software auch auf anderen Geräten verwendet wird.
Obwohl dieses Problem als letztes gefunden wurde, ist es entscheidend für die tatsächliche Ausnutzung der meisten anderen, da sie auf der Verwendung unsicherer C-String-Funktionen beruhen. Obwohl es verschiedene Techniken gibt, die für eine erfolgreiche Codeausführung in ähnlichen Szenarien eingesetzt werden können, ist die Anwendung so aufgebaut, dass diese weitgehend nutzlos sind. Das Hauptproblem ist, dass Alloca's Code und Daten statisch auf niedrigen Adressen (< 0x01000000) alloziert sind. Daher sind Versuche, vorhandenen Code wiederzuverwenden (z.B. ROP und ähnliches), nicht sinnvoll, da sie die Fähigkeit erfordern, Adressen in den Speicher des Programms zu schreiben. Da C-Strings \x00 als Abschlusszeichen verwenden und String-Funktionen die Verarbeitung beim ersten solchen Byte beenden, ist es nicht möglich, mehr als ein einzelnes NULL-Byte zu verwenden. Zudem ist die Stack-Position randomisiert und die Anwendung stark multithreaded, was andere Techniken viel unzuverlässiger macht.
Diese Schwachstelle ist das Ergebnis der gemeinsamen Nutzung von Daten zwischen mehreren Threads und der unsicheren Verwendung von strcpy. Obwohl ich diese spezielle Problematik lange analysiert habe, habe ich die Möglichkeit, sie als Datenleck-Vektor zu nutzen, erst wenige Wochen vor dieser Veröffentlichung entdeckt. Interessanterweise ermöglicht diese Schwachstelle dank des Lecks der Heap-Adresse eines C++-Objekts auch eine Remote-Code-Ausführung. Dieser Angriff ist jedoch nicht in diesem Bericht enthalten.