Ich wollte meinen Hund überwachen – und habe stattdessen TP-Link überwacht

• Ich habe eine Tapo-Kamera gekauft, um meinen Hund im Haus zu beobachten, und dabei unerwartet die Funktionsweise von TP-Link-Geräten und der App rückwärts analysiert
• Um den Onboarding-Prozess und die Struktur der verschlüsselten API-Kommunikation zu untersuchen, kamen verschiedene Techniken zum Einsatz, darunter MITM, APK-Decompiling und das Erstellen von Entschlüsselungsskripten
• Durch die Entdeckung des initialen Administrator-Passworts und des Ableitungsprozesses für Sitzungsschlüssel konnten verschlüsselte Nachrichten entschlüsselt und Probleme mit der unzuverlässigen Synchronisierung zwischen Gerät und Cloud-Konto erkannt werden
• Durch die Analyse des gesamten Onboarding-Ablaufs wurden die wichtigsten API-Aufrufe, Kontenerstellung, Passwortänderung und der Wi‑Fi-Verbindungsprozess per Bash-Skript automatisiert
• Es werden Schwachstellen im Sicherheitsdesign der Tapo-Firmware, eine wenig ausgereifte Verschlüsselungsimplementierung und eine unregelmäßige Kontensynchronisierung aufgezeigt – typische Merkmale günstiger IoT-Geräte

---

Projektüberblick

• Der Autor kaufte und nutzte eine günstige Tapo-Kamera zur Beobachtung seines Hundes in der Wohnung
• Während der Nutzung führten umständliche Einrichtung und mangelnde verfügbare Informationen im Netz dazu, dass er die Funktionsweise des Produkts genauer untersuchte
• Unerwartete Probleme bei der Integration mit frigate und beim Aktivieren von 2way audio weckten das Interesse an einer direkten Onboarding-Methode ohne Cloud-Anbindung

Analyse von Onboarding- und Authentifizierungsstruktur

• Um den Verbindungsprozess der Tapo-Kamera zu analysieren, wurden MITM proxy und das dynamische Hooking-Tool frida verwendet, um den Datenverkehr zwischen App und Kamera abzufangen
  • Da aktuelle Apps häufig Schutzmechanismen wie Proxy-Ignorierung und certificate pinning besitzen, ist ein Ansatz mit dynamischen Tools wirksam
• Nach dem Einrichten dieser Umgehungsstruktur konnte im Onboarding-Flow der Kamera der Vorgang des Default-Logins mit dem Administrator-Konto genau nachvollzogen werden
• Es wurde festgestellt, dass die Default-Login-API unabhängig vom Passwort des Cloud-Kontos mit einem gerätespezifischen Standardpasswort arbeitet

Verschlüsselungsstruktur und Suche nach dem Standardpasswort

• Durch APK-Decompiling (mit JADX) und Codeanalyse wurde das Standardpasswort des admin-Kontos (TPL075526460603) ermittelt
• Dass bereits verknüpfte Kamerageräte selbst nach einer Änderung des Cloud-Passworts diese Änderung nicht erkennen, bestätigte die fehlerhafte Passwortsynchronisierung zwischen App und Kamera
• Nachdem das Standardpasswort bekannt war, konnte durch Implementierung der Ableitungslogik für die Sitzungsschlüssel (lsk, ivb) die verschlüsselte API-Kommunikation in Echtzeit entschlüsselt werden

mitmproxy-Skripting und API-Analyse

• Unter Bezug auf das Open-Source-Projekt PyTapo wurde der tatsächliche API-Ablauf des Tapo-Onboardings präzise analysiert
• Mit dem Skript tapo_decrypt_pretty.py wurden
  • der Login-Handshake erkannt
  • Sitzungsschlüssel extrahiert
  • verschlüsselte APIs entschlüsselt und gut lesbar ausgegeben sowie als JSON gespeichert
• Aus der vollständigen Liste der Onboarding-API-Aufrufe wurden nur die relevanten Hauptschritte ausgewählt und daraus ein automatisierter Workflow erstellt
  • Wi‑Fi-Liste abrufen (scanApList)
  • RTSP/ONVIF-Konto aktivieren
  • Administrator-Passwort ändern
  • Wi‑Fi verbinden

Automatisierung und Ergebnisse

• Mit dem Bash-Skript (tapo_onboard.sh) wurde der gesamte oben beschriebene Onboarding-Prozess vollautomatisch ausgeführt
  • Standard-Login als admin
  • Wi‑Fi auswählen und verbinden
  • Logo aus dem Kamerafeed entfernen
  • RTSP/ONVIF aktivieren
  • Administrator-Passwort zurücksetzen
• In der Struktur der Kamera-Firmware wurden folgende Eigenschaften und Schwachstellen festgestellt
  • Einige APIs verwenden SHA-256-Hashes, andere behalten veraltete Verfahren wie MD5 bei
  • Es existieren 2 öffentliche Schlüssel, aber es ist unklar, in welcher Situation welcher Schlüssel verwendet werden soll
  • Die Passwortsynchronisierung zwischen App und Gerät ist äußerst instabil

Fazit und Eindruck

• Die Sicherheitsstruktur von Tapo-Kamera-Firmware und API wirkt provisorisch und wenig ausgereift
• Das Projekt vermittelte indirekt praktische Einblicke in Sicherheitslücken günstiger IoT-Geräte und die Realität unvollständiger Onboarding-Systeme
• Das eigentliche Ziel des Projekts – den Hund zu überprüfen – wurde erreicht; zu sehen war meist, wie der Hund auf dem Sofa oder dem Bett schläft

[helio]

CVE-2022-37255, also 7,5 Punkte.

[GN⁺]

Hacker-News-Kommentare

• Faszinierend, dass mein Frida-Skript verwendet wurde; das Skript ist hier zu finden. Es freut mich, dass es in der Praxis gut zu funktionieren scheint. Falls du etwas ergänzt oder verändert hast, würde ich das gern hören.

  • Ich finde HTTP Toolkit ein wirklich großartiges Tool; hervorragende Arbeit von Tim.
  • Von allen Tools, die ich benutzt habe, ist HTTP Toolkit meiner Meinung nach das beste. Ich habe auch mit mitmproxy, Proxyman und Charles Proxy gearbeitet, aber HTTP Toolkit war am besten, und es ist Open Source.

• Zur Info: Wenn man bidirektionales Audio in Frigate nutzen will, muss man in go2rtc für den Hauptstream tapo:// statt des üblichen rtsp:// konfigurieren. TP-Link bietet bidirektionales Audio nur über die eigene API an. Das ist lästig, weil damit ONVIF (für die Schwenk-/Neigesteuerung der Kamera mit Open-Source-Tools) nicht funktioniert. Wenn man beides nutzen will, braucht man einen ziemlich aggressiven Workflow: Lesen des tapo://-Streams stoppen → ONVIF-Client starten / schwenken-neigen → ONVIF beenden → tapo:// wieder starten.

• Ich halte IoT-Sicherheit insgesamt für ein einziges Chaos. Besonders besorgniserregend ist, dass Consumer-Router undurchsichtige Blackboxes sind, die den gesamten Netzwerkverkehr verarbeiten und sich nicht auditieren lassen. Den meisten Leuten ist nicht bewusst, dass ihre Router-Firmware oft seit Jahren keine Updates mehr bekommen hat und bereits bekannte Schwachstellen enthält. Das Vertrauensmodell der Lieferkette bei Netzwerkhardware ist meiner Meinung nach komplett kaputt.

  • Ich stimme zu, dass IoT-Sicherheit schlecht ist. Für mich persönlich wäre es oft schon genug, wenn ein IoT-Gerät einfach zuverlässig verbunden bleibt, und manchmal würde ich sogar lieber einen Exploit nutzen, um Online-only-Beschränkungen zu umgehen. Es gibt aber auch echte Anwendungsfälle für Cloud-angebundenes IoT. Deshalb finde ich, dass ein Gerät beim ersten Einrichten den Nutzer fragen und dann ausschließlich im gewählten Modus arbeiten sollte. Wenn jemand Cloud-MFA braucht, sollte das möglich sein; wenn man das Gerät einfach nur per Programmierung steuern will, sollte es offline bleiben können.
  • Zwischen Nutzer und Ziel gibt es unzählige Router, und man kann nicht alle überwachen. Endgeräte gehen ohnehin davon aus, dass Router kompromittiert sein könnten, und senden deshalb alle Daten verifiziert und verschlüsselt. Solange der Router nicht für DDoS oder Krypto-Mining missbraucht wird, halte ich dessen Sicherheit an sich für nicht besonders aussagekräftig.
  • Die meisten Leute verwenden den vom ISP bereitgestellten und vorkonfigurierten Router, sodass man faktisch nur eine Blackbox mit einer anderen Blackbox verbindet. Wenn ich sehe, dass Leute beim WLAN einfach die vom ISP vorgegebene SSID und das Passwort übernehmen, überrascht mich immer wieder, wie viel Macht sie ihrem ISP überlassen.
  • Für normale Consumer-Produkte stimmt das, aber bei Prosumer-Hardware wie Ubiquiti oder Mikrotik bekommt man meiner Meinung nach schnelle Security-Updates und verlässlichen Firmware-Support.

• Ich fand diesen Blogpost außergewöhnlich gut geschrieben. Heutzutage sind viele Texte in diesem Stil von LLMs erzeugt und oft unangenehm zu lesen, aber dieser hier hält die Balance zwischen technischer Tiefe und angenehmer Lesbarkeit beeindruckend gut. (Ich weiß, dass das Titelbild KI-generiert ist, aber das hat für mich nichts mit der Qualität des Textes zu tun.)

  • Ich blockiere mit uBlock Origin standardmäßig große Mediendateien, um Ressourcen zu sparen. Titelbilder werden bei mir oft sowieso blockiert und bringen kaum Nutzen. Es stimmt mich eher traurig, dass Leute heute überhaupt Ressourcen darauf verwenden, so etwas zu generieren.

• Ich frage mich, ob sich Tools wie Frida und mitmproxy auch künftig noch bei Android-Apps einsetzen lassen und was passiert, wenn nächstes Jahr die Signaturanforderungen greifen.

  • Im Großen und Ganzen wird es wohl weiter möglich sein, aber Apps, die Attestation verlangen, werden deutlich schwieriger. Schon jetzt lassen sich Geräte, die OEM-Unlock und Root erlauben, etwa Pixel-Geräte, weiterhin gut für Entwicklerzwecke nutzen. Allerdings werden solche Geräte als entsperrt markiert und bestehen die Google-Attestation nicht. Man wird Apps vermutlich weiterhin entpacken, Frida injizieren und sie mit einem Entwicklerkonto sideloaden können, ähnlich wie unter iOS. Aber auch dann bleibt man von fehlgeschlagener Attestation sowie Anti-Tampering- und Anti-Debugging-Maßnahmen betroffen.
  • Ich erwarte eigentlich nicht, dass solche Änderungen direkte große Auswirkungen haben, weil Reverse Engineering meist auf gerooteten Geräten oder Emulatoren stattfindet. Seltener gibt es Fälle, in denen Frida auf nicht gerooteten Geräten per Gadget in die APK injiziert wird; das wird schwieriger, aber es wird wohl weiterhin Wege geben, APKs im Entwicklermodus zu bauen und zu installieren. Würde man das vollständig blockieren, wäre Android-App-Entwicklung praktisch unmöglich. Vermutlich wird Sideloading also auf normalen Nutzergeräten eingeschränkt, während Dinge wie zusätzliche Entwicklerzertifikate weiter erlaubt bleiben. Schwieriger wird am Ende vor allem die echte App-Verteilung; Entwicklung und Reverse Engineering dürften weiter möglich bleiben. Die größere Bedrohung ist eher die Ausweitung von Device Attestation. Immer mehr Apps könnten auf gerooteten oder inoffiziellen Geräten aggressiv prüfen, ob es sich um ein unverändertes Gerät handelt. Im Moment betrifft das vor allem große Finanz-Apps. Die Zahl der Leute, die sich darum ernsthaft kümmern müssen (zum Beispiel GrapheneOS-Nutzer), ist noch klein, und zusätzliche Serverkosten erschweren eine breite Einführung, aber künftig könnte sich das ändern.
  • Tatsächlich ist der Einsatz von Frida schon heute nicht einfach. Für Frida braucht man Root, und Root wird bei immer mehr Modellen praktisch unmöglich. Außerdem gibt es sehr starke SDKs zur Root-Erkennung und Gegenmaßnahmen zu Play Integrity.

• Zur Einordnung gibt es dazu auch The Tapo C200 research project und PyTapo: eine Python-Bibliothek für Tapo-Kameras.

• Weiteres verwandtes Material: (TP-Link-Firmware-Entschlüsselung und Analyse des Bootloaders der Cloud-Kamera C210 V2) gibt es hier.

• Vielleicht bewegt sich der Hund des OP vom Bett auf den Boden, weil die Heizung bzw. der Radiator angeht; dafür bräuchte man wohl zusätzliche Sensordaten.

  • Oder ihm ist einfach kalt.

• Ich habe das Gefühl, wir sind inzwischen an dem Punkt, an dem ein fest eincodiertes Administratorpasswort niemanden mehr besonders überrascht.

  • Soweit ich es verstehe, ist es nur ein fest eincodiertes Standardpasswort und keine permanente Backdoor. Laut dem Artikel wird das Passwort beim Onboarding vom Nutzer geändert. So arbeiten die meisten Apps.
  • Solange das Passwort im normalen Einrichtungsprozess geändert wird, sehe ich darin kein großes Problem. Nachdem ich in den letzten fünf Jahren versucht habe, mein Zuhause mit möglichst vielen IoT-/Smart-Home-Geräten auszustatten, ist mein Eindruck: Fast alle Anbieter verkaufen Produkte mit fragwürdiger Funktionalität, und ein wirklich gutes Smart Home aufzubauen ist extrem schwierig, wenn man nicht alles bei einem Hersteller bündelt. Und selbst die besseren Anbieter decken nicht alle individuellen Bedürfnisse ab. Auf meinem Smartphone sind Apps von Ecobee, Lutron, Hue, mehreren Kameraherstellern, Meross, Smart Life und anderen installiert. Nur Lutron und Hue lassen sich direkt über Hub/HomeKit steuern, sodass man die jeweilige App gar nicht öffnen muss. Matter und Thread gibt es schon lange als Standards, trotzdem ist der Markt weiterhin voller billiger WLAN-basierter Geräte statt wirklich kompatibler Produkte. Die meisten sind schlecht und lassen sich nur über Apps verwalten, die einen in Cloud-Dienste drängen sollen. Dass ich gleich vier Kameras gekauft habe, ist teilweise mein eigener Fehler, aber letztlich haben verschiedene Anbieter eben unterschiedliche Stärken, sodass Verbraucher kaum darum herumkommen, gemischt einzukaufen.
  • Ein fest eincodiertes Administratorpasswort, das man vor der Nutzung zwingend ändern muss, halte ich an sich nicht für ein großes Problem.
  • Ehrlich gesagt bin ich wohl einfach nur grundlos von dieser Technik genervt; in diesem Fall ist das hier kein wirklicher Mangel.
  • Man könnte auch argumentieren, dass Smartphones die ursprünglichen wirklich feindseligen Geräte sind; bei Netzwerkgeräten kann man wenigstens noch eher nachvollziehen oder entdecken, was vor sich geht.

• Ich hätte gern eine Referenzübersicht dazu, welche Tapo-Kameras RTSP unterstützen. Die C210 funktioniert einigermaßen gut (Cloud-Capture geht nicht) und läuft bei mir in Frigate. Heute habe ich die C402 (Outdoor-Modell) gekauft, aber dort fehlt in den erweiterten Einstellungen ein Kamera-Account. Der niedrige Preis ist attraktiv, aber die Funktionskonsistenz lässt zu wünschen übrig. Falls jemand eine gute, günstige Outdoor-Kamera empfehlen kann, die RTSP-Streams unterstützt und sich mit einem Solarpanel betreiben lässt, wäre ich dankbar.

  • Auch wenn die Kamera rtsp:// nicht unterstützt, sollte es möglich sein, tapo:// als go2rtc-Streamquelle zu verwenden. Ich habe meine Frigate-Konfiguration als Referenz hier hinterlegt.