Une porte dérobée non documentée découverte dans une puce Bluetooth utilisée par des milliards d’appareils
(bleepingcomputer.com)- Des commandes Bluetooth absentes de la documentation publique ont été découvertes dans l’ESP32, largement utilisée dans les appareils IoT ; l’impact potentiel est important, cette puce équipant plus d’un milliard d’appareils en 2023
- Lors de RootedCON, Tarlogic Security a révélé 29 commandes propres au fournisseur dans le firmware Bluetooth de l’ESP32, signalant qu’elles permettaient la lecture/écriture en RAM et en Flash, l’usurpation d’adresse MAC et l’injection de paquets LMP/LLCP
- Ces commandes peuvent conduire à l’usurpation d’appareils de confiance, à un accès non autorisé aux données, à des déplacements latéraux dans le réseau et à l’obtention d’une persistance de longue durée ; elles sont suivies sous l’identifiant CVE-2025-27840
- La possibilité d’une exploitation à distance dépend de la manière dont la pile Bluetooth de l’appareil traite les commandes HCI, et devient plus pertinente en présence d’un firmware malveillant, d’une mise à jour malveillante ou d’un accès root déjà obtenu
- Espressif affirme qu’il s’agit de commandes de debug destinées aux tests internes et qu’elles ne peuvent pas, à elles seules, créer un risque de sécurité pour l’ESP32, mais prévoit de supprimer les commandes non documentées dans une future mise à jour logicielle
Commandes Bluetooth non documentées restées dans l’ESP32
- La puce ESP32 du fabricant chinois Espressif contient des commandes Bluetooth absentes de la documentation publique
- L’ESP32 est un microcontrôleur qui fournit une connectivité Wi‑Fi et Bluetooth aux appareils IoT, et équipait plus d’un milliard d’appareils en 2023
- Les commandes découvertes peuvent être utilisées pour les actions suivantes
- Usurpation pour se faire passer pour un appareil de confiance
- Accès non autorisé aux données
- Déplacement vers d’autres appareils du réseau
- Possibilité d’obtenir une persistance de longue durée
Découverte de Tarlogic et outils de recherche
- Miguel Tarascó Acuña et Antonio Vázquez Blanco, de l’entreprise espagnole Tarlogic Security, ont présenté leurs résultats à RootedCON, à Madrid
- Les chercheurs estiment que l’intérêt pour la recherche en sécurité Bluetooth a diminué, mais pas parce que le protocole ou ses implémentations seraient devenus plus sûrs
- Beaucoup d’attaques publiées récemment ne disposaient pas d’outils fonctionnels, ne fonctionnaient pas sur du matériel générique, ou dépendaient d’outils anciens et non maintenus, peu adaptés aux systèmes modernes
- Tarlogic a développé un nouveau pilote USB Bluetooth en C
- Indépendant du matériel et multiplateforme
- Capable d’accéder directement au matériel sans dépendre des API propres à chaque OS
- Permettant un accès brut au trafic Bluetooth
Contrôle bas niveau permis par les commandes
- Des commandes propres au fournisseur cachées ont été identifiées dans le firmware Bluetooth de l’ESP32
- L’opcode est
0x3F - Elles permettent de contrôler les fonctions Bluetooth à bas niveau
- L’opcode est
- Au total, 29 commandes non documentées ont été découvertes
- Leurs principales fonctions concernent
- La manipulation de la mémoire RAM et Flash
- L’usurpation d’appareil via l’usurpation d’adresse MAC
- L’injection de paquets LMP/LLCP
- Comme Espressif n’a pas documenté publiquement ces commandes, il est possible qu’elles n’aient pas été destinées à être accessibles ou qu’elles soient restées là par erreur
- Ce problème est suivi sous CVE-2025-27840
Possibilités d’attaque et contraintes réalistes
- Les chercheurs estiment que ces commandes peuvent entraîner un risque d’implémentation malveillante au niveau OEM ou d’attaque de la chaîne d’approvisionnement
- La possibilité d’une exploitation à distance dépend de la manière dont la pile Bluetooth de l’appareil traite les commandes HCI
- Dans les conditions suivantes, l’exploitation à distance pourrait devenir plus probable
- Si l’attaquant a déjà obtenu un accès root
- Si un malware a été implanté
- Si une mise à jour malveillante ouvrant un accès bas niveau a été déployée
- Si un firmware malveillant ou une connexion Bluetooth rogue est impliqué
- En général, l’accès physique à l’interface USB ou UART de l’appareil constitue un scénario d’attaque plus réaliste
- Tarlogic estime que compromettre un appareil IoT contenant un ESP32 permettrait de cacher un APT dans la mémoire de l’ESP, de contrôler l’appareil via Wi‑Fi/Bluetooth et de mener des attaques Bluetooth ou Wi‑Fi contre d’autres appareils
- Les commandes capables de modifier la RAM et la Flash peuvent mener à une prise de contrôle complète de la puce ESP32 et à une persistance au niveau de la puce
Explications d’Espressif et plan de correction
- BleepingComputer a d’abord demandé un commentaire à Espressif, sans recevoir de réponse immédiate
- Espressif a ensuite publié une position officielle sur la découverte de Tarlogic
- L’entreprise explique que les fonctionnalités découvertes sont des commandes de debug destinées aux tests internes
- Ces commandes font partie de l’implémentation du protocole HCI (Host Controller Interface) utilisé par la technologie Bluetooth
- HCI est utilisé à l’intérieur du produit pour la communication entre les couches Bluetooth
- Espressif estime que la présence de commandes de debug ne peut pas, à elle seule, créer un risque de sécurité pour la puce ESP32
- Elle prévoit toutefois de fournir un correctif logiciel supprimant les commandes non documentées
Correction terminologique et mises à jour de l’article
- Dans la mise à jour du 9 mars 2025, le titre et le corps de l’article ont été modifiés pour tenir compte des préoccupations liées à l’emploi du terme « backdoor » pour désigner ces commandes non documentées
- Le 8 mars 2025, la position de Tarlogic a été ajoutée
- Le 9 mars 2025, l’identifiant CVE a été ajouté
- Le 10 mars 2025, la position officielle d’Espressif a été ajoutée
1 commentaires
Avis sur Hacker News
Je trouve que le titre est un peu trompeur. Si j’ai bien lu, la backdoor dont il est question ici permet à l’ordinateur de lire et d’écrire la mémoire et des fonctions bas niveau de son propre adaptateur USB Bluetooth.
Ça ne semble pas exploitable sans fil. Ces commandes de débogage non documentées sont courantes, et j’ai déjà vu des fonctionnalités similaires sur des adaptateurs WiFi et des récepteurs GPS. Elles n’étaient simplement pas documentées, mais ont été découvertes par rétro-ingénierie du firmware de la puce ou du driver du fournisseur, et ce n’est pas un problème ayant en soi un impact majeur. Si cela permet du firmware non signé, alors c’est tout aussi vulnérable.
Si c’est utilisable depuis autre chose que l’hôte, alors c’est une tout autre histoire.
Espressif a été presque exceptionnellement ouvert dans ce domaine. Ils ont contribué à une toolchain Rust open source pour leurs puces, et ont même encouragé publiquement la rétro-ingénierie de la pile modem qu’ils ne peuvent pas publier à cause de code sous licence. Je n’aime pas que la contrepartie de la moindre attitude ouverte soit une mauvaise publicité nuisible.
« Selon la manière dont la pile Bluetooth de l’appareil traite les commandes HCI, une exploitation à distance de la backdoor pourrait être possible via un firmware malveillant ou une connexion Bluetooth malveillante. »
En bref, si vous avez une pile de drivers sûre et que vous faites confiance à tout le code local, les extensions HCI propres au fournisseur ne posent pas de problème.
Cela dit, les extensions HCI peuvent facilement devenir des trous de sécurité. Le problème est que HCI mêle des entrées contrôlées par l’attaquant, des interfaces complexes et un parsing délicat. Comme l’a montré la faille BleedingTooth il y a quelques années, il est facile de se tromper.
L’existence de ce type de fonctionnalité facilite aussi le pivot depuis d’autres vulnérabilités, mais sur la plupart des systèmes, cela ressemble plutôt à un fruit à portée de main.
[0] https://google.github.io/security-research/pocs/linux/bleedi...
Même en laissant de côté le pire cas des API web, imaginons que vous exécutiez, par prudence, un logiciel auquel vous faites à moitié confiance dans une triple VM imbriquée. Ce logiciel avance une raison plausible d’avoir besoin d’un accès Bluetooth, et vous accordez l’exception. Le résultat ne vous plaît pas, vous supprimez le logiciel et réinitialisez aussi les trois couches de VM. Tout semble terminé, mais ce que le malware a installé sur l’ESP pendant qu’il avait l’accès pourrait encore être là.
Un accès non documenté à ses propres sous-périphériques peut être vraiment problématique, surtout quand la persistance entre en jeu.
On peut imaginer un cas où l’ESP32 n’est pas utilisé comme SoC autonome, mais comme « modem » WiFi/Bluetooth relié par une liaison série à un système hôte.
En théorie, un attaquant pourrait utiliser des commandes non documentées pour scanner, usurper ou attaquer des appareils Bluetooth à proximité. Peut-être même sans obtenir les droits root sur l’appareil qui héberge l’ESP32.
Ils vont être surpris d’apprendre qu’avec les droits root dans un OS, on peut réécrire le firmware d’un disque dur.
Ce que les chercheurs ont trouvé, c’est une fonctionnalité matérielle non documentée qui permet à quelqu’un disposant déjà de droits d’exécution de code d’accéder plus profondément que prévu, à bas niveau, à la pile WiFi de l’ESP32.
Appeler ça une « backdoor » relève du pur clickbait.
Je suis perplexe. Cela veut dire qu’il existe quelques commandes non documentées dans la pile Bluetooth ? Si seul du code déjà en cours d’exécution sur l’appareil peut y accéder, ça me semble difficile à qualifier de backdoor.
Ça ne ressemble pas à de l’exécution de code à distance.
Donc il est possible qu’un programme en espace utilisateur, voire pire, un programme WebBLE, ajoute une charge malveillante persistante à l’adaptateur. Une balise de traçage qui subsiste après le remplacement du disque, c’est effrayant, mais ce n’est pas de l’exécution de code à distance.
En théorie, il faut pouvoir accéder à bas niveau à la puce radio Bluetooth connectée elle-même, donc cela me paraît quelque peu attendu.
Les appareils qui disposent de ce genre d’interface bas niveau sont préférables. Le problème est peut-être moins son existence que le manque de documentation.
Autrefois, on utilisait des commandes de lecture/écriture mémoire via USB sur des puces radio Qualcomm pour déverrouiller des appareils verrouillés et en reprendre possession. C’était une lecture/écriture complètement hors bande, donc peut-être pas idéal, mais si ici l’accès n’est possible que depuis le code flashé, c’est plutôt mieux.
Slides en espagnol : https://www.documentcloud.org/documents/25554812-2025-rooted...
En résumé, ils ont rétro‑ingénié le firmware et trouvé des commandes HCI qui permettent de faire des choses comme lire/écrire la mémoire, envoyer des paquets, définir l’adresse MAC.
Ce n’est pas vraiment une backdoor. Je ne sais pas si ce sont les chercheurs qui l’ont appelée ainsi, si c’est parce que la présentation est en espagnol, ou si ce sont les journalistes qui l’appellent backdoor pour générer plus de clics.
Pour utiliser ces commandes, il faut un accès arbitraire permettant d’envoyer des commandes HCI à l’appareil. Autrement dit, on contrôle déjà l’appareil et son fonctionnement. Ce n’est pas exploitable à distance via la liaison radio. Quel que soit l’exploit, il faut déjà avoir le contrôle total de l’appareil, et à ce stade, la capacité de changer l’adresse MAC ou d’envoyer des paquets n’a rien de surprenant.
La recherche est intéressante, mais l’emballage en « backdoor » est vraiment décevant. Je ne sais pas à qui revient la responsabilité du terme, mais je parierais sur les journalistes.
Pour une analogie plus familière, imaginez qu’on découvre que le contrôleur Ethernet d’une puce IoT courante peut changer son adresse MAC ou envoyer des paquets arbitraires sur instruction du firmware. C’est la même histoire, sauf qu’ici il s’agit de Bluetooth.
https://www.tarlogic.com/news/backdoor-esp32-chip-infect-ot-...
C’est pour cela qu’il existe des outils Windows comme https://macaddresschanger.com/ et bdaddr sous Linux. La plupart semblent être des clones de conceptions CSR, et la commande pour définir l’adresse est bien connue. https://sources.debian.org/src/bluez/5.55-3.1%2Bdeb11u1/tool...
Là, on a même supprimé l’exigence du câble Ethernet.
On peut rouler dans un van blanc marqué « Free Candy / BLE Persistent Threats », dépouiller des appareils en passant par un détecteur de métaux en route vers la Chine.
C’est sans fil, capable de se propager comme un ver, d’envoyer des paquets arbitraires et d’usurper n’importe quel appareil, et vous ne voyez toujours pas le problème ?
Je déteste ce genre d’articles sensationnalistes. J’ai l’impression qu’Espressif va maintenant se sentir poussée à devenir plus fermée.
Sur les desktops et les portables, on installe sans sourciller des pilotes blob binaires opaques qui tournent dans l’espace noyau, et on n’a même pas d’accès root sur son propre téléphone contrôlé par le cloud ; mais quelques commandes bas niveau non documentées de l’ESP32, qui exigent que l’appareil soit déjà compromis, deviennent un vecteur de menace digne des gros titres.
Je me demande vraiment si quelque chose ne s’est pas perdu dans la traduction. À une autre époque, on aurait simplement trouvé ça cool et cherché comment le transformer en radio logicielle.
La recherche elle-même est bonne, mais le titre est mauvais. Comme vecteur d’attaque, cela nécessite un accès physique, et dans presque tous les cas, c’est quelque chose qu’on pouvait déjà faire par d’autres moyens.
Un meilleur titre serait quelque chose comme « Découverte de commandes non documentées dans une puce Bluetooth courante ».
Ce titre est mensonger. Une backdoor dans une puce Bluetooth devrait permettre à un attaquant sans fil d’obtenir une exécution de code sur la puce.
Cet article parle du fait que le pilote de périphérique de l’appareil connecté peut obtenir une exécution de code sur la puce, ce qui ne franchit pas de frontière de sécurité.
Dans un écosystème médiatique qui fonctionnerait correctement, il faudrait une correction, et la réputation du média qui a écrit l’article devrait en prendre un sérieux coup. Malheureusement, cela n’arrivera pas.