« Pratique courante »
Image may be NSFW.Clik here to view.
Deux chercheurs espagnols ont annoncé avoir découvert des commandes cachées dans la puce ESP32, largement utilisée dans le monde. Ce qui a conduit la société Tarlogic Security à parler de « porte dérobée ». En s’y penchant de plus près, d’autres ont remarqué cependant qu’il s’agissait de commandes non documentées, dont l’exploitation serait complexe.
Durant le week-end, la communauté de la sécurité informatique découvrait avec stupeur une information étonnante : la puce ESP32, que l’on trouve dans plus d’un milliard d’appareils dans le monde, contenait une porte dérobée. C’était la découverte de deux chercheurs espagnols, Miguel Tarascó Acuña et Antonio Vázquez Blanco, de la société Tarlogic Security.
Cette découverte a été partagée en fin de semaine dernière dans le cadre de la conférence RootedCON, qui s’est tenue à Madrid du 6 au 8 mars. La puce ESP32, chargée d’assurer les connexions Wi-Fi et Bluetooth, est fabriquée par la société chinoise Espressif et est souvent intégrée pour son rapport qualité/prix (2 euros, selon Tarlogic Security). Bien sûr, l’éventualité d’une porte dérobée dans un composant aussi courant et provenant de Chine a fait se dresser de nombreuses oreilles.
Une découverte via un pilote maison
« Tarlogic Security a détecté une fonctionnalité cachée qui peut être utilisée comme porte dérobée dans l’ESP32, un microcontrôleur qui permet la connexion Wi-Fi et Bluetooth et qui est présent dans des millions d’appareils IoT grand public », débute le communiqué de la société le 6 mars.
Clik here to view.
Comment a-t-elle procédé ? En développant son propre pilote Bluetooth en C, sans passer par les API mises à disposition par le système d’exploitation. Ce pilote a permis aux chercheurs d’accéder au trafic Bluetooth brut. C’est là qu’ils ont repéré 29 commandes cachées, codées dans le firmware de la puce ESP32. Ces commandes, exploitées, permettent la manipulation de la mémoire et donc d’accéder à de nombreuses informations, en plus d’autoriser l’injection de paquets.
Ce lot de commandes a été initialement qualifié de « porte dérobée » par Tarlogic. Le cas est suivi sous la référence CVE-2025-27840, écope d’une note de sévérité CVSS3.1 de 6,8 sur 10 et a reçu le type « fonctionnalité cachée ». Un qualificatif entouré, dans le cas présent, d’une petite polémique, comme on le verra.
Clik here to view.
Une exploitation pas si simple
Quels sont les risques ? « L’exploitation de cette fonctionnalité cachée permettrait à des acteurs hostiles de mener des attaques par usurpation d’identité et d’infecter de manière permanente des appareils sensibles tels que des téléphones portables, des ordinateurs, des serrures intelligentes ou des équipements médicaux en contournant les contrôles d’audit du code », indique Tarlogic Security dans son communiqué.
Bien que le danger existe, l’exploitation de ces commandes cachées reste complexe. Idéalement, il faut disposer d’un accès bas niveau sur l’appareil que l’on veut ainsi contrôler. L’objectif peut être de collecter des informations sur ce dernier, ou de s’en servir comme base de départ pour mener des attaques contre d’autres équipements connectés.
Les chercheurs indiquent qu’il n’y a que deux manières de procéder : soit obtenir un accès physique (port USB ou UART) soit par l’intermédiaire d’une autre attaque capable d’octroyer un accès distant. Ce qui suppose, dans ce second cas, l’exploitation d’au moins une autre faille pour gagner cet accès, via un logiciel malveillant par exemple.
Si les pirates y arrivent, ils pourraient cacher un malware résident dans la petite quantité de mémoire accompagnant la puce et ainsi obtenir une menace avancée persistante (APT). De là, il est en théorie possible d’infecter d’autres appareils du réseau, si la ou les failles utilisées en premier lieu peuvent être réemployées.
Une porte dérobée ? « Ce n’est pas le cas »
Problème pour Tarlogic, sa communication initiale sur une « porte dérobée » a créé des vagues. On peut d’ailleurs voir à la fin du communiqué une mise à jour datant d’hier, expliquant que la présence de ces commandes a été requalifiée en « fonction cachée », plutôt qu’en « porte dérobée ». L’expression reste dans le texte, mais seulement pour indiquer que ces commandes peuvent être utilisées « comme » une porte dérobée. Les risques, eux, restent.
De nombreux experts ont réagi, critiquant cette qualification. Xeno Kovah par exemple, de la société de sécurité Dark Mentor, n’est pas tendre avec l’annonce des chercheurs. « Ce que les chercheurs mettent en évidence (commandes HCI spécifiques au fournisseur pour lire et écrire la mémoire du contrôleur) est un modèle de conception commun que l’on retrouve dans d’autres puces Bluetooth d’autres fournisseurs, tels que Broadcom, Cypress et Texas Instruments », affirme-t-il ainsi. Selon lui, il ne faudrait donc pas parler de porte dérobée, mais d’API privée.
La société rappelle que l’utilisation du terme backdoor renvoie vers une définition spécifique, qui inclut une « intentionnalité malveillante », avec une volonté de tromper sur le périmètre d’un produit pour mieux en profiter ensuite.
Dans le cas présent, Dark Mentor indique que le protocole Bluetooth dispose d’une couche architecturale nommée Host Controller Interface, c’est-à-dire une interface entre l’hôte (l’ordinateur, le smartphone…) et le contrôleur, autrement dit la puce Bluetooth elle-même. « Si l’hôte souhaite rechercher les appareils BT disponibles à proximité ou se connecter à l’un d’entre eux, il envoie une commande au contrôleur via l’interface HCI pour l’informer de l’action qu’il souhaite effectuer », explique la société.
Un chat est un chat
Surtout, Dark Mentor explique que la spécification Bluetooth Core contient un grand nombre de commandes communes à l’ensemble des constructeurs, ce que l’on attend d’une norme. Toutefois, cette même norme laisse un « blanc » pour qu’un constructeur puisse introduire ses propres commandes, appelées VSC (Vendor specific commands). En outre, Dark Mentor indique que la méthode utilisée par les deux chercheurs espagnols se basent sur une rétro-ingénierie réalisée sur une ROM fournie par Espressif sur son dépôt GitHub. « Un niveau de transparence peu commun », ajoute Dark Mentor.
Le communiqué de Tarlogic Security est ainsi accusé de FUD (Fear, uncertainty and doubt), puisque les commandes spécifiques sont une pratique courante et connue. En outre, dans le cas d’Espressif, elles sont partiellement documentées. Dark Mentor souligne toutefois que seul le communiqué de Tarlogic Security parle de porte dérobée : dans leur présentation à Madrid, les chercheurs espagnols n’en ont pas parlé.
Même son de cloche chez Davi Ottenheimer qui, après analyse, voit simplement des « commandes propriétaires » pour les tests et la fabrication, une pratique qualifiée de « standard ». Selon lui cependant, les travaux présentés gardent leur valeur, car ils explorent la sécurité autour du Bluetooth et comment la tester.
C’est ce qui explique que la fiche CVE contienne la référence CWE-912, le « W » signifiant « weakness » : la découverte est considérée comme une « faiblesse » dans le firmware dans la puce ESP32, non comme une « vulnérabilité ».