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

 (evilsocket.net)
1 points par GN⁺ 2025-12-21 | 1 commentaires | Partager sur WhatsApp
  • 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

À lire aussi

1 commentaires

 
GN⁺ 2025-12-21
Avis sur Hacker News

  • Je trouve dommage que ce type d’article mélange de vrais cas d’échec avec des problèmes que même les FAANG ont du mal à résoudre pour en faire une critique
    En particulier, traiter de façon critique le fait que « le dépôt de firmware de TP-Link se trouvait dans un bucket S3 public sans authentification » est une mauvaise approche
    J’y vois plutôt un bon exemple d’évitement de la sécurité par l’obscurité
    Ce genre d’article pourrait au contraire pousser la direction à donner de mauvaises consignes de « verrouillage renforcé »

    • Le texte lui-même était facile à lire, mais on y sentait un ton qui semblait écrit par un LLM
      Les textes écrits par l’IA manquent de nuances subtiles et ont tendance à présenter chaque chose comme excessivement nouvelle, bonne ou mauvaise
      Ce n’est pas un mauvais article, mais il faut le lire avec prudence. La plupart des billets publiés sur HN ces jours-ci semblent avoir bénéficié d’une aide de l’IA
    • Quelqu’un a lancé la blague « n’allons pas parler de Linux » à propos du fait que « le dépôt de firmware est public »
    • Ce type de blog de reverse engineering est avant tout une manière amusante et pédagogique de raconter une histoire
      J’en ai moi-même écrit plusieurs, et celui-ci était vraiment intéressant
      En réalité, « comment le firmware a été obtenu » est la partie la moins importante de cette histoire
    • Je n’ai perçu absolument aucune connotation négative dans le passage indiquant que le firmware était public. Je me demande si d’autres l’ont ressenti ainsi
    • À mon avis, les firmwares devraient toujours être publics. C’est la bonne direction

  • Il est très probable que la plupart des autres modèles de caméras partagent des failles de sécurité similaires
    Selon la page communautaire TP-Link, le dernier firmware du C200 est affiché en version 1.4.4, mais l’article mentionne la 1.4.2
    Autrement dit, certaines mises à jour ont eu lieu, mais les correctifs de sécurité ne semblent pas avoir été intégrés

    • J’étais arrivé à la même conclusion autrefois en analysant des produits Zyxel
      Beaucoup de fabricants revendent du matériel commun sous une autre marque
      Billets d’analyse associés : Part 1, Part 2
    • Ces caméras conviennent à une connexion locale, mais pour l’utilisateur moyen, il subsiste encore de gros problèmes d’utilisabilité

  • C’est pour cela que la segmentation du réseau IoT est indispensable
    Toutes les caméras intelligentes et tous les appareils IoT devraient être placés sur un VLAN séparé, avec un accès Internet restreint via le pare-feu
    Réglages recommandés aux utilisateurs de caméras TP-Link :

    1. désactiver l’UPnP sur le routeur
    2. isoler les appareils IoT avec un VLAN
    3. n’autoriser en sortie que les endpoints nécessaires
    4. remplacer le firmware par un firmware open source si possible
    5. vérifier régulièrement les mises à jour
      Le problème des clés codées en dur est particulièrement grave et affecte toute la gamme de produits
    • J’ai déjà testé le réseau domestique d’un ami et j’ai pu accéder à l’ensemble de son réseau interne via un système d’interphone PoE
      Il n’avait pas isolé ses appareils IoT par VLAN et n’avait aucun système d’alerte
      Il a donc appris ce jour-là, de manière très concrète, l’importance de la séparation par VLAN et de la restriction d’accès
      J’ai l’impression que beaucoup de gens exposent leur réseau interne de la même manière
    • Quelqu’un a aussi demandé s’il existait un guide expliquant pas à pas la configuration d’un VLAN. C’est techniquement possible, mais il faut une procédure détaillée

  • Thingino prendrait en charge le C200

    • Mais en réalité, seules certaines des 5 versions du C200 sont prises en charge
      Pour vérifier le chipset exact, il faut consulter OpenIPC
    • Le firmware créé par la communauté Thingino est vraiment impressionnant
      Si vous avez une caméra compatible, cela vaut vraiment le coup d’essayer

  • J’utilise toutes mes caméras sur un VLAN sans accès à Internet
    L’accès local fonctionne via HomeKit, donc tout marche bien même sans application dédiée

  • Ce niveau de médiocrité en matière de sécurité donne presque l’impression d’être intentionnel
    Il est difficile de comprendre comment on peut vendre des millions d’unités sans effectuer les vérifications de vulnérabilité les plus élémentaires
    À mon avis, la plupart des caméras Wi-Fi à moins de 150 $ ont des problèmes comparables
    Pour une utilisation vraiment sûre, il ne reste pratiquement qu’à fabriquer soi-même un adaptateur Wi‑Fi ↔ Ethernet non propriétaire

    • Cette caméra est vendue 17,99 $ sur le site officiel
      Une fois retranchés le matériel, l’emballage, la logistique, les tests, les retours, etc., il reste moins de 5 $ de marge par unité
      Dépenser 100 000 $ de plus en développement revient alors à brûler 20 000 unités
      Pour une entreprise avec une large gamme de produits comme TP-Link, ce coût peut gonfler jusqu’à des dizaines de millions de dollars par an
      Au final, on se retrouve avec une logique de mise en vente avec un développement minimal
    • Certaines caméras alimentées en USB prennent en charge des adaptateurs réseau USB
      Les personnes techniquement à l’aise peuvent mettre en place un environnement purement local avec le firmware Thingino
    • Ces caméras ne devraient jamais être placées sur un réseau non fiable. C’est un principe tellement évident
    • J’adhère totalement à l’idée que « toutes les caméras Wi‑Fi ont des problèmes similaires »

  • Je me demande combien de temps le dépôt de firmware S3 de TP-Link restera ouvert
    Il y a environ 990 GiB de données ; ce serait bien que quelqu’un en fasse une sauvegarde sous forme d’archive ou de torrent

  • J’utilise cette caméra avec Unifi + ONVIF uniquement pour des usages non critiques
    Je l’ai placée sur un VLAN séparé avec accès Internet bloqué, et heureusement cela fonctionne correctement

  • Pour examiner les caméras, je me suis référé au site drmnsamoliu.github.io

  • J’ai déjà fait du reverse engineering du flux vidéo d’un drone jouet avec Ghidra et AWS Amazon Q
    Cela aurait sans doute été beaucoup plus rapide avec GhidraMCP