Sturm am Horizont: Einblicke in das AJCloud IoT-Ökosystem

Einführung

Wi-Fi-Kameras gehören zu den gebräuchlichsten IoT-Geräten, die in Haushalten, Unternehmen und anderen öffentlichen Räumen zu finden sind. Sie sind in der Regel recht erschwinglich und bieten Benutzern von überall auf der Welt einen einfachen Zugriff auf einen Live-Videostream auf ihrem Mobilgerät. Wie so oft bei IoT-Geräten wird die Sicherheit bei diesen Kameras tendenziell übersehen, so dass sie für kritische Schwachstellen anfällig sind. Wenn diese Schwachstellen ausgenutzt werden, können sie verheerende Auswirkungen auf die Kameras und die Netzwerke haben, in denen sie eingesetzt werden. Sie können dazu führen, dass die sensiblen personenbezogenen Daten ihrer Benutzer kompromittiert werden.

Eine kürzlich durchgeführte Elastic ON Week bot uns die Gelegenheit, die Angriffsfläche dieser Art von Geräten zu untersuchen und ein tieferes Verständnis dafür zu erlangen, wie sie kompromittiert werden. Wir haben uns in erster Linie auf die Schwachstellenforschung der Wansview Q5 (zusammen mit der fast identischen Q6) konzentriert, einer der beliebtesten und erschwinglicheren Kameras, die bei Amazon verkauft werden. Wansview ist ein Anbieter von Sicherheitsprodukten mit Sitz in Shenzhen, China, und einer der bekanntesten Vertreiber von Wi-Fi-Kameras bei Amazon.

Die Q5 bietet den gleichen grundlegenden Funktionsumfang wie die meisten Kameras:

• Schwenken / Neigen / Zoomen
• Nachtsicht
• Zwei-Wege-Audio
• Videoaufzeichnung auf SD-Karte
• Integration mit Smart Home KI-Assistenten (z. Alexa)
• ONVIF für die Interoperabilität mit anderen Sicherheitsprodukten
• RTSP für direkten Zugriff auf Video-Feed innerhalb des LAN
• Automatisierte Firmware-Updates aus der Cloud
• Technischer Remote-Support
• Zugriff auf gemeinsam genutzte Geräte mit anderen Konten
• Optionales monatliches Abonnement für Cloud-Speicher und Bewegungserkennung

Wie die meisten anderen Wi-Fi-Kameras benötigen auch diese Modelle für den grundlegenden Betrieb eine aktive Verbindung zur Cloud-Infrastruktur ihres Anbieters. Ohne Zugang zum Internet werden sie einfach nicht funktionieren. Bevor eine Kamera in Betrieb genommen werden kann, muss sie über die offizielle mobile App von Wansview und einen standardmäßigen QR-Code-basierten Einrichtungsprozess mit einem registrierten Benutzerkonto gekoppelt werden. Sobald dieser Vorgang abgeschlossen ist, ist die Kamera vollständig online und betriebsbereit.

AJCloud: Eine kurze Einführung

Obwohl Wansview seit 2009 in Betrieb ist, scheinen sie im Moment in erster Linie ein Wiederverkäufer von Kameraprodukten zu sein, die von einem separaten Unternehmen mit Sitz in Nanjing, China, hergestellt werden: AJCloud.

AJCloud bietet Anbietern Zugriff auf hergestellte Sicherheitsgeräte, die erforderliche Firmware, mobile und Desktop-Benutzeranwendungen, die Cloud-Management-Plattform und Dienste, die alles miteinander verbinden. Seit der Gründung von AJCloud im Jahr 2018 haben sie mit mehreren großen und kleinen Anbietern zusammengearbeitet, darunter, aber nicht beschränkt auf die folgenden:

• Wansview
• Cinnado
• Galayou
• Faleemi
• Philips
• Septekon
• Kluger Blick
• Heimwehr
• iPupPee

Ein flüchtiger Überblick über mobile und Desktop-Anwendungen, die von AJCloud bei Google Play, im App Store von Apple und im Microsoft Store entwickelt und veröffentlicht wurden, zeigt ihre Verbindungen zu jedem dieser Anbieter. Abgesehen von einem oberflächlichen Corporate Branding sind diese Anwendungen in Form und Funktion identisch und erfordern alle eine Konnektivität mit der AJCloud-Management-Plattform.

Was die Kameras betrifft, so ist es offensichtlich, dass diese Anbieter ähnliche Modelle mit nur geringfügigen Änderungen am Kameragehäuse und der zugrunde liegenden Hardware verkaufen.

Die Ähnlichkeit zwischen der Faleemi 886 und der Wansview Q6 (1080p) ist unübersehbar

Die Wiederverwendung von Ressourcen für die Hardwareherstellung und Softwareentwicklung trägt wahrscheinlich dazu bei, die Kosten zu kontrollieren und die Logistik für AJCloud und seine Wiederverkäufer zu vereinfachen. Diese Rationalisierung der Assets bedeutet jedoch auch, dass Sicherheitslücken, die in einem Kameramodell entdeckt werden, wahrscheinlich alle mit AJCloud verbundenen Produkte durchdringen würden.

Trotz seiner entscheidenden Rolle bei der Bereitstellung dieser Geräte für die Verbraucher hat AJCloud in der Öffentlichkeit ein relativ geringes Profil. IPVM-Forscher haben jedoch kürzlich Forschungsergebnisse zu einer bedeutenden Schwachstelle (die inzwischen behoben wurde) im GitLab-Repository von AJCloud veröffentlicht . Diese Schwachstelle ermöglicht es jedem Benutzer, auf Quellcode, Anmeldeinformationen, Zertifikate und andere vertrauliche Daten zuzugreifen, ohne dass eine Authentifizierung erforderlich ist.

Obwohl die Gesamtverkaufszahlen für Wansview und andere Anbieter im Bereich der Wi-Fi-Kameras schwer zu ermitteln sind, schätzt IPVM, dass zum Zeitpunkt der Veröffentlichung des Berichts mindestens eine Million Geräte mit der AJCloud-Plattform verbunden waren. Da die Kameraverkäufe weiterhin in die Hunderte von Millionen steigen, kann man davon ausgehen, dass in den kommenden Jahren mehr Geräte von AJCloud in Haushalten auf der ganzen Welt vernetzt sein werden.

Erste Forschungsbemühungen zur Vulnerabilität

Um ein tieferes Verständnis für die Sicherheitslage des Wansview Q5 zu erhalten, haben wir es aus mehreren Blickwinkeln angegriffen:

Zunächst konzentrierten sich unsere Bemühungen vor allem auf die aktive und passive Netzwerkaufklärung der Kamera und der Android-Version der Wansview Cloud, der offiziellen mobilen App von Wansview. Wir suchten nach offenen Ports, belauschten die Netzwerkkommunikation durch Man-in-the-Middle-Angriffe (MitM), versuchten, unvorhersehbares Verhalten der Kameras durch absichtliche Fehlkonfiguration in der App zu erzwingen, und störten den Betrieb der Kameras, indem wir das QR-Code-Format missbrauchten und physisch mit der Kamera interagierten. Die Geräte und ihre Infrastruktur waren überraschend widerstandsfähig gegen diese Art von Oberflächenangriffen, und unsere ersten Bemühungen führten zu wenigen nennenswerten Erfolgen.

Besonders überrascht waren wir von unserem mangelnden Erfolg beim Abfangen der Netzwerkkommunikation sowohl auf der Kamera als auch auf der App. Wir stießen wiederholt auf robuste Sicherheitsfunktionen (z. B. Zertifikats-Pinning, Einschränkungen für App- und Betriebssystemversionen und ordnungsgemäß gesicherte TLS-Verbindungen), die unsere Versuche störten.

Reverse-Engineering-Tools ermöglichten es uns, die APK viel genauer zu analysieren, obwohl die Komplexität der Code-Verschleierung, die im dekompilierten Java-Quellcode beobachtet wurde, eine längere Zeitspanne erforderte, um sie vollständig zusammenzusetzen.

Unser anfänglich begrenzter Erfolg würde uns dazu zwingen, weitere Optionen zu prüfen, die uns einen nuancierteren Einblick in den Q5 und seine Funktionsweise verschaffen würden.

Erstes Hardware-Hacking

Um mehr Einblick in die Funktionsweise der Kamera zu erhalten, haben wir uns entschieden, einen genaueren Blick auf die Kamera-Firmware zu werfen. Während einige Firmware-Pakete online verfügbar sind, wollten wir einen direkten Blick auf den Code werfen und ihn und die daraus resultierenden Protokolle überwachen können, während die Kamera läuft. Zu diesem Zweck haben wir uns zunächst das Hardware-Diagramm für das System-on-a-Chip (SoC) angesehen, um zu sehen, ob es Hardware-Möglichkeiten gibt, die wir nutzen können. Der Wansview Q5 verwendet einen Ingenic Xburst T31 SoC, dessen Systemblockdiagramm unten dargestellt ist.

Eine Möglichkeit, die uns besonders aufgefallen ist, war der I2Cx3/UARTx2/SPIx2 SPI I/O-Block. Wenn auf diese E/A-Blöcke zugegriffen werden kann, stellen sie häufig Protokollausgabeschnittstellen und/oder Shellschnittstellen bereit, die zum Debuggen und Interagieren mit dem SoC verwendet werden können. Da es vielversprechend erschien, führten wir dann einen Hardware-Teardown der Kamera durch und fanden etwas, das wie eine serielle UART-Schnittstelle zum SoC aussah (siehe unten).

Als nächstes schlossen wir einen Logikanalysator an, um zu sehen, welches Protokoll über diese Pins verwendet wurde, und als es dekodiert wurde, war das Signal tatsächlich UART.

Jetzt, da wir auf eine exponierte UART-Schnittstelle zugreifen können, haben wir versucht, eine Shell-Verbindung zum SoC über UART herzustellen. Es gibt eine Reihe verschiedener Softwaremechanismen, um dies zu tun, aber für unsere Zwecke haben wir das Unix-Dienstprogramm verwendet, das mit der vom Logikanalysator erkannten Baudrate screen wurde.

Beim Öffnen und Überwachen der Startsequenz stellten wir fest, dass der sichere Start nicht aktiviert war, obwohl er vom SoC unterstützt wurde. Anschließend haben wir die Konfiguration so geändert, dass sie im Einzelbenutzermodus gestartet wird, und eine Root-Shell bereitgestellt, mit der wir die Firmware untersuchen können, bevor die Initialisierungsprozesse durchgeführt werden, wie unten gezeigt.

Sobald wir uns im Einzelbenutzermodus befanden, konnten wir die Firmware-Dateien für die statische Analyse mit dem Dienstprogramm binwalk abrufen, wie unten gezeigt.

Zu diesem Zeitpunkt ist das Dateisystem in der Regel schreibgeschützt; Wir wollten jedoch in der Lage sein, Änderungen vorzunehmen und nur bestimmte Teile der Firmware-Initialisierung nach Bedarf zu instanziieren, daher haben wir einige schnelle Setups für zusätzliche Persistenz über den Einzelbenutzermodus hinaus vorgenommen. Dies kann auf verschiedene Arten erfolgen, aber es gibt zwei Hauptmethoden, die man verwenden möchte. Im Allgemeinen wird man bei beiden Ansätzen so wenig Änderungen wie möglich an der bestehenden Konfiguration vornehmen wollen. Dies wird im Allgemeinen bevorzugt, wenn dies bei der Ausführung dynamischer Analysen möglich ist, da wir die geringsten Auswirkungen auf die Laufzeitumgebung hatten. Eine Methode, die wir für diesen Ansatz verwendet haben, besteht darin, eine tmpfs Partition für den Lese-/Schreibzugriff im Speicher zu erstellen und sie über fstabzu mounten. In unserem Fall wurde fstab bereits so berücksichtigt, dass dies unterstützt wurde, und als solche war es eine sehr minimale Änderung. Weitere Informationen finden Sie in den Befehlen und Ergebnissen für diesen Ansatz.

Eine andere Methode besteht darin, vorhandene Benutzeranmeldeinformationen abzurufen und zu versuchen, diese für die Anmeldung zu verwenden. Auch dieser Ansatz war erfolgreich. Der Passwort-Hash für den Root-Benutzer befindet sich in der etc/passwd Datei und wird mit einem Tool wie John the Ripper entschlüsselt. In unseren obigen Beispielen haben wir Daten und Dateien vollständig über die serielle Verbindung übertragen. Die Kamera verfügt außerdem über einen verfügbaren SD-Kartensteckplatz, der montiert und zum Übertragen von Dateien verwendet werden kann. In Zukunft werden wir die SD-Karte oder das lokale Netzwerk zum Verschieben von Dateien verwenden, da die Bandbreite eine schnellere und einfachere Übertragung ermöglicht. Die serielle Version kann jedoch weiterhin für die gesamte Kommunikation für die Hardwareeinrichtung und das Debuggen verwendet werden, falls dies gewünscht wird.

Jetzt haben wir Root-Level-Zugriff auf die Kamera, der Zugriff auf die Firmware- und dmesg-Protokolle bietet, während die Software ausgeführt wird. Anhand der Firmware und der Protokolle haben wir dann die Benutzeroberflächen für die Kamera weiter untersucht, um zu sehen, ob es einen guten Einstiegspunkt gibt, den wir nutzen können, um weitere Einblicke zu gewinnen.

Wansview Cloud für Windows

Nachdem sich die mobilen Apps als sicherer erwiesen hatten, als wir ursprünglich erwartet hatten, verlagerten wir unseren Fokus auf eine ältere Version der Wansview Cloud-Anwendung, die für Windows 7 entwickelt wurde. Diese App, die immer noch zum Download zur Verfügung steht, würde uns einen direkten Einblick in die Netzwerkkommunikation geben, die mit Kameras verbunden ist, die mit der AJCloud-Plattform verbunden sind.

Zum großen Teil dank der übermäßigen Debug-Protokollierung seitens der Entwickler gibt die Windows-App ihre Geheimnisse mit einer rücksichtslosen Hingabe preis, die man bei kommerzieller Software selten sieht. Das erste Anzeichen dafür, dass etwas nicht stimmt, ist, dass die Anmeldeinformationen der Benutzer im Klartext protokolliert sind.

Das Reverse Engineering der ausführbaren Hauptdatei und der DLLs (die im Gegensatz zur Wansview Cloud APK nicht gepackt sind) wurde dank der häufigen Verwendung ausführlicher Protokollmeldungen mit eindeutigen Zeichenfolgen beschleunigt. Das Identifizieren von Verweisen auf bestimmte Dateien und Zeilen innerhalb der zugrunde liegenden Codebasis half uns, die Kernkomponenten der Anwendung schnell zu kartieren und den Kontrollfluss auf hoher Ebene zu etablieren.

Die Netzwerkkommunikation, die für uns auf Android schwer abzufangen war, wird immer noch über TLS übertragen, obwohl sie praktischerweise im Klartext auf der Festplatte protokolliert wird. Mit vollem Zugriff auf alle HTTP POST-Anforderungs- und Antwortdaten (die in JSON-Objekte gepackt sind) bestand keine Notwendigkeit mehr, MitM-Angriffe auf der Anwendungsseite zu verfolgen.

In den POST-Antworten fanden wir sensible Metadaten, darunter Links zu öffentlich zugänglichen Screenshots sowie Informationen über den Standort der Kamera, die Netzwerkkonfiguration und ihre Firmware-Version.

Nachdem wir alle POST-Anfragen und -Antworten dokumentiert hatten, die in den Protokolldaten gefunden wurden, begannen wir mit der Manipulation verschiedener Felder in jeder Anfrage zu experimentieren, um auf Daten zuzugreifen, die nicht mit unserer Kamera oder unserem Konto verknüpft waren. Wir würden schließlich einen Debugger verwenden, um die deviceId in die einer Zielkamera zu ändern, die nicht mit dem aktuell angemeldeten Konto gekoppelt ist. Eine Kamera-Geräte-ID dient gleichzeitig als Seriennummer und ist auf einem Aufkleberetikett aufgedruckt, das sich entweder auf der Rückseite oder Unterseite einer Kamera befindet.

Wir haben das am besten geeignete Ziel für unseren Angriff in einem Codeabschnitt gefunden, in dem die deviceId zuerst in einer POST-Anfrage an https://sdc-us.ajcloud.net/api/v1/dev-config übertragen wird:

Unser Plan bestand darin, einen Haltepunkt bei der im obigen Screenshot hervorgehobenen Anweisung festzulegen, die deviceId im Speicher auszutauschen und dann der App zu erlauben, die Ausführung fortzusetzen.

Erstaunlicherweise funktionierte dieser naive Ansatz nicht nur, um sensible Daten abzurufen, die auf der AJCloud-Plattform gespeichert waren, die mit der Zielkamera und dem Konto, mit dem sie verknüpft ist, verbunden waren, sondern er verband uns auch mit der Kamera selbst. Auf diese Weise konnten wir auf die Video- und Audiostreams zugreifen und sie über die App fernsteuern, als wäre es unsere eigene Kamera.

Durch die Ausnutzung dieser Schwachstelle und Tests mit mehreren Modellen verschiedener Anbieter haben wir festgestellt, dass alle Geräte, die mit der AJCloud-Plattform verbunden sind, auf diese Weise aus der Ferne aufgerufen und gesteuert werden können. Wir haben ein PoC-Exploit-Skript geschrieben, um diesen Prozess zu automatisieren und effektiv zu demonstrieren, wie einfach diese Zugriffskontrolllücke in der Infrastruktur von AJCloud ausgenutzt werden kann.

Erkundung der Netzwerkkommunikation

Obwohl wir in der Lage waren, einen Exploit gegen eine kritische Schwachstelle in der AJCloud-Plattform zu erstellen und zuverlässig auszulösen, mussten wir weiter graben, um ein besseres Verständnis für das Innenleben der Apps, der Kamera-Firmware und der Cloud-Infrastruktur zu erlangen.

Als wir über die POST-Anfragen und -Antworten hinausgingen, die während des Anmeldevorgangs beobachtet wurden, bemerkten wir eine Fülle von UDP-Anfragen und -Antworten von einer Vielzahl von IPs. In dieser Kommunikation waren nur wenige erkennbare Klartextdaten zu finden, und die UDP-Portnummern für die ausgehenden Anforderungen schienen zu variieren. Weitere Untersuchungen sollten später zeigen, dass diese UDP-Aktivität auf PPPP hindeutete, ein IoT-Peer-to-Peer (P2P)-Protokoll, das von Paul Marrapesse während seines Vortrags auf der DEF CON 28 ausführlich analysiert und demonstriert wurde. Später kamen wir zu dem Schluss, dass die Art und Weise, wie wir die von uns entdeckte Schwachstelle ausnutzten, durch modifizierte P2P-Anfragen erleichtert wurde, was uns dazu veranlasste, die entscheidende Rolle, die P2P in der AJCloud-Plattform spielt, weiter zu untersuchen.

Der Hauptzweck von P2P besteht darin, die Kommunikation zwischen Anwendungen und IoT-Geräten zu erleichtern, unabhängig von den beteiligten Netzwerkkonfigurationen. P2P verwendet in erster Linie einen Ansatz, der auf UDP-Loching basiert, um temporäre Kommunikationswege zu schaffen, die es Anfragen ermöglichen, ihr Ziel entweder direkt oder über einen Relay-Server zu erreichen, der sich in einer besser zugänglichen Netzwerkumgebung befindet. Der Kernsatz von P2P-Befehlen, der in die AJCloud-Apps integriert ist, ermöglicht den Zugriff auf Video- und Audiostreams sowie auf das Mikrofon und das Schwenken/Neigen/Zoomen.

Fortgeschrittenes Hardware-Hacking

Mit unserem zusätzlichen Verständnis der P2P-Kommunikation war es nun an der Zeit, die Kamera selbst während dieser P2P-Gespräche genauer zu untersuchen, einschließlich des Ausführens der Kamerasoftware in einem Debugger. Zu Beginn richten wir die Kamera mit einer Live-Logging-Ausgabe über die serielle UART-Verbindung ein, die wir zuvor hergestellt haben (siehe unten).

Dies ermöglichte einen Live-Blick auf die Protokollmeldungen der Anwendungen sowie auf alle zusätzlichen Protokollierungsquellen, die wir benötigten. Aus diesen Informationen haben wir die primäre Binärdatei identifiziert, die verwendet wird, um die Kommunikation zwischen der Kamera und der Cloud herzustellen und die Schnittstellen für den Zugriff auf die Kamera über P2P bereitzustellen.

Diese Binärdatei wird lokal initApp genannt und wird ausgeführt, sobald die Kamera vollständig initialisiert und die Boot-Sequenz abgeschlossen ist. Vor diesem Hintergrund haben wir uns vorgenommen, diese Binärdatei mit einem Debugger auszuführen, um die lokalen Funktionen besser auswerten zu können. Bei dem Versuch, dies zu tun, stießen wir auf einen Kernel-Watchdog, der erkannte, wenn initApp nicht ausgeführt wurde, und die Kamera zwangsweise neu startete, wenn er ein Problem erkannte. Dieser Watchdog prüft, ob Schreibvorgänge in /dev/watchdog vorhanden sind, und löst einen Timer aus, der die Kamera neu startet, wenn die Schreibvorgänge nicht fortgesetzt werden. Dies erschwert das Debuggen, da beim Anhalten der Ausführung von initApp auch die Schreibvorgänge auf den Watchdog pausiert werden. Ein Beispiel für dieses Stoppverhalten ist unten dargestellt:

Um dies zu vermeiden, könnte man einfach versuchen, bei jedem Stopp der initApp an den Watchdog zu schreiben, um den Neustart zu verhindern. Eine weitere sauberere Option besteht jedoch darin, die magische Schließfunktion der Linux Kernel Watchdog Driver API zu nutzen. Kurz gesagt, wenn man ein bestimmtes magisches Zeichen 'V' schreibt, wird /dev/watchdog der Watchdog deaktiviert. Es gibt auch andere Methoden, um den Watchdog zu besiegen, aber diese war diejenige, die wir für unsere Forschung ausgewählt haben, da sie es einfach macht, den Watchdog nach Belieben zu aktivieren und zu deaktivieren.

Wenn der Watchdog deaktiviert ist, ist das Einrichten zum Debuggen von initApp recht einfach. Wir wollten den Code nach Möglichkeit direkt auf der Kamera ausführen, anstatt einen Emulator zu verwenden. Die Architektur der Kamera ist Little Endian MIPS (MIPSEL). Wir hatten das Glück, dass vorgefertigte GDB- und GDBServer-Binärdateien ohne Änderungen funktionieren konnten. Da wir das aber anfangs nicht wussten, haben wir auch eine Toolchain eingerichtet, um den GDBServer speziell für die Kamera zu kompilieren. Eine Technik, die nützlich sein könnte, wenn Sie sich in einer ähnlichen Situation befinden, besteht darin, ein Kompilierungstool wie gcc zu verwenden, um Quellcode für Ihre vermutete Zielarchitektur zu kompilieren und zu prüfen, ob er ausgeführt wird. Siehe das Beispiel unten.

Da uns unser SoC bekannt war, waren wir uns in unserem Fall über die Zielarchitektur ziemlich sicher. In bestimmten Situationen ist dies jedoch möglicherweise nicht so einfach zu entdecken, und die Arbeit mit Hello World-Binärdateien kann nützlich sein, um ein erstes Verständnis aufzubauen. Sobald wir in der Lage waren, Binärdateien zu kompilieren, haben wir GDBServer für unsere Kamera kompiliert und ihn dann zum Anhängen und Starten von initApp verwendet. Dann haben wir uns von einem anderen Computer im selben lokalen Netzwerk wie die Kamera mit ihr verbunden. Ein Beispiel dafür ist unten dargestellt:

Als Hinweis für das obige Beispiel verwenden wir den Parameter -x , um der Einfachheit halber einige Befehle zu übergeben, die jedoch für das Debuggen nicht erforderlich sind. Weitere Informationen zu den Dateien oder Befehlen finden Sie in unserem GitHub-Repository elastic/camera-hacks . Damit initApp ordnungsgemäß geladen werden konnte, mussten wir auch sicherstellen, dass die von der Binärdatei verwendeten Bibliotheken über die Umgebungsvariablen PATH und LD_LIBARY_PATH zugänglich sind. Mit diesem Setup waren wir dann in der Lage, die Binärdatei nach Bedarf zu debuggen. Da wir früher auch die magische Zeichenmethode verwendet haben, um den Watchdog zu besiegen, müssen wir auch sicherstellen, dass wir Instanzen kontrollieren, in denen der Watchdog wieder aktiviert werden kann. In den meisten Fällen wollen wir nicht, dass dies geschieht. Aus diesem Grund haben wir die Watchdog-Aufrufe in initApp überschrieben, sodass der Watchdog während des Debuggens nicht wieder aktiviert wird, wie unten gezeigt.

Das folgende Video zeigt den vollständigen Setup-Prozess vom Booten bis zum Ausführen von GDBServer. Im Video starten wir auch einen neuen initApp-Prozess, und als solcher müssen wir sowohl den ursprünglichen Prozess als auch das daemon.sh Shell-Skript beenden, das einen neuen initApp-Prozess erzeugt, wenn er beendet wird.

Aufbau eines P2P-Clients

Um das volle Ausmaß der Funktionen, die P2P für AJCloud IoT-Geräte bietet, weiter zu erforschen und zu untersuchen, wie sie von Angreifern missbraucht werden können, haben wir uns daran gemacht, unseren eigenen eigenständigen Client zu entwickeln. Dieser Ansatz würde den Aufwand für die Bearbeitung der Wansview Cloud Windows-App beseitigen und es uns gleichzeitig ermöglichen, schneller eine Verbindung zu Kameras herzustellen und Befehle zu testen, die wir aus dem Reverse Engineering der Firmware ableiten.

Aus den Konfigurationsdaten, die wir zuvor aus den Windows-App-Protokollen erhalten haben, wussten wir, dass ein Client im Rahmen des Verbindungsprozesses Anforderungen an bis zu drei verschiedene Server sendet. Diese Server geben den Clients Anweisungen, wohin der Datenverkehr geleitet werden soll, um auf eine bestimmte Kamera zuzugreifen. Wenn Sie mehr von diesen Servern im Freien entdecken möchten, können Sie das Internet mit der folgenden Vier-Byte-UDP-Nutzlast an Port 60722scannen. Paul Marrapese nutzte diese Technik im Rahmen seiner Forschung mit großem Erfolg.

Um eine P2P-Verbindung ordnungsgemäß aufzubauen, muss ein Client zunächst eine einfache Hello-Nachricht (MSG_HELLO) senden, die von einem Peer-to-Peer-Server bestätigt (MSG_HELLO_ACK) werden muss. Der Client fragt dann den Server (MSG_P2P_REQ) nach einer bestimmten deviceId ab. Wenn der Server dieses Gerät kennt, antwortet er dem Client (MSG_PUNCH_TO) mit einer Ziel-IP-Adresse und einem UDP-Portnummernpaar. Der Client versucht dann,MSG_PUNCH_PKT im Rahmen einer UDP-Lochroutine eine Verbindung () mit dem IP- und Port-Paar zusammen mit anderen Ports innerhalb eines vorgegebenen Bereichs herzustellen. Wenn dies erfolgreich ist, sendet das Ziel eine Nachricht (MSG_PUNCH_PKT) an den Client zurück, zusammen mit einer abschließenden Nachricht (MSG_P2P_RDY), um zu bestätigen, dass die Verbindung hergestellt wurde.

Nach dem Verbinden mit einer Kamera sind wir in erster Linie daran interessiert, verschiedene MSG_DRW Pakete zu versenden und ihr Verhalten zu beobachten. Diese Pakete enthalten Befehle, die es uns ermöglichen, die Kamera physisch zu manipulieren, ihre Video- und Audiostreams anzusehen und anzuhören, auf die darin gespeicherten Daten zuzugreifen oder ihre Konfiguration zu ändern. Der einfachste Befehl, mit dem wir begannen, bestand darin, die Kamera gegen den Uhrzeigersinn zu schwenken, was wir leicht als eine einzige Nachrichtenübertragung identifizieren konnten.

Debug-Protokollmeldungen auf der Kamera ermöglichten es uns, leicht zu lokalisieren, wo dieser Befehl innerhalb der Firmware verarbeitet wurde.

Das Auffinden der Quelle dieser speziellen Nachricht versetzte uns in die Hauptroutine, die sich um die Verarbeitung MSG_DRW Nachrichten kümmert, was uns einen kritischen Einblick in die Art und Weise gab, wie dieser Befehl aufgerufen wird und welche anderen Befehle von der Firmware unterstützt werden.

Umfangreiches Reverse Engineering und Tests ermöglichten es uns, einen PoC-P2P-Client zu entwickeln, der es Benutzern ermöglicht, sich mit jeder Kamera auf der AJCloud-Plattform zu verbinden, sofern sie Zugriff auf deren deviceId haben. Zu den grundlegenden Befehlen, die vom Client unterstützt werden, gehören das Schwenken und Neigen der Kamera, das Neustarten, das Zurücksetzen, das Abspielen von Audioclips und sogar das Abstürzen der Firmware.

Die gefährlichste Funktion, die wir implementieren konnten, war durch einen Befehl, der eine Konfigurationsdatei für ein Kerngerät ändert: /var/syscfg/config_default/app_ajy_sn.ini. Auf unserer Testkamera sah der Inhalt der Datei ursprünglich wie folgt aus:

[common]
product_name=Q5
model=NAV
vendor=WVC
serialnum=WVCD7HUJWJNXEKXF
macaddress=
wifimacaddress=

Diese Datei scheint zwar grundlegende Gerätemetadaten zu enthalten, aber diese Datei ist das einzige Mittel, mit dem sich die Kamera identifizieren kann. Beim Start liest die Kamera den Inhalt dieser Datei ein und versucht dann, über eine Reihe von Curl-Anfragen an verschiedene API-Endpunkte eine Verbindung zur AJCloud-Plattform herzustellen. Diese curl-Anforderungen übergeben den Produktnamen, das Kameramodell, den Herstellercode und die Seriennummernwerte, die aus der INI-Datei extrahiert wurden, als Argumente für die Abfragezeichenfolge. Wir haben unseren Client verwendet, um eine Nachricht zu übermitteln, die den Inhalt wie folgt überschreibt:

[common]
product_name=
model=OPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~HH01
vendor=YZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~HH01
serialnum=defghijklmnopqrstuvwxyz{|}~HH01
macaddress=
wifimacaddress=

Nach dem Zurücksetzen der Kamera schlagen alle Curl-Anforderungen, die als Teil der Startroutine an die API-Endpunkte der AJCloud-Plattform ausgegeben werden, aufgrund der in der INI-Datei enthaltenen fehlerhaften Daten fehl. Diese Anfragen werden weiterhin regelmäßig gesendet, aber sie werden nie erfolgreich sein, und die Kamera bleibt inaktiv und über Apps nicht zugänglich. Leider gibt es keine einfache Möglichkeit, den vorherigen Dateiinhalt wiederherzustellen, indem Sie die Kamera zurücksetzen, die Firmware aktualisieren oder die Werkseinstellungen wiederherstellen. Dateiänderungen, die mit diesem Befehl vorgenommen werden, führen dazu, dass eine Kamera effektiv gemauert und unbrauchbar wird.

Wenn wir uns die dekompilierte Funktion (syscfg_setAjySnParams), die die in app_ajy_sn.inigespeicherten Werte überschreibt, genauer ansehen, können wir sehen, dass Eingabeparameter, die aus dem MSG_DRW -Befehl extrahiert wurden, verwendet werden, um String-Daten weiterzugeben, die zum Überschreiben der Felder Modell, Hersteller und Seriennummer in der Datei verwendet werden. memset wird verwendet, um drei globale Variablen, die diese Eingabezeichenfolgen speichern sollen, mit Null-Bytes zu überschreiben. strcpy wird dann verwendet, um die Eingabeparameter in diese Globals zu übertragen. In jedem Fall führt dies dazu, dass Bytes direkt aus dem MSG_DRW Befehlspuffer kopiert werden, bis ein NULL-Zeichen gefunden wird.

Da keine Validierung der Länge dieser Eingabeparameter erzwungen wird, die aus dem Befehl extrahiert werden, ist es trivial, eine Nachricht von ausreichender Länge zu erstellen, die einen Pufferüberlauf auslöst. Obwohl wir diese Schwachstelle nicht als Teil unseres Angriffs ausgenutzt haben, um die Kamera zu blockieren, scheint dies ein Fall zu sein, in dem ein Exploit entwickelt werden könnte, der es einem Angreifer ermöglichen würde, Remote-Codeausführung auf der Kamera zu erreichen.

Auswirkungen

Wir haben bestätigt, dass eine breite Palette von Geräten verschiedener Hersteller, die mit AJCloud verbunden sind, und verschiedene Firmware-Versionen von diesen Schwachstellen und Fehlern betroffen sind. Insgesamt haben wir unsere Angriffe gegen fünfzehn verschiedene Kameraprodukte von Wansview, Galayou, Cinnado und Faleemi erfolgreich demonstriert. Basierend auf unseren Erkenntnissen kann davon ausgegangen werden, dass alle Geräte, die AJCloud-Firmware betreiben und sich mit der AJCloud-Plattform verbinden, betroffen sind.

Alle Versuche, sowohl AJCloud als auch Wansview zu kontaktieren, um diese Schwachstellen und Fehler offenzulegen, waren erfolglos.

Was haben die Anbieter richtig gemacht?

Trotz der Schwachstellen, die wir zuvor entdeckt und besprochen haben, gibt es eine Reihe von Sicherheitskontrollen, die AJCloud und die Kamerahersteller gut implementiert haben. Für ein so kostengünstiges Gerät wurden viele Best Practices implementiert. Erstens wird die Netzwerkkommunikation durch eine zertifikatsbasierte WebSocket-Authentifizierung gut gesichert. Neben der zusätzlichen Verschlüsselung macht die Platzierung vieler API-Endpunkte hinter der Zertifikatauthentifizierung Man-in-the-Middle-Angriffe erheblich schwieriger. Darüber hinaus wurden die APKs für die mobilen Apps signiert und verschleiert, was die Bearbeitung dieser Apps sehr zeitaufwändig machte.

Darüber hinaus trafen die Anbieter auch einige fundierte Entscheidungen bei der Kamera-Hardware und -Firmware. Das lokale Betriebssystem für die Kamera ist effektiv begrenzt und konzentriert sich nur auf die für das Produkt benötigte Funktionalität. Das Dateisystem ist so konfiguriert, dass es schreibgeschützt ist, außerhalb der Protokollierung, und der Kernel-Watchdog ist eine effektive Methode, um die Betriebszeit sicherzustellen und das Risiko zu verringern, in einem fehlerhaften Zustand stecken zu bleiben. Der Ingenic Xburst T31 SoC bietet eine leistungsfähige Plattform mit einer breiten Palette an Unterstützung, einschließlich Secure Boot, einem Power-On Reset (POR)-Watchdog und einem separaten RISC-V-Prozessor, der in der Lage ist, rudimentäres maschinelles Lernen auf dem Kameraeingang auszuführen.

Was haben die Anbieter falsch gemacht?

Leider gab es eine Reihe von verpassten Gelegenheiten mit diesen verfügbaren Funktionen. Der potenziell ungeheuerlichste ist der nicht authentifizierte Cloud-Zugriff. Angesichts der API-Zugriffskontrollen, die für viele der Endpunkte eingerichtet wurden, ist es ein großer und vermeidbarer Fehler, dass die Zugriffsendpunkte für den Kamerabenutzer über die Seriennummer ohne Authentifizierung verfügbar sind. Das P2P-Protokoll ist ebenfalls verwundbar, wie wir vorgestellt haben, aber im Vergleich zum API-Zugriff, der sofort reparierbar sein sollte, kann dies einige Zeit länger dauern, um das Protokoll zu reparieren. Es ist eine sehr gefährliche Schwachstelle, aber sie ist ein wenig verständlicher, da sie erheblich mehr Zeit erfordert, um sie zu entdecken und zu beheben.

Auf der Anwendungsseite liegt das Hauptproblem bei der Windows-App, die über eine umfangreiche Debugprotokollierung verfügt, die vor der öffentlichen Veröffentlichung hätte entfernt werden sollen. Was die Hardware betrifft, so kann sie mit physischem Zugang (freiliegende Reset-Taste usw.) leicht manipuliert werden. Dies ist angesichts der Zielgruppe nicht so sehr ein Problem. Es wird erwartet, dass es eher auf der Seite der Benutzerfreundlichkeit als der Sicherheit irrt, insbesondere angesichts des physischen Zugriffs auf das Gerät. In ähnlicher Weise sollte Secure Boot aktiviert sein, insbesondere angesichts der Tatsache, dass der T31-SoC dies unterstützt. Dies ist zwar nicht unbedingt erforderlich, würde es jedoch erheblich erschweren, den Quellcode und die Firmware des Geräts direkt zu debuggen, was es schwieriger macht, möglicherweise vorhandene Schwachstellen zu entdecken. Im Idealfall wäre es so implementiert, dass der Bootloader immer noch ein nicht signiertes Betriebssystem laden könnte, um ein einfacheres Basteln und Entwickeln zu ermöglichen, aber das Laden des signierten Betriebssystems verhindern würde, bis die Bootloader-Konfiguration wiederhergestellt ist. Ein wesentlicher Fehler in der aktuellen Firmware ist jedoch die Abhängigkeit von der ursprünglichen Seriennummer, die nicht in einem schreibgeschützten Bereitstellungspunkt gespeichert wird, während das System ausgeführt wird. Das Manipulieren der Seriennummer sollte das Gerät nicht dauerhaft beschädigen. Es sollte entweder über einen Mechanismus verfügen, mit dem eine neue Seriennummer angefordert werden kann (oder die ursprüngliche Seriennummer wiederhergestellt werden kann), falls die Seriennummer überschrieben wird, oder die Seriennummer sollte unveränderlich sein.

Gegenmaßnahmen

Um die Angriffsfläche zu verringern und mögliche nachteilige Auswirkungen im Falle eines Angriffs zu begrenzen, können bestimmte Maßnahmen ergriffen werden, die jedoch in ihrer Wirksamkeit variieren.

Die Segmentierung von Wi-Fi-Kameras und anderen IoT-Geräten vom Rest Ihres Netzwerks ist eine dringend empfohlene Gegenmaßnahme, um zu verhindern, dass Angreifer seitlich auf kritischere Systeme ausweichen. Dieser Ansatz hindert einen Angreifer jedoch nicht daran, an vertrauliche Benutzerdaten zu gelangen, indem er die von uns entdeckte Zugriffskontrollschwachstelle in der AJCloud-Plattform ausnutzt. Wenn man bedenkt, wie einfach wir zeigen konnten, wie Kameras über P2P aus der Ferne aufgerufen und manipuliert werden können, ist jedes Gerät, das mit der AJCloud-Plattform verbunden ist, unabhängig von seiner lokalen Netzwerkkonfiguration immer noch einem erheblichen Kompromittierungsrisiko ausgesetzt.

Eine Einschränkung der gesamten Netzwerkkommunikation zu und von diesen Kameras wäre nicht machbar, da die Konnektivität zur AJCloud-Plattform für ihren Betrieb unerlässlich ist. Wie bereits erwähnt, funktionieren die Geräte einfach nicht, wenn sie beim Start keine Verbindung zu verschiedenen API-Endpunkten herstellen können.

Ein praktikabler Ansatz könnte darin bestehen, die Kommunikation über die anfängliche Startroutine hinaus einzuschränken. Dies würde jedoch den Fernzugriff und die Fernsteuerung über mobile und Desktop-Apps verhindern, was den gesamten Zweck dieser Kameras von vornherein zunichte machen würde. Weitere Informationen zu diesem Thema finden Sie unter "Blocking Without Breaking: Identification and Mitigation of Non-Essential IoT Traffic", in dem dieser Ansatz für eine Vielzahl von IoT-Geräten und -Anbietern eingehender untersucht wurde.

Der beste Ansatz, um jede Wi-Fi-Kamera, unabhängig vom Anbieter, zu sichern und gleichzeitig die Kernfunktionalität beizubehalten, besteht darin, sie mit alternativer Open-Source-Firmware wie OpenIPC oder thingino zu flashen. Der Wechsel zu Open-Source-Firmware vermeidet die Kopfschmerzen, die mit der erzwungenen Konnektivität zu Cloud-Plattformen von Anbietern verbunden sind, indem den Benutzern eine detaillierte Kontrolle über die Gerätekonfiguration und den Remote-Netzwerkzugriff ermöglicht wird. Der offene Zugriff auf die Firmware-Quelle trägt dazu bei, dass kritische Fehler und Schwachstellen schnell identifiziert und von fleißigen Projektmitarbeitern gepatcht werden.

Wichtigste Erkenntnisse

Unsere Recherchen haben mehrere kritische Schwachstellen aufgedeckt, die sich über alle Aspekte von Kameras erstrecken, die AJCloud-Firmware ausführen und mit ihrer Plattform verbunden sind. Erhebliche Mängel im Zugriffskontrollmanagement auf ihrer Plattform und dem PPPP-Peer-Protokoll bieten eine ausgedehnte Angriffsfläche, die Millionen von aktiven Geräten auf der ganzen Welt betrifft. Die Ausnutzung dieser Fehler und Schwachstellen führt zur Offenlegung sensibler Benutzerdaten und ermöglicht Angreifern die vollständige Fernsteuerung jeder Kamera, die mit der AJCloud-Plattform verbunden ist. Darüber hinaus kann ein integrierter P2P-Befehl, der absichtlich willkürlichen Schreibzugriff auf eine Schlüsselkonfigurationsdatei gewährt, genutzt werden, um entweder Kameras dauerhaft zu deaktivieren oder die Remote-Codeausführung durch Auslösen eines Pufferüberlaufs zu erleichtern.

Bitte besuchen Sie unser GitHub-Repository für benutzerdefinierte Tools und Skripte, die wir zusammen mit Daten und Notizen erstellt haben, die wir erfasst haben und von denen wir glauben, dass sie der Sicherheitsforschungsgemeinschaft den größten Nutzen bringen würden.