TP-Link Tapo C200 : clé codée en dur, buffer overflow et confidentialité à l’ère du reverse engineering assisté par l’IA

• L’analyse du firmware de la caméra IP TP-Link Tapo C200 d’entrée de gamme via du reverse engineering assisté par l’IA a mis au jour de nombreuses vulnérabilités de sécurité
• Le firmware contient une clé privée SSL codée en dur, ce qui permet de déchiffrer le trafic HTTPS sur le même réseau
• Le processus d’analyse s’est appuyé sur des outils d’IA (Grok, GhidraMCP, Cline, etc.) afin d’automatiser la compréhension de la structure du firmware et l’analyse sémantique des fonctions
• Parmi les principales failles découvertes figurent un buffer overflow (CVE-2025-8065), un integer overflow (CVE-2025-14299) et un détournement WiFi (CVE-2025-14300), dont certaines sont exploitables à distance sans authentification
• Ce cas est considéré comme un exemple montrant que l’IA améliore l’efficacité de la recherche en sécurité tout en révélant les faiblesses structurelles des appareils IoT

---

Acquisition et déchiffrement du firmware

• Le reverse engineering de l’application Android Tapo a permis de découvrir le bucket S3 public de TP-Link, depuis lequel il est possible de télécharger sans authentification le firmware de tous les appareils
  • Exemple de commande : aws s3 ls s3://download.tplinkcloud.com/ --no-sign-request --recursive
• Le déchiffrement du firmware a été réalisé à l’aide de l’outil tp-link-decrypt
  • La clé RSA peut être extraite des sources GPL publiées par TP-Link
• Le firmware déchiffré est structuré en bootloader, noyau et système de fichiers racine SquashFS

Reverse engineering assisté par l’IA

• L’analyse du firmware a été automatisée à l’aide de Ghidra, GhidraMCP, Cline, Anthropic Opus/Sonnet 4, etc.
• L’IA explique le rôle des fonctions et renomme les variables de manière plus parlante, ce qui améliore la lisibilité du code
• Ce processus a permis de cartographier les gestionnaires HTTP, le protocole de découverte et les routines de chiffrement
• Il a été confirmé que la clé privée SSL présente dans le firmware n’est pas générée au démarrage mais embarquée directement
  • Un attaquant présent sur le même réseau peut donc déchiffrer le trafic HTTPS

Principales vulnérabilités

• CVE-2025-8065 (débordement mémoire dans le parseur XML SOAP ONVIF)

  • Le serveur /bin/main sur le port 2020 ne réalise aucun contrôle de limite sur le nombre d’éléments XML
  • L’envoi d’un grand volume de requêtes XML provoque un débordement mémoire et le crash de la caméra
  • Score CVSS v4.0 : 7.1 (High)

• CVE-2025-14299 (integer overflow du Content-Length HTTPS)

  • Le serveur HTTPS sur le port 443 traite l’en-tête Content-Length avec atoi() sans validation
  • Sur un système 32 bits, cela provoque un crash dû à un overflow
  • Score CVSS v4.0 : 7.1 (High)

• CVE-2025-14300 (détournement WiFi)

  • L’API connectAp est accessible sans authentification et reste active même après la fin de la configuration
  • Un attaquant peut connecter la caméra à son propre réseau et intercepter le trafic vidéo
  • Score CVSS v4.0 : 8.7 (High)

• API de scan WiFi sans authentification (scanApList)

  • Elle renvoie les SSID, BSSID, intensités de signal et paramètres de sécurité des réseaux WiFi environnants
  • Des outils comme Apple BSSID Locator permettent un suivi très précis de la position GPS
  • Un attaquant distant peut ainsi identifier l’emplacement réel de la caméra

Divulgation et réponse

• Premier signalement à l’équipe sécurité de TP-Link le 22 juillet 2025, avec PoC et vidéo à l’appui
• Publication après 150 jours (19 décembre), puis diffusion d’un avis de sécurité par TP-Link
• TP-Link dispose de sa propre autorité d’attribution de CVE (CNA), ce qui lui permet de contrôler directement le processus de signalement et de divulgation des vulnérabilités de ses produits
• Sur son site web, l’entreprise utilise un nombre de CVE inférieur à celui de ses concurrents comme argument marketing, ce qui soulève la question d’un conflit d’intérêts structurel

Conclusion

• Les outils d’IA maximisent l’efficacité du reverse engineering et rendent la recherche en sécurité plus accessible
• Mais des éléments comme les clés codées en dur, les API sans authentification et des parseurs fragiles révèlent une absence fondamentale de sécurité sur les appareils IoT
• Le cas TP-Link illustre de manière emblématique la question de l’équilibre entre la recherche en sécurité à l’ère de l’IA et la responsabilité des fabricants