Recherche de vulnérabilités sur des équipements IoT: Cas de la CVE-2022-46527 (Partie 1)

L’usage d’objets connectés est de plus en plus répandu, que ce soit pour des besoins privés comme avec la domotique ou bien des besoins d’entreprises comme le suivi de camions. Avec leur nature connectée, ce type d’équipement peut présenter des risques pour leurs utilisateurs.

Afin d’assurer la sécurité de ces clients, l’équipe COS a réalisé des missions afin de rechercher des vulnérabilités sur ce type d’équipement. Cette publication est le début d’une série et aborde le cas de la découverte d’une 0-day sur l’une d’entre elles. L’étude de ce cas sera divisée en deux parties. La première partie montre la mise en place de l’environnement afin d’analyser l’équipement et la seconde partie exposera la découverte de la CVE-2022-46527 – Dont les détails sont à cette heure encore sous embargo.

Comment est composé un objet connecté ?

Les objets connectés peuvent être utilisés à des fins variées. Cela peut aller des relevés d’informations comme la température ou aussi bien une localisation, mais aussi à des actions sur l’environnement comme l’éclairage. Un objet connecté est composé de plusieurs parties :

• L’alimentation
• La partie réseau
• Le contrôleur
• Le capteur/actionneur

Les différents types de contrôleurs

Deux types de contrôleurs sont principalement rencontrés:

• les microcontrôleurs (MCU)
• les microprocesseurs (MPU)

Figure 1: Différence entre MCU et MPU

Les MCU sont les plus complets en comportant l’essentiel pour fonctionner: un processeur (CPU), de la mémoire volatile (RAM) et de la mémoire non volatile (ROM). Leur intégration est plus simple, leur consommation électrique et leur vitesse de fonctionnement plus faible. De plus, les MCU ont peu de RAM et de ROM donc ils sont plus adaptés pour un usage simple. Ce type de contrôleur est souvent utilisé sur des objets connectés qui prennent des mesures simples ; et qui sont déployés pendant plusieurs années sans qu’on ait besoin de changer la batterie.
Pour un usage plus intensif comme des équipements qui font du traitement d’images, les MPU sont utilisés, mais leur intégration est plus complexe, car la ROM et la RAM doivent être intégrées à part sur le circuit électronique en plus du MPU. Cependant, ce type de contrôleur est plus énergivore, mais pourra s’occuper de tâches plus complexes avec leur vitesse de fonctionnement plus élevé et avec plus de ROM et de RAM.

Découverte de l’objet connecté cible

L’objet connecté permet de relever plusieurs informations : le niveau sonore, la température, l’humidité, la luminosité et la présence. La référence du produit n’est pas encore divulguée, car une procédure de responsible disclosure est en cours.

Figure 2: Composants sur la carte électronique

Le circuit est composé d’un MCU STM32L151CC, d’un modem LoRaWAN et d’un tag NFC du fabricant STMicroelectronics. Pour le tag NFC, la référence ne se trouve pas sur sa face exposée après des essais. Le brochage semble correspondre à la gamme de ST25 du constructeur.

Grâce à la référence de ce MCU, nous apprenons que l’architecture du processeur est l’ARM ce qui nous permet d’analyser plus facilement le contenu du firmware.

Récupération du firmware

Néanmoins, parce que c’est un microcontrôleur (MCU), le contenu de la mémoire flash interne n’est pas directement accessible comparé aux MPU où la mémoire flash est à part donc :

Il existe plusieurs façons de récupérer le firmware utilisé par l’objet connecté. Les microcontrôleurs de chez STM ont un mode de debug utilisable avec un adapteur ST-Link. De plus, il existe différents bootloaders permettant de télécharger le firmware stocké sur la mémoire flash interne. Par exemple, il y a la commande « DFU_UPLOAD » du bootloader par USB DFU.

Cependant, pour protéger leur équipement et leur propriété intellectuelle, les constructeurs peuvent activer la protection en lecture de la mémoire flash, désactiver le mode debug et désactiver le bootloader sur les interfaces externes.

Dans le cas de l’équipement étudié, le mode debug semble être désactivé.

Figure 3: Tentative de debugging utilisant le ST-link

Un analyseur logique saleae a été utilisé pour écouter le trafic entre l’équipement et l’interface de debug.

Malgré les tentatives de l’interface de debug, aucune réponse ne vient du microcontrôleur.

Figure 4: Utilisation d'un analyseur logique pour surveiller le trafic entre le ST-link et le microcontrôleur

De plus, les pins pour sélectionner le mode de boot sont condamnés. L’obtention du firmware directement depuis l’objet connecté n’est pas possible avec les moyens à disposition.

Le constructeur propose les firmwares sur son site. Il est à noter que le constructeur propose un adaptateur pour pouvoir faire les mises à jour. Lors de cette étude, le firmware trouvé sur le site du constructeur a été utilisé.

Une fois le firmware téléchargé, le firmware peut être chargé dans un désassembleur sachant l’architecture utilisée.

Ici, Ghidra a été utilisé pour analyser le firmware.

Figure 5: Utilisation de Ghidra pour analyser le firmware

Une analyse du firmware peut permettre la découverte de fonctions à risque. Mais avant d’entrer plus en profondeur dans l’analyse du firmware, la recherche des différents canaux de communication et de leur fonctionnement permet de mieux focaliser la recherche de vulnérabilités sur les fonctions utilisées par les différents échanges avec l’extérieur.

Canaux de communication

L’équipement se configure à l’aide d’une application Android. L’application envoie un message au format NDEF dans le tag NFC. Le tag NFC stocke dans sa mémoire le message. Ce message contient, sur chaque ligne, une clé et sa valeur.

Figure 6: Extrait d'un message Ndef

Le MCU récupère la donnée contenue dans le tag NFC au travers d’une interface I2C.

 Figure 7: Écoute de l'échange entre le tag NFC et le MCU

Après analyse, le MCU prend la configuration contenue dans le tag NFC et l’intègre dans la configuration générale. Il y a tout de même le cas particulier où la configuration est protégée par un PIN. Seule la clé « pin » est prise en compte afin de déverrouiller la configuration et obtenir une copie dans le tag NFC.
Un autre canal de communication est l’interface entre le MCU et le modem LoRaWAN.

Et la suite ?

Dans cette première partie, nous avons pu faire la découverte de l’équipement où la recherche de vulnérabilité est faite. Cependant, le mode de debug et de programmation de l’équipement ne semble pas être activé. L’architecture du processeur est l’ARM et on a une version du firmware qui se rapproche de celle utilisée par l’équipement.
La prochaine étape consiste à explorer les différentes parties du code qui sont utilisées dans les différents canaux de communication à la recherche de vulnérabilités.