J’ai voulu surveiller mon chien, et je me suis retrouvé à surveiller TP-Link

• J’ai acheté une caméra Tapo pour observer mon chien à la maison, mais cela m’a finalement amené à expliquer à rebours le fonctionnement des appareils et de l’app TP-Link
• Pour analyser le processus d’onboarding et la structure des communications API chiffrées, diverses techniques ont été utilisées : MITM, décompilation d’APK, création de scripts de déchiffrement, etc.
• La découverte du mot de passe administrateur initial et du processus de dérivation des clés de session a permis de déchiffrer les messages chiffrés et d’identifier un problème de synchronisation peu fiable entre l’appareil et le compte cloud
• L’analyse de l’ensemble du flux d’onboarding a permis d’automatiser en Bash les principaux appels API, la création de compte, le changement de mot de passe, la connexion au Wi‑Fi, etc.
• Le billet pointe les failles de conception de la sécurité du firmware Tapo, une implémentation du chiffrement peu sophistiquée et une synchronisation de compte irrégulière, autant de traits typiques des appareils IoT à bas coût

---

Aperçu du projet

• L’auteur a acheté et utilisé une caméra Tapo d’entrée de gamme pour surveiller son chien à l’intérieur
• Au fil de l’utilisation, face à une configuration peu pratique et au manque d’informations disponibles en ligne, il a été poussé à creuser en profondeur le fonctionnement du produit
• Des problèmes inattendus sont survenus lors de l’intégration avec frigate et de l’activation du 2way audio, ce qui a éveillé son intérêt pour une méthode d’onboarding direct sans intégration cloud

Analyse de l’onboarding et de la structure d’authentification

• Pour analyser la procédure de connexion de la caméra Tapo, l’auteur a intercepté le trafic entre l’app et la caméra à l’aide d’un proxy MITM et de l’outil de hook dynamique frida
  • Les applications récentes ignorent souvent les proxys et utilisent des mécanismes de résistance au contournement comme le certificate pinning, ce qui rend pertinente une approche fondée sur des outils dynamiques
• Une fois ce dispositif de contournement en place, il a pu confirmer précisément le processus de connexion du compte administrateur par défaut dans le flux d’onboarding de la caméra
• Il a découvert que l’API de connexion par défaut fonctionnait avec un mot de passe par défaut propre à l’appareil, distinct du mot de passe du compte cloud

Structure du chiffrement et recherche du mot de passe par défaut

• Grâce à la décompilation de l’APK (avec JADX) et à l’analyse du code, il a récupéré le mot de passe par défaut du compte admin (TPL075526460603)
• Il a constaté que, même après modification du mot de passe cloud, les caméras déjà associées ne détectaient pas le changement, ce qui confirme une synchronisation imparfaite des mots de passe entre l’app et la caméra
• Ayant découvert le mot de passe par défaut, il a implémenté la logique de dérivation des clés de session (lsk, ivb), rendant possible le déchiffrement en temps réel des messages API chiffrés

Scripts mitmproxy et analyse de l’API

• En s’appuyant sur le projet open source PyTapo, il a analysé avec précision le flux API réel de l’onboarding Tapo
• Le script tapo_decrypt_pretty.py permet de :
  • détecter le handshake de connexion
  • extraire les clés de session
  • déchiffrer les API chiffrées, produire une sortie plus lisible et enregistrer le JSON
• Parmi l’ensemble des appels API de l’onboarding, seuls les processus significatifs ont été retenus pour créer un workflow automatisé
  • récupération de la liste Wi‑Fi (scanApList)
  • activation des comptes RTSP/ONVIF
  • changement du mot de passe administrateur
  • connexion au Wi‑Fi

Automatisation et résultats

• Un script Bash (tapo_onboard.sh) a été conçu pour exécuter automatiquement l’ensemble de ce processus d’onboarding
  • connexion admin par défaut
  • sélection et connexion au Wi‑Fi
  • suppression du logo sur le flux de la caméra
  • autorisation de l’usage de RTSP/ONVIF
  • réinitialisation du mot de passe administrateur
• En raison de la structure du firmware de la caméra, les caractéristiques et faiblesses suivantes ont été observées
  • certaines API utilisent un hachage SHA-256, mais d’autres conservent des mécanismes plus anciens comme MD5
  • il existe deux clés publiques, sans qu’il soit clair dans quelles situations utiliser l’une ou l’autre
  • la synchronisation des mots de passe entre l’app et l’appareil est très instable

Conclusion et impressions

• La structure de sécurité du firmware et des API de la caméra Tapo donne l’impression d’un assemblage de fortune et d’une conception peu sophistiquée
• Le projet lui a permis d’entrevoir concrètement les failles de sécurité et la réalité d’un système d’onboarding imparfait dans les appareils IoT à bas coût
• Il a finalement atteint son objectif initial, à savoir surveiller son chien, et a surtout constaté que celui-ci dormait la plupart du temps sur le canapé ou le lit

[helio]

Le CVE-2022-37255 est noté 7,5.

[GN⁺]

Avis Hacker News

• Je trouve ça amusant que quelqu’un ait utilisé mon script Frida ; il est disponible ici. Je suis content de voir qu’il semble bien fonctionner en conditions réelles, et j’aimerais savoir si quelqu’un y a ajouté ou modifié quelque chose.

  • HTTP Toolkit est vraiment un excellent outil ; superbe travail de Tim.
  • Parmi tous les outils que j’ai utilisés, Http toolkit est le meilleur. J’ai aussi essayé mitmproxy, proxyman et charles proxy, mais httptoolkit est celui que je préfère, et en plus il est open source.

• Pour info, si vous voulez utiliser l’audio bidirectionnel dans frigate, il faut configurer le flux principal go2rtc avec tapo:// au lieu du rtsp:// habituel. TP-Link ne fournit l’audio bidirectionnel que via son API propriétaire. Le problème, c’est qu’avec cette configuration, ONVIF (contrôle pan/tilt de la caméra via des outils open source) ne fonctionne plus, ce qui est pénible. Pour avoir les deux, il faut un workflow assez agressif : arrêter la lecture du flux tapo:// → lancer le client ONVIF / ajuster le pan-tilt → quitter ONVIF → redémarrer tapo://.

• Je pense que la sécurité IoT est globalement catastrophique, et le fait que les routeurs grand public soient des boîtes noires impossibles à auditer qui traitent tout le trafic réseau est particulièrement inquiétant. La plupart des gens ignorent que le firmware de leur routeur n’a pas été mis à jour depuis des années et qu’il contient déjà des vulnérabilités connues. À mon avis, le modèle de confiance de la supply chain du matériel réseau est complètement cassé.

  • Je suis d’accord pour dire que la sécurité IoT laisse à désirer. Pour ma part, j’aimerais surtout que les appareils IoT se connectent simplement correctement, et il m’arrive même de vouloir utiliser un exploit pour contourner des limitations online-only. Mais il existe aussi de vrais cas d’usage pour l’IoT connecté au cloud, donc je pense qu’au premier démarrage l’appareil devrait demander à l’utilisateur ce qu’il veut et ne fonctionner que dans le mode choisi. Si quelqu’un a besoin de MFA dans le cloud, il devrait pouvoir le sélectionner ; s’il veut simplement piloter l’appareil par programmation, il devrait pouvoir le laisser hors ligne.
  • Il y a d’innombrables routeurs entre l’utilisateur et la destination, et on ne peut pas tous les surveiller. Les terminaux partent déjà du principe que les routeurs sont compromis et transmettent tout en vérifié et chiffré ; donc tant qu’un routeur n’est pas utilisé pour des abus comme du DDoS ou du minage de cryptomonnaie, sa sécurité en elle-même n’a pas énormément d’importance, à mon avis.
  • La plupart des gens utilisent un routeur fourni et configuré par leur FAI, donc on branche en pratique une boîte noire sur une autre boîte noire. Il m’est souvent arrivé de voir des gens se connecter au Wi-Fi avec le SSID et le mot de passe imposés par leur FAI, et ça me surprend toujours de voir à quel point ils lui abandonnent de contrôle.
  • C’est vrai pour les produits grand public, mais avec du matériel prosumer comme Ubiquiti ou Mikrotik, on peut avoir des mises à jour de sécurité rapides et un support firmware fiable.

• J’ai trouvé ce billet de blog remarquablement bien écrit. De nos jours, beaucoup de textes de ce style sont générés par des LLM et deviennent pénibles à lire, mais celui-ci m’a impressionné par son bon équilibre entre technicité et confort de lecture. (Je sais que l’image de couverture est générée par IA, mais je pense que ça n’a rien à voir avec le fond du texte.)

  • De mon côté, j’utilise uBlock Origin pour bloquer par défaut les fichiers média volumineux afin d’économiser des ressources. Les images de couverture sont souvent bloquées de toute façon et n’ont quasiment aucune utilité. Je trouve dommage qu’on dépense des ressources pour les générer.

• Je me demande si on pourra continuer à utiliser des outils comme Frida ou mitmproxy avec les apps Android, et ce qu’il se passera l’an prochain quand les exigences de signature entreront en vigueur.

  • Globalement, ce sera probablement encore possible, mais les apps qui exigent de l’attestation vont devenir bien plus difficiles. Déjà aujourd’hui, les appareils autorisant l’OEM unlock et le root, comme les Pixel, peuvent encore servir à des usages de développement. En revanche, ils sont marqués comme déverrouillés et échouent à l’attestation Google. On pourra sans doute toujours extraire une app, y injecter Frida et la sideloader avec un compte développeur, comme sur iOS. Mais là aussi, on se heurte à l’échec de l’attestation et aux mécanismes anti-tampering / anti-debugging.
  • En réalité, je ne pense pas que ce changement aura un impact direct majeur. Le reverse engineering se fait surtout sur des appareils rootés et des émulateurs. Plus rarement, lorsqu’on injecte Frida dans un APK via gadget sur un appareil non rooté, cela deviendra plus compliqué, mais il restera probablement une possibilité de builder et d’installer l’APK en mode développeur. Le bloquer totalement rendrait le développement d’apps Android impossible ; j’imagine donc qu’ils interdiront le sideload sur les appareils grand public tout en gardant une option de type certificat développeur. Au final, ce qui deviendra surtout difficile, c’est la distribution réelle des apps ; pour le développement et le reverse engineering, ça devrait rester faisable. La menace plus importante, c’est plutôt l’extension de l’attestation des appareils : de plus en plus d’apps pourraient devenir très strictes sur la vérification d’un appareil non modifié sur des appareils rootés ou non officiels. Pour l’instant, cela concerne surtout les grosses apps financières. Les personnes vraiment concernées (comme les utilisateurs de GrapheneOS) restent peu nombreuses, et cela implique aussi des coûts, comme l’ajout d’une infrastructure serveur, donc ce n’est pas forcément quelque chose qui se généralisera vite, mais ça pourrait évoluer.
  • En pratique, j’ai déjà l’impression que l’usage de Frida n’est pas simple. Il faut du root, et il existe de plus en plus de modèles sur lesquels le root devient impossible, ainsi que des SDK de détection de root très puissants et des contre-mesures face à Play Integrity.

• Pour info, parmi les cas liés, il y a The Tapo C200 Research Project et PyTapo: bibliothèque Python pour les caméras Tapo.

• Autre ressource connexe : l’analyse du déchiffrement du firmware TP-Link et du bootloader de la caméra cloud C210 V2 est disponible ici.

• Je me demande si la raison pour laquelle le chien d’OP passe du lit au sol n’est pas simplement que le radiateur s’allume ; il faudrait sans doute davantage de données de capteurs.

  • Ou alors il a tout simplement froid.

• J’ai l’impression qu’on est arrivés à une époque où découvrir un mot de passe administrateur codé en dur n’a plus rien d’exceptionnel.

  • Si je comprends bien, il s’agit juste d’un mot de passe par défaut codé en dur, pas d’une porte dérobée permanente. D’après le billet, l’utilisateur change ce mot de passe pendant l’onboarding. La plupart des apps fonctionnent comme ça.
  • Si le mot de passe est changé dans le processus normal après l’installation, je ne pense pas que ce soit vraiment un problème. Après avoir rempli ma maison d’autant d’appareils IoT / smart home que possible ces cinq dernières années, mon constat est que quasiment tous les fabricants vendent des produits dont la qualité fonctionnelle est discutable, et qu’il est très difficile de bâtir un smart home cohérent sans tout unifier chez un seul fournisseur. Et même les meilleurs ne couvrent pas tous les besoins individuels. Sur mon smartphone, j’ai installé des apps Ecobee, Lutron, Hue, plusieurs fournisseurs de caméras, Meross, Smart Life, etc. Parmi tout ça, seuls Lutron et Hue peuvent être pilotés directement via hub / HomeKit, donc je n’ai pas besoin d’ouvrir leurs apps. Matter et Thread sont standardisés depuis longtemps, mais le marché est toujours inondé de produits Wi-Fi bon marché plutôt que d’appareils compatibles, et la plupart sont médiocres : ils ne se gèrent que via une app et sont conçus pour pousser vers des services cloud. Le fait que j’aie acheté quatre caméras est aussi de ma faute, mais en réalité chaque fabricant a ses points forts, donc on ne peut pas vraiment reprocher aux consommateurs de répartir leurs achats.
  • Un mot de passe administrateur codé en dur qu’il est impossible de ne pas changer avant utilisation, ce n’est pas en soi un gros sujet selon moi.
  • En fait, j’ai l’impression que cette technologie m’agace juste inutilement. Ici, on ne peut pas vraiment parler de problème.
  • On peut aussi considérer que le smartphone est l’appareil originellement hostile ; au moins, avec les équipements réseau, ce genre d’observation ou de découverte reste possible.

• J’aimerais trouver une référence recensant les modèles de caméras tapo qui prennent en charge RTSP. La c210 fonctionne plutôt correctement (sauf pour les captures cloud) et je l’utilise intégrée à frigate. J’ai acheté aujourd’hui une c402 (extérieur), mais celle-ci n’a pas de compte caméra dans les paramètres avancés, ce qui est dommage. Le prix est attractif, mais je trouve le manque d’uniformité des fonctionnalités frustrant. Si quelqu’un a une bonne caméra extérieure bon marché, avec flux RTSP et panneau solaire, je suis preneur.

  • Même si la caméra ne prend pas en charge rtsp://, il devrait être possible d’utiliser une source de flux go2rtc en tapo://. J’ai laissé ma configuration frigate ici à titre de référence.