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

 (evilsocket.net)
1 Punkte von GN⁺ 2025-12-21 | 1 Kommentare | Auf WhatsApp teilen
  • 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

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-21
Hacker-News-Kommentare

  • Schade, dass solche Artikel echte Fehlleistungen mit Problemen vermischen, an denen sogar FAANG scheitert.
    Vor allem den Punkt „Das Firmware-Repository von TP-Link lag in einem öffentlich zugänglichen S3-Bucket ohne Authentifizierung“ kritisch zu behandeln, ist der falsche Ansatz.
    Ich halte das eher für ein gutes Beispiel dafür, Security through Obscurity zu vermeiden.
    Solche Artikel könnten das Management im Gegenteil dazu verleiten, falsche Anweisungen zum „stärkeren Abschließen“ zu geben.

    • Der Artikel selbst war leicht zu lesen, aber man merkte einen Tonfall wie von einem LLM geschrieben.
      Von KI geschriebene Texte haben oft zu wenig feine Nuancen und neigen dazu, alles übertrieben als neu oder als klar gut bzw. schlecht darzustellen.
      Es ist kein schlechter Text, aber man sollte ihn mit Vorsicht lesen. Die meisten Artikel, die heute auf HN auftauchen, wirken, als hätten sie KI-Unterstützung bekommen.
    • Auf die Aussage „Das Firmware-Repository ist öffentlich“ kam der scherzhafte Einwurf: „Lasst uns besser nicht über Linux reden.“
    • Solche Reverse-Engineering-Blogs sind einfach eine unterhaltsame und lehrreiche Art, Geschichten zu erzählen.
      Ich habe selbst schon mehrfach solche Artikel geschrieben, und dieser hier war wirklich interessant.
      Eigentlich ist „Wie kam man an die Firmware?“ in dieser Geschichte der am wenigsten wichtige Teil.
    • Ich habe bei dem Punkt, dass die Firmware öffentlich verfügbar ist, überhaupt keinen negativen Unterton wahrgenommen. Mich würde interessieren, ob andere das anders empfunden haben.
    • Ich finde, Firmware sollte immer öffentlich sein. Das ist der richtige Weg.

  • Wahrscheinlich teilen die meisten anderen Kameramodelle ähnliche Sicherheitslücken.
    Laut der TP-Link-Community-Seite wird für die C200 die neueste Firmware als 1.4.4 angezeigt, im Artikel ist jedoch von 1.4.2 die Rede.
    Das heißt: Es gab zwar einige Updates, aber offenbar keine Security-Patches.

    • Als ich früher einmal ein Zyxel-Produkt analysiert habe, bin ich zum gleichen Schluss gekommen.
      Viele Hersteller verkaufen im Grunde gemeinsame Hardware unter anderem Markennamen.
      Passende Analyseartikel: Part 1, Part 2
    • Für lokale Verbindungen sind solche Kameras geeignet, für normale Nutzer gibt es aber weiterhin deutliche Usability-Probleme.

  • Genau deshalb ist IoT-Netzwerksegmentierung unverzichtbar.
    Alle Smart-Kameras und IoT-Geräte sollten in ein eigenes VLAN, und der Internetzugang sollte per Firewall eingeschränkt werden.
    Empfohlene Einstellungen für Nutzer von TP-Link-Kameras:

    1. UPnP im Router deaktivieren
    2. IoT-Geräte per VLAN trennen
    3. Outbound-Verbindungen nur zu erforderlichen Endpunkten erlauben
    4. Wenn möglich auf offene Firmware umsteigen
    5. Regelmäßig nach Updates suchen
      Das Problem mit hartkodierten Schlüsseln ist besonders gravierend und betrifft offenbar die gesamte Produktlinie.
    • Ich habe einmal das Heimnetz eines Freundes getestet und konnte über ein PoE-Gegensprechsystem auf das gesamte interne Netz zugreifen.
      Er hatte seine IoT-Geräte nicht per VLAN getrennt und auch kein Benachrichtigungssystem eingerichtet.
      So hat er an diesem Tag ganz direkt gelernt, wie wichtig VLAN-Trennung und Zugriffsbeschränkungen sind.
      Vermutlich legen viele Menschen ihr internes Netz auf ähnliche Weise offen.
    • Es gab auch Leute, die gefragt haben, ob es einen Leitfaden mit Schritt-für-Schritt-Erklärung zur VLAN-Einrichtung gibt. Technisch ist das machbar, aber konkrete Abläufe werden benötigt.

  • Thingino soll die C200 unterstützen.

    • In der Praxis werden aber nur einige der fünf Versionen der C200 unterstützt.
      Um den genauen Chipsatz zu prüfen, sollte man OpenIPC zu Rate ziehen.
    • Die von der Thingino-Community entwickelte Firmware ist wirklich beeindruckend.
      Wenn man eine kompatible Kamera hat, lohnt sich ein Versuch auf jeden Fall.

  • Ich selbst betreibe alle Kameras in einem VLAN ohne Internetzugang.
    Über HomeKit ist lokaler Zugriff möglich, daher funktioniert alles auch ohne separate App gut.

  • Dieses Ausmaß an schlechter Sicherheit wirkt schon fast absichtlich.
    Es ist schwer nachzuvollziehen, wie man Millionen Geräte verkaufen kann, ohne auch nur grundlegende Schwachstellenprüfungen durchzuführen.
    Ich gehe davon aus, dass die meisten Wi-Fi-Kameras unter 150 US-Dollar ähnliche Probleme haben.
    Wenn man es wirklich sicher haben will, bleibt einem fast nur, selbst einen nicht-proprietären Wi-Fi-↔-Ethernet-Adapter zu bauen.

    • Diese Kamera wird auf der offiziellen Website für 17,99 US-Dollar verkauft.
      Zieht man Hardware, Verpackung, Logistik, Tests, Rücksendungen usw. ab, bleibt weniger als 5 US-Dollar Gewinn pro Einheit.
      Weitere 100.000 US-Dollar an Entwicklungskosten zu investieren, entspricht dem Verbrennen von 20.000 Geräten.
      Bei einem Unternehmen mit vielen Produktlinien wie TP-Link summiert sich das auf zig Millionen Dollar pro Jahr.
      Am Ende führt das zu einer Struktur, in der mit minimaler Entwicklung ausgeliefert wird.
    • Einige USB-betriebene Kameras unterstützen USB-Netzwerkadapter.
      Wer technisch versiert ist, kann sich mit Thingino-Firmware eine rein lokale Umgebung aufbauen.
    • Solche Kameras dürfen niemals in ein nicht vertrauenswürdiges Netzwerk gestellt werden. Das sollte eigentlich völlig offensichtlich sein.
    • Der Aussage „Alle Wi-Fi-Kameras haben ähnliche Probleme“ stimme ich voll zu.

  • Ich frage mich, wie lange das S3-Firmware-Repository von TP-Link noch offen bleiben wird.
    Es sind etwa 990 GiB an Daten, daher wäre es gut, wenn jemand ein Archiv oder Torrent-Backup anlegen würde.

  • Ich nutze diese Kamera mit Unifi + ONVIF nur für unkritische Zwecke.
    Sie hängt in einem separaten VLAN und hat keinen Internetzugang, funktioniert zum Glück aber problemlos.

  • Bei der Untersuchung der Kamera habe ich auf die Website drmnsamoliu.github.io zurückgegriffen.

  • Ich habe einmal mit Ghidra und AWS Amazon Q den Videofeed einer Spielzeugdrohne reverse-engineert.
    Mit GhidraMCP wäre es vermutlich deutlich schneller gegangen.