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

Cet article est la seconde partie de l’étude de cas de la CVE-2022-46527 et va parler de la découverte de la vulnérabilité et d’une preuve de concept menant à un crash. La découverte de l’équipement se trouve dans la première partie.

L’embargo sur les détails de la vulnérabilité étant levé, l’équipement concerné par cet article est un ERS Sound d’ELSYS avec le firmware version 2.3.8.

Identification du code traitant les données NFC

Dans la première partie de l’article, on a appris que l’équipement se configure via des messages stockés sur la puce NFC. À l’aide des captures des données échangées, nous avons des exemples de mots utilisés dans la configuration qui seront utiles pour localiser la partie du firmware qui est en charge de traiter.

Figure 1: Extrait d'un message Ndef

Identification des fonctions à risques

En utilisant les mots clés, la fonction qui permet d’analyser les données stockées sur la puce NFC a été trouvé avec l’aide de Ghidra.

Figure 2: Aperçu de la fonction d'analyse des données de la puce NFC

Dans cette fonction d’analyse, on remarque que le mot clé “lock” est utilisé dans les arguments
envoyés à une fonction à trois paramètres :

• Le mot clé
• Les données de la puce
• La taille de la valeur à extraire

Cette fonction permet d’extraire la valeur associée à un mot clé.

Figure 3: Aperçu de la fonction d'extraction de la valeur associée à un mot clé

Analyse de l’origine du problème

Dans le cas présent, la fonction de copie « strncpy » n’est pas censée être à l’origine de problème de dépassement de mémoire tampon. Cette fonction prend en paramètre la taille maximale à copier afin de ne pas dépasser la mémoire tampon.

Sauf que dans notre cas, la taille maximale est la taille de valeur associée à la clé et qui est maîtrisée par l’utilisateur. Ce dernier peut avoir une taille supérieure à la taille de la mémoire tampon.

Déclenchement du crash

Comme la mémoire tampon est sur le stack, la vulnérabilité est un stack-based buffer overflow.

La taille de la mémoire tampon est de 36 caractères. Afin de réécrit l’adresse de retour, il faut un payload d’au moins 36 caractères auquel on rajoute la taille des variables stockée avec la mémoire tampon jusqu’à atteindre la réécriture de l’adresse de retour de la fonction. Dans notre case, 52 caractères permettent un crash de l’équipement. La réécriture de l’adresse de retour permet de prendre le contrôle sur le flux d’exécution des instructions sur le MCU.

Figure 4: Exemple d'effet de dépassement de la mémoire tampon de la stack

En mettant en chargeant la configuration suivante dans la puce NFC, l’appareil crash et redémarre indéfiniment. « lock: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA » Le clignotement de la LED en blanc n’est pas un comportement normal de l’appareil. La LED qui s’allume en rouge indique un démarrage de l’équipement.

Figure 5: Crash de l'appareil après chargement du payload

Un PoC est disponible sur notre GitHub.

Proposition de correction

La vulnérabilité étant un débordement de mémoire, ce dernier peut être corrigé en améliorant la gestion de la taille des chaînes de caractères.
Une solution pour corriger peut-être la modification de la portion du code responsable du calcul de la taille. Comme la fonction prend en paramètre la taille maximale, ce paramètre peut être réutilisé par la fonction « strncpy ». Ainsi la taille maximale est maîtrisée par le développeur au lieu de l’utilisateur.

Conclusion

Le vendeur a été notifié à propos de ce problème sur son équipement et a accusé de réception de la notification. Cependant à l’heure où cet article a été écrit, aucune information concernant une nouvelle version corrigeant ce problème ne nous a été communiquée de la part du vendeur. Entre-temps une nouvelle version du firmware est sortie.

Le PoC déclenche uniquement un crash. Dans le temps imparti de la mission réalisée pour notre client, une réelle exploitation n’a pas pu être réalisée. Il reste encore du travail pour arriver à son exploitation sachant que le mode debug du MCU n’est pas disponible. En supposant que les conditions d’exploitation soient réunies, une réelle utilisation de cette vulnérabilité peut être l’extraction des secrets permettant la connexion au réseau LoraWAN en se faisant passer pour l’équipement.