TP-Link Tapo C200: Hartcodierter Schlüssel, Buffer Overflow und Datenschutz im Zeitalter der KI-gestützten Reverse-Engineering

• Eine Analyse der Firmware der günstigen TP-Link Tapo C200 IP-Kamera mittels KI-gestütztem Reverse-Engineering hat mehrere Sicherheitslücken aufgedeckt
• Die Firmware enthält einen hartcodierten privaten SSL-Schlüssel, wodurch innerhalb desselben Netzwerks eine Entschlüsselung des HTTPS-Datenverkehrs möglich ist
• Im Analyseprozess wurden KI-Tools (Grok, GhidraMCP, Cline usw.) eingesetzt, um die Firmware-Struktur zu erfassen und die Bedeutung von Funktionen automatisiert zu analysieren
• Zu den wichtigsten entdeckten Schwachstellen zählen Buffer Overflow (CVE-2025-8065), Integer Overflow (CVE-2025-14299) und WiFi-Hijacking (CVE-2025-14300); einige davon sind per Remote-Angriff ohne Authentifizierung ausnutzbar
• Der Fall gilt als Beispiel dafür, dass KI die Effizienz der Sicherheitsforschung steigert und zugleich die strukturellen Schwächen von IoT-Geräten offenlegt

---

Beschaffung und Entschlüsselung der Firmware

• Durch Reverse Engineering der Tapo-Android-App wurde ein öffentlich zugänglicher S3-Bucket von TP-Link entdeckt, aus dem sich die Firmware aller Geräte ohne Authentifizierung herunterladen lässt
  • Beispielbefehl: aws s3 ls s3://download.tplinkcloud.com/ --no-sign-request --recursive
• Die Firmware wurde mit dem Tool tp-link-decrypt entschlüsselt
  • Der RSA-Schlüssel lässt sich aus den von TP-Link im Rahmen der GPL veröffentlichten Quelltexten extrahieren
• Die entschlüsselte Firmware besteht aus Bootloader, Kernel und SquashFS-Root-Dateisystem

KI-gestütztes Reverse Engineering

• Die Firmware-Analyse wurde mit Ghidra, GhidraMCP, Cline und Anthropic Opus/Sonnet 4 automatisiert
• Die KI erklärte die Rolle von Funktionen und benannte Variablen sinnvoll um, was die Lesbarkeit des Codes verbesserte
• Auf diesem Weg wurden HTTP-Handler, Discovery-Protokoll und Verschlüsselungsroutinen kartiert
• Es wurde bestätigt, dass der private SSL-Schlüssel in der Firmware nicht beim Booten erzeugt, sondern fest eingebettet ist
  • Ein Angreifer im selben Netzwerk kann dadurch den HTTPS-Datenverkehr entschlüsseln

Wichtige Schwachstellen

• CVE-2025-8065 (Speicherüberlauf im ONVIF-SOAP-XML-Parser)

  • Im /bin/main-Server auf Port 2020 fehlt eine Grenzprüfung für die Anzahl von XML-Elementen
  • Beim Senden großer Mengen von XML-Anfragen kommt es zu Speicherüberlauf und Absturz der Kamera
  • CVSS-v4.0-Wert 7.1 (High)

• CVE-2025-14299 (Integer Overflow bei HTTPS Content-Length)

  • Der HTTPS-Server auf Port 443 verarbeitet den Header Content-Length ohne Prüfung mit atoi()
  • Auf 32-Bit-Systemen führt das zu einem Absturz durch Overflow
  • CVSS-v4.0-Wert 7.1 (High)

• CVE-2025-14300 (WiFi-Hijacking)

  • Die API connectAp ist ohne Authentifizierung zugänglich und bleibt auch nach Abschluss der Einrichtung aktiv
  • Angreifer können die Kamera mit einem vom Angreifer kontrollierten Netzwerk verbinden und dadurch Videodatenverkehr abfangen
  • CVSS-v4.0-Wert 8.7 (High)

• WiFi-Scan-API ohne Authentifizierung (scanApList)

  • Gibt SSID, BSSID, Signalstärke und Sicherheitseinstellungen umliegender WiFi-Netze zurück
  • Mit Diensten wie Apple BSSID Locator ist eine präzise GPS-Ortung möglich
  • Ein Remote-Angreifer kann dadurch den tatsächlichen Standort der Kamera ermitteln

Offenlegung und Reaktion

• Erste Meldung an das Sicherheitsteam von TP-Link am 22. Juli 2025, einschließlich PoC und Video
• Nach 150 Tagen (19. Dezember) wurde die Schwachstelle veröffentlicht; anschließend veröffentlichte TP-Link eine Sicherheitswarnung
• TP-Link besitzt die Befugnis zur eigenen CVE-Vergabe (CNA) und kontrolliert damit das Verfahren zur Meldung und Offenlegung von Schwachstellen in den eigenen Produkten direkt selbst
• Auf der eigenen Website wird die niedrigere Zahl an CVEs im Vergleich zu Wettbewerbern als Marketingkennzahl verwendet; kritisiert wird eine Interessenkonflikt-Struktur

Fazit

• KI-Tools maximieren die Effizienz des Reverse Engineerings und senken die Einstiegshürde für Sicherheitsforschung
• Zugleich zeigen hartcodierte Schlüssel, APIs ohne Authentifizierung und anfällige Parser-Strukturen das grundsätzliche Fehlen von Sicherheit bei IoT-Geräten
• Der Fall TP-Link zeigt beispielhaft das Spannungsverhältnis zwischen Sicherheitsforschung im KI-Zeitalter und der Verantwortung von Herstellern