L’Internet of Things -IoT- gagne de plus en plus de place dans nos vies chaque année. Montres, caméras, balances ou encore alarmes sont des exemples d’objets que l’on peut trouver dans cet écosystème qu’est l’IoT. Lorsque l’on prend conscience de l’omniprésence de ces appareils autour de nous, la question de la sécurité de ces derniers s’impose forcément. La conception de ces mini-ordinateurs est-elle pensée pour les sécuriser contre des attaques qui peuvent permettre d’en prendre le contrôle voir même d’accéder à nos données personnelles ?
Dans ce premier article sur la sécurité de l’IoT, nous allons nous intéresser à la caméra connecté Tapo C200 de TP-LINK. Cet appareil coûte une trentaine d’euros et promet un accès et une gestion facile des flux vidéo via une application mobile. Nous allons nous intéresser à la question : Comment sont stockées nos données dans cet appareil ?
Architecture de notre environnement de test
La démarche entreprise lors de nos recherches est similaire à celle que l’on suivrait lors d’un test d’intrusion. Tout d’abord, nous récupérons un maximum d’informations, de manière passive puis active. Nous étudions ensuite chaque point d’entrée, avec pour but principal d’obtenir les privilèges les plus élevés sur la caméra pour ensuite analyser plus aisément son fonctionnement.
Au niveau de notre environnement de test, tous nos appareils sont connectés à un même réseau Wifi. La caméra a été mise à jour dans sa dernière version lors de sa configuration via l’application mobile proposée par TP-LINK.
Récupération de données techniques
Sans même déballer notre nouveau gadget, quelques recherches sur Internet nous permettent de récupérer des ressources intéressantes. Parmi elles, l'identifiant FCC du modèle US de la caméra qui nous permet, notamment, d’avoir une vue théorique du circuit imprimé. Cependant, le modèle testé par l’organisme FCC peut différer de celui utilisé pour la rédaction de cet article. Nous identifions aussi des articles de recherches effectués sur des modèles antérieurs au notre qui nous seront bien utiles.
Au niveau des ports externes, la caméra est équipée d’un slot de carte SD, d’un bouton de réinitialisation et de son port d’alimentation 9V. Il sera intéressant d’analyser le contenu de notre carte mémoire après utilisation de la caméra.
Vue externe de la caméra
Passons ensuite à l’analyse interne de l’objet ! Pour cela, il est d’abord nécessaire de la démonter. Ici, pas de vis externe, il faut commencer par déclipser le haut de la structure externe.
Quelques coups de tournevis plus tard, nous pouvons commencer notre analyse du circuit imprimé.
Nous identifions rapidement plusieurs points de test -TP- souvent utilisé dans les usines de production pour valider le fonctionnement du circuit imprimé. Parmi ces points, 4 nous laissent penser, en raison de leur proximité, qu’une interface série émetteur-récepteur asynchrone universel -UART- est présente. Nous nous connecterons, plus tard, à cette interface afin d’observer les données qu’il est possible d’obtenir.
Nous relevons ensuite la liste des composants utilisés. Parmi eux, une puce Ingenic T31 qui fait office de microprocesseur. En accédant à la référence de cette dernière sur le site du constructeur, nous notons sa compatibilité avec l’UART.
Présentation du microprocesseur
Sur l’autre face du circuit, nous identifions la mémoire flash de la caméra d’une capacité de 8 Mégaoctets. C’est dans cette dernière que se situent toutes les données stockées et utilisées, notamment celles pour la configuration. Une étape importante du test d’intrusion IoT est de récupérer le contenu de cette puce.
Circuit imprimé de la caméra
Connexion à l'interface UART
Il est temps de sortir le multimètre et le fer à souder. L’interface UART sera notre première cible. Cette dernière peut nous fournir énormément d’informations sur la séquence de démarrage de la caméra et, parfois même, un accès à un terminal de commande.
Avec notre multimètre, nous confirmons que l’agencement des pins est dans le même ordre que les annotations TX, RX, GND et VCC. Après avoir soudé des fils sur les trois premiers pins (VCC n’est pas utile dans ce cas), nous utilisons un adaptateur USB TTL pour connecter notre ordinateur à l’interface.
Branchement à un adaptateur USB TTL
Il ne reste plus qu’à lancer la commande screen, avec en paramètre l’interface de notre pc connecté à l’adaptateur et le baud rate, que nous avons obtenu de façon empirique.
Commande Screen
En branchant l’alimentation de la caméra, nous observons alors sa séquence de démarrage. Nous identifions l’utilisation d’un noyau MIPS et d’une image Linux-3.10-14. Il est également possible de récupérer le détail des partitions de la mémoire flash.
Information technique via l'interface série
Un détail attire notre attention, le composant BusyBox est utilisé. En appuyant sur la touche entrée, nous accédons à un terminal de commande sur la caméra. Nous avons les privilèges root, et pouvons ainsi parcourir tous les dossiers du système d’exploitation. Aucun mot de passe est nécessaire. En réalité le compte root n’en possède pas.
Accès root sans mot de passe
Dans le dossier /bin, nous identifions plusieurs binaires utilisés lors de la configuration de la caméra. Nous observons aussi un dossier /etc/config dans lequel est montée la partition « Config ».
Liste de binaires accessibles
Nous identifions rapidement la configuration wifi de la caméra. Cependant, le mot de passe de notre réseau est chiffré puis encodé en base64. Il en est de même pour la variable « username ».
Nous observons également une variable « passwd » qui semble contenir une empreinte cryptographique au format md5. Nous remarquons rapidement que cette empreinte correspond au mot de passe utilisé pour notre compte sur l’application mobile. L’algorithme md5 n’est plus recommandé par l’ANSSI depuis 2014. En effet, il est considéré comme « définitivement cassé ». Selon sa robustesse, il est peut-être plus ou moins facile pour un attaquant d’obtenir le mot de passe en clair.
Identification de données chiffrées
Pour déchiffrer le mot de passe wifi, nos recherches nous mènent à un binaire « wlan-manager » qui semble s’occuper d’initier la connexion avec notre point d’accès, et donc de déchiffrer le mot de passe présent dans la configuration.
Dump de la mémoire flash
Nous décidons alors de récupérer le contenu de la mémoire flash pour travailler plus aisément sur le fichier. Nous décidons ici de passer par notre interface UART. Plus précisément, il est possible d’interrompre le démarrage de la caméra avant que les partitions ne soient chargées en tapant rapidement « slp ». Nous obtenons alors un terminal de commande bas niveau sur le microprocesseur. Ceci nous permet d’effectuer des opérations directement sur la mémoire flash.
Menu du bootloader
Il est alors possible de lire l’entièreté de la mémoire flash grâce à la commande « md » accompagnée de l’adresse de démarrage de la mémoire et de sa taille. En prenant soin de rediriger vers un fichier l’affichage de notre commande screen, nous obtenons après quelques minutes une copie de notre mémoire flash. Nous exécutons ensuite un script permettant de nettoyer notre fichier, pour ne garder que les données hexadécimales.
Enfin, nous utilisons le très célèbre binwalk pour identifier un type de fichier dans notre extrait. L’outil identifie alors un système de fichier Linux (squash-fs). Après extraction, nous pouvons accéder aux binaires de l’application, dont le fameux wlan-manager.
Analyse du dump de la mémoire flash
Retro ingenieurie du Wlan-Manager
Nous nous lançons donc dans la rétro ingénierie de ce binaire. Après avoir importé toutes les librairies utilisées par ce dernier, nous identifions l’utilisation des fonctions AES_cbc_Encrypt et AES_cbc_Decrypt de la librairie libaes.so. Une analyse plus poussée des paramètres utilisés, dans l’appel à ces fonctions, nous aide à identifier deux valeurs stockées dans le binaire qui semblent servir de clé de chiffrement et de vecteur d’initialisation.
Identification de la clé et du vecteur initial AES
Nous décodons alors dans un fichier la chaine de caractère en base64, présente au niveau de notre configuration Wifi et lançons la commande openssl pour tenter de déchiffrer ce dernier.
Déchiffrement de la clé wifi
Le contenu de la variable « username » récupéré précédemment est aussi encodé en base64. Se pourrait-il que les clés de chiffrement soient les mêmes ? Oui ! Nous parvenons ainsi à récupérer l’adresse email de notre utilisateur de l’application mobile.
Pour aller plus loin, nous tentons également de déchiffrer les clé Wifi chiffrées trouvées dans des articles d’autres chercheurs sur Internet. Le constat final est que toutes les caméras du même modèle utilisent les mêmes clés de chiffrements et vecteurs d’initialisation !
Pour conclure...
Pour terminer cet article, nous pouvons retenir qu’un accès physique à notre caméra connecté permettra à un attaquant d’obtenir un accès à notre réseau local ainsi qu’à notre compte d’application mobile et donc aux flux vidéo. Pour aller plus loin, il peut être intéressant d’effectuer une analyse réseau de la caméra en parallèle avec la rétro ingénierie d’autres binaires dans le but d’identifier des points d’entrées depuis le réseau.
Ce premier article met en évidence des problématiques courantes dans le domaine de la sécurité IoT. Un accès local à un appareil nous permet dans la plupart des cas d’obtenir les pleins droits dessus assez aisément. Il est ensuite possible d’analyser en profondeur l’objet connecté pour ensuite trouver des défauts qui permettront d’impacter la sécurité d’autre appareils du même modèle (parfois de la même marque) sans forcément nécessiter un accès local.
Nous pouvons ensuite dresser la liste suivante des vulnérabilités identifiées en fonction du TOP 10 OWASP 2018 dédié à l’IoT :
Il est important de préciser que même une vulnérabilité considérée comme mineure ou modérée peut nécessiter une correction rapide dans le cas où son enchaînement avec d’autres défauts engendre un réel impact sur la sécurité de l’objet.
Suite à notre observation sur l’utilisation non unique des paramètres de chiffrement AES, nous avons contacté TP-LINK pour les inviter à corriger ce défaut.
Timeline
13/12/2022 – Support TP-LINK contacté
08/02/2023 – Vérification de la correction proposée par TP-Link
21/02/2023 – Demande d’attribution d’une CVE
23/03/2023 – CVE-2023-27126 attribuée par Mitre
15/05/2023 – Relance auprès de TP-LINK
16/05/2023 – Réponse de TP-LINK : La correction a été publié le 26/04/2023
Voir le replay du webinar Sécurité IoT
Découvrir les autres articles de cette série consacrée à la sécurité IoT :
Analyse d'une serrure électronique
Pentest d'un routeur wifi