Dans ce second article nous allons présenter brièvement la démarche technique entreprise par un pentester lors d’un test d’intrusion IoT sur un routeur Wi-Fi dans un temps limité. Cet objet connecté faisant office de porte d’entrée sur un réseau interne, les risques principaux redoutés que nous avons identifiés sont l’accès illégitime au réseau LAN ainsi que la modification de la configuration de l’appareil.
Le routeur en question peut être trouvé chez les particuliers ou en entreprise. Après avoir effectué quelques recherches sur Internet afin d’identifier des sources intéressantes, nous commencerons par une analyse réseau. Ensuite, nous nous intéressons au matériel entre nos mains et nous terminons par une analyse du firmware.
L'installation
La première étape après avoir déballé notre nouvel objet connecté et de l’installer dans son environnement de test. Ici, nous connectons tout simplement notre PC et smartphone au réseau Wifi du routeur.
Architecture de notre environnement de test
Recherche d'informations techniques
Après l’installation, nous procédons à une phase de recherche de données techniques. Nous identifions plusieurs articles de recherches sur des versions de logiciel antérieur à notre objet. Il sera donc intéressant de vérifier au niveau logiciel les corrections apportées par l’éditeur pour les vulnérabilités précédemment identifiées.
Notre routeur étant un modèle européen, il ne possède pas d’identifiant FCC. Cependant, nous pouvons en trouver un sur le modèle US. Cela nous permet d’avoir une vue intérieure de l’appareil avant de l’acheter notamment :
Vue interne via l'identifiant FCC
Ces informations sont cependant à vérifier étant donné que notre modèle diffère. De plus, pour un même modèle il est aussi possible d’avoir une architecture qui évolue suite à des changements entre l’étape de vérification FCC et la mise en production.
Analyse Réseau
Cette phase consiste à identifier les éventuels points d’entrée une fois connecté au routeur. Pour cela nous effectuons un scan de port :
Scan de port
Service SSH
Nous identifions un service SSH permettant de se connecter à distance à l’appareil avec les identifiants configurés lors du premier accès à l’interface web. Cependant, il ne semble pas possible d’obtenir un accès à distance du fait d’une protection qui semble être activée. Nous découvrirons plus tard, que ce service est en fait utilisé par l’application mobile.
Tentative d'authentification au service SSH
Ce service n’est par ailleurs pas à jour et est impacté par plusieurs vulnérabilités connues. Cependant, aucuns des défauts les plus critiques ne semble présent dans notre environnement.
Listes des vulnérabilités découvertes sur la version actuellement installée
Service web
Au niveau de l’interface web, la plupart des données sont chiffrées et envoyées dans des paramètres POST. Nous notons l’utilisation du protocole HTTP qui peut engendrer un impact sur la confidentialité et l’intégrité des données.
L'interface web est accessible en HTTP
Les paramètres POST semblent chiffrés
En analysant le code JavaScript, nous avons été en mesure de déchiffrer les paramètres « sign » et « data ». Le premier utilise une signature RSA et le second l’algorithme AES.
Portion de code responsable du chiffrement AES
La clé AES et le vecteur initial sont généré à partir d’un timestamp et d’une valeur aléatoire. Ils sont ensuite stockés dans le navigateur.
Génération du couple clé/vecteur initial AES
La valeur « sign » est un chiffrement RSA de 3 valeurs concaténées : la clé AES, l’empreinte md5 des identifiants de connexions et un numéro de séquence.
Portion de code responsable du chiffrement RSA
Une requête non authentifiée permet de récupérer les valeurs « n » et « e » utilisées par l’algorithme RSA ainsi que la variable « seq ».
Récupération de paramètres de chiffrement
Un peu de scripting Python plus tard, nous avons pu automatiser le déchiffrement et le chiffrement de la valeur data. La variable « sign » ne semble pas être vérifiée côté serveur, il n’est donc pas nécessaire de la modifier.
Déchiffrement d'une chaîne AES
Le chiffrement de données dans une requête POST en se basant exclusivement sur des paramètres générés côté client est une barrière facilement franchissable pour un attaquant et ne répond pas aux bonnes pratiques de sécurité.
Service UPNP
Le service UPNP (Universal Plug and Play) sur le port 1900 permet aux équipements sur un même réseau de découvrir la disponibilité de chacun, d’établir des connexions et de partager des données. Plusieurs défauts sont connus sur ce protocole et permettent notamment des attaques de type phishing.
Avec pour seul prérequis d’être connecté au réseau du routeur, nous parvenons par exemple à créer une fausse imprimante sur le réseau. Lorsqu’un utilisateur tentera d’y accéder, il sera redirigé vers une fausse page d’authentification ce qui nous permettra de récupérer des identifiants.
Attaque phishing via le service UPnP du routeur
Récupération d'identifiants
Réseau Wifi
Au niveau du réseau Wifi, le mot de passe par défaut sur ce modèle de routeur est composé de 8 chiffres.
Mot de passe Wifi par défaut
Dans le cas d’un routeur utilisé avec ses paramètres par défaut, un attaquant peut donc aisément obtenir un accès au réseau. En effet avec 100 000 000 de mots de passe possibles, un attaquant avec un pc sans carte graphique prendrait en moyenne moins de 2 heures à récupérer le mot de passe en clair après avoir intercepté des trames contenant le mot de passe chiffré. Il est important de préciser que l’attaque par force brute ne nécessite pas de communiquer avec le routeur après avoir intercepté l’empreinte de mot de passe.
Nombre de mot de passe possibles
Attaque par force brute avec une machine sans carte graphique
Analyse du matériel
Le routeur est ensuite démonté en retirant les 2 vis cruciformes et quelques clips. Nous remarquons qu’aucune protection n’est présente à ce niveau.
Vue interne du routeur
Nous pouvons déjà confirmer que notre modèle n’est pas le même que celui trouvé via l’identifiant FCC du modèle US.
Très rapidement, nous identifions 4 pins associés aux valeurs TX, RX, GND et VCC. Ces pins correspondent à une interface UART. A priori, pas besoin d’utiliser le multimètre ou un analyseur logique ici. Pour rappel, cette interface peut nous fournir énormément d’informations sur la séquence de démarrage du routeur et, parfois même, un accès à un terminal de commande.
En nous connectant à cette interface via un module USB-TTL, nous obtenons un terminal root et des informations de debug.
Obtention d'un accès root via l'interface série
Il est alors possible d’analyser le système de fichiers et d’identifier des données sensibles telles que des mots de passe. Nous identifions par exemple l’empreinte md5 du mot de passe de l’interface web. Ce dernier comme indiqué plus haut, est d’ailleurs également utilisé pour l’accès SSH.
Présence d'une empreinte de mot de passe md5
Analyse du firmware
Plusieurs méthodes sont possibles ici pour récupérer le firmware de notre routeur. La plus facile étant d’en récupérer une copie sur le site du constructeur.
Cependant, nous préférons ici faire un dump directement sur le routeur afin d’avoir accès à notre configuration. Pour cela, nous choisissons d’utiliser un programmeur ch341a et l’outil flashrom pour lire directement le contenu de la mémoire flash. A noter que d’autres méthodes existent en passant par l’interface UART notamment.
Récupération du firmware
Des fichiers XML sont chiffrés dans le répertoire "/etc". Heureusement pour nous, le travail de déchiffrement a déjà été fait par un chercheur. Il nous suffit de récupérer les clés de chiffrement qui sont les même pour tous les routeurs du modèle. Ces fichiers ne contiennent cependant que des données de test.
Accès au fichier "default_config.xml" après déchiffrement
Par la suite nous procédons à l’analyse de plusieurs binaires afin d’identifier des faiblesses dans leur conception.
La fonction util_exexsystem() est utilisée par plusieurs d’entre eux lors d’une modification dans la configuration du routeur via l’interface web.
Exemple d'utilisation de la fonction util_execsystem()
De plus, plusieurs paramètres sont contrôlés par l’utilisateur dans la commande ce qui nous laisse penser qu’une exécution de code est possible. Cependant, des vulnérabilités ont déjà été identifiées concernant cette fonction et sont aujourd’hui corrigées. Chaque caractère contrôlé par l’utilisateur est vérifié et la plupart des caractères spéciaux sont interdits.
Portion de code vérifiant que l'URL est bien construite
Nous identifions également la fonction qui permet de générer le code à 8 chiffres lors de l’activation du WPS permettant de se connecter au réseau wifi sans connaitre le mot de passe du réseau.
Fonction permettant de générer le code WPS
La génération n’est ici pas aléatoire et est basée sur un timestamp. Cela réduit la difficulté qu’aura un attaquant lors d’une attaque par force brute.
Conclusion
Dans un temps limité à 5 jours, nous avons pu identifier plusieurs défauts de conception sur un routeur accessible au grand public. Il sera très facile pour un attaquant ayant un accès physique à l’objet d’en prendre le contrôle. A distance, il faudra en moyenne deux heures avec une machine sans carte graphique pour trouver le mot de passe par défaut du réseau wifi et ainsi étendre la surface d’attaque.
L’analyse du firmware requiert quant à elle plus de temps et est un travail qui devrait s’effectuer à chaque mise à jour. Pour la suite, il serait intéressant d’étudier le mécanisme de mise à jour du logiciel ainsi que la génération du mot de passe du réseau wifi par défaut que nous n’avons pas identifié dans le temps imparti.
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.
Découvrir nos solutions de pentest
Découvrir les autres articles de cette série consacrée à la sécurité IoT :
Analyse d'une serrure électronique
Dans les entrailles d'une caméra connectée TP-Link