Les commandes Bluetooth HCI de propriétaire caché dans le microcontrôleur ESP32 pourraient présenter un risque de sécurité

La sécurité est difficile. Tout comme les systèmes ESPRESSIF ont annoncé PSA niveau 2 pour le microcontrôleur ESP32-C6, la société d’Espagne de cybersécurité basée sur l’Espagne Tarlogic a publié leurs résultats sur une fonctionnalité Bluetooth cachée qui peut être utilisée comme dérobée dans la génération précédente ESP32, et a fait une présentation en espagnol à RootCon 2025.

Plus précisément, ils ont trouvé des commandes propriétaires HCI HCI (interface du contrôleur hôte) utilisées utilisées pour lire et écrire la mémoire du contrôleur, et généralement utilisées pour le débogage. Cependant, ils pourraient également faciliter les attaques de la chaîne d’approvisionnement, la dissimulation des délais dans le chipset ou l’exécution d’attaques plus sophistiquées. Tarlogic l’a initialement appelé une «porte dérobée», mais certains ont contesté la réclamation (plus à ce sujet plus tard), et la société a finalement publié une mise à jour le dégradant à une fonctionnalité «cachée»:

Nous tenons à préciser qu’il est plus approprié de se référer à la présence de commandes HCI propriétaires – qui permettent des opérations telles que la lecture et la modification de la mémoire dans le contrôleur ESP32 – comme une «fonctionnalité cachée» plutôt qu’une «porte dérobée».
L’utilisation de ces commandes pourrait faciliter les attaques de la chaîne d’approvisionnement, la dissimulation des délais dans le chipset ou l’exécution d’attaques plus sophistiquées. Au cours des prochaines semaines, nous publierons d’autres détails techniques à ce sujet.

Selon les chercheurs, les mauvais acteurs pourraient potentiellement infecter non seulement les puces ESP32 elles-mêmes, mais aussi les appareils qui se connectent à eux via Bluetooth tels que les smartphones ou même les appareils médicaux:

L’exploitation de cette fonctionnalité cachée permettrait aux acteurs hostiles de mener des attaques d’identité et d’infecter en permanence des appareils sensibles tels que les téléphones mobiles, les ordinateurs, les verrous intelligents ou l’équipement médical en contournant les commandes d’audit de code.

Cela semble effrayant, d’autant plus qu’un milliard de dispositifs ESP32 sont dans la nature. Regardons de plus près.

Les outils utilisés pour la découverte comprenaient un pilote de périphérique Bluetooth basé sur Libusb et des sockets scapuliés développés par Antonio Vazquez de Tarlogic, et la documentation ROM ELF à partir d’EspressIF. Ceux-ci leur ont permis d’activer l’accès brut au trafic Bluetooth, et après les travaux d’ingénierie rétro-inverse, ils ont finalement découvert 29 commandes HCI sans papiers dans le firmware Bluetooth ESP32. Ces commandes peuvent être utilisées pour lire et écrire RAM et Flash, l’usurpation d’adresse MAC et l’injection de paquets LMP / LLCP.

La vulnérabilité de sécurité Bluetooth ESP32 a son propre CVE (CVE-2025-27840) avec un score de gravité moyen de 6,8 points. Targlogic dit qu’ils fourniront plus de détails techniques plus tard et ont encore besoin d’un matériel spécifique qui leur permettra d’implémenter des attaques avancées.

Un article de Xeno Kovah de Dark Mentor LLC fournit plus d’informations. Tout d’abord, il rejette l’évaluation initiale de la «porte dérobée»:

Ce que les chercheurs mettent en évidence (commandes HCI spécifiques aux fournisseurs pour lire et écrire la mémoire du contrôleur) est un modèle de conception courant trouvé dans d’autres puces Bluetooth d’autres fournisseurs, tels que Broadcom, Cypress et Texas Instruments. Les commandes spécifiques aux fournisseurs de Bluetooth constituent effectivement une «API privée», et le choix d’une entreprise de ne pas documenter publiquement leur API privée ne constitue pas une «porte dérobée».

Mis à part les réclamations de la porte dérobée, ils ont également tenté d’évaluer si cette fonctionnalité constitue une vulnérabilité de sécurité. La réponse courte est que cela dépend. La réponse plus longue explique que ce n’est pas une vulnérabilité pour les clients qui ne font pas de distinction entre les privilèges de l’hôte et le contrôleur. Cependant, ce serait pour un client qui ne veut pas d’espace utilisateur compromis sur l’hôte pour garantir automatiquement un firmware de contrôleur Bluetooth compromis. Dans tous les cas, ils considèrent que l’utilisation des VSC accordant la capacité de lire et d’écrire de la mémoire, du flash ou des registres est une mauvaise conception de sécurité, mais elle affecte tous les fournisseurs Bluetooth.

Via Bleeping Computer

Retrouvez l’histoire de Raspberry Pi dans cette vidéo :