L’ESP32 d’Espressif a été une petite révolution dans le monde des microcontrôleurs, lancé officiellement en 2016, il a généré une véritable vague de produits l’exploitant. Avec le développement de la domotique et de l’IoT, ce composant facile d’accès est hyper abordable a fait son chemin dans énormément d’appareils. Aujourd’hui, il apparait que son code pourrait embarquer des éléments non documentés.

Une solution de développement ESP32
La société de recherche en sécurité informatique Tarlogic Security a présenté lors d’une conférence spécialisée à Madrid cet ensemble d’éléments et tire la sonnette d’alarme sur les possibles implications de celui-ci.
L’ESP32 est une puce que vous utilisez peut-être sans le savoir. Si vous êtes un électronicien, vous connaissez déjà ce type de microcontrôleur. Semblables dans l’esprit aux solutions Arduino, ils permettent des montages programmables très abordables. Si vous avez un peu de domotique chez vous, il est fort probable que vous ayez un ESP32 à bord. Ces puces permettent d’actionner des appareils tiers en suivant des routines programmables simples et proposent également une connectivité Wi-Fi et Bluetooth. Vous êtes un industriel et vous voulez créer un interrupteur connecté ? Il suffit de glisser dans un petit boitier une puce ESP32 et un relai pour pouvoir le faire.
Cette popularité immense, le fait que des puces Espressif se vendent par dizaines millions chaque mois, pose un petit souci de sécurité aujourd’hui. De larges interrogations portent sur la découverte de ces chercheurs en sécurité. Leur analyse montre que ces puces embarquent des éléments très problématiques. Ils permettraient d’abord de verrouiller un dialogue stable sur les appareils équipés. Une seconde étape pourrait être l’usurpation d’identité d’autres appareils sur le même réseau, et même d’appareils de confiance. Enfin, ces éléments non documentés permettraient non seulement de récupérer des données sensibles, mais aussi de propager des failles sur un réseau interne.

Tarlogic présentant sa découverte pendant la conférence RootedCON
Un ESP32 intégré dans un objet connecté anodin pourrait donc servir de cheval de Troie pour compromettre d’autres appareils sur le même réseau. Un ordinateur, un smartphone, une tablette, un autre appareil domotique connecté, voir un routeur.
C’est un ensemble de 29 commandes non documentées par Espressif qui sont présentes dans le firmware pilotant le Bluetooth des ESP32. En offrant un accès à la manipulation de la mémoire embarquée, la possibilité de modifier la mémoire flash, le changement d’adresse MAC de l’appareil et en offrant les ressources nécessaires pour injecter du code. Ces commandes offrent un arsenal d’outils important à une personne tierce qui aurait des intentions malveillantes. Ces éléments non documentés officiellement n’ont été visibles que grâce à des outils de sécurité analysant le flux Bluetooth des puces. Autrement dit, sans un logiciel créé sur mesures à cette fin, les commandes restent parfaitement invisibles à un développeur traditionnel.
La société Tarlogic met en avant plusieurs problèmes majeurs dont la possibilité de glisser une menace dans un ESP32 afin de pouvoir mener à bien des attaques contre des dispositifs sans fil sur le même réseau, en Bluetooth comme en Wi-Fi. Un premier appareil infecté pourrait à son tour attaquer d’autres appareils ESP32 et leur injecter à leur tour ce type de code, créant ainsi un maillage capable ensuite d’attaquer d’autres outils.

Beaucoup de questions en suspens autour des ESP32
La première question est bien sûr liée au scénario de cette intégration de commandes. Est-elle due à une volonté de proposer un outil de compromission à un maximum d’appareils tiers dans le monde ? Ce qui serait un scénario un peu conspirationniste, mais tout à fait crédible. La seconde serait un « oubli » de la part des développeurs de retirer ces commandes qui peuvent être utiles lors d’une phase de développement. Un scénario beaucoup plus pacifiste.
Dans le développement conspirationniste, on peut imaginer une demande du gouvernement chinois de laisser cette porte d’entrée à des milliards d’appareils connectés pour des usages litigieux ; une manière de pouvoir entrer dans des réseaux facilement à travers le monde. Cette vision à du sens même si elle se heurte tout de même à la réalité de terrain. Le problème étant que pour exploiter ces commandes, la solution la plus simple est d’avoir un accès physique à l’appareil et de profiter de son USB ou de son UART pour injecter le code nécessaire. Le scénario des agents secrets déguisés en agents de maintenance qui viennent modifier le code d’appareils ESP32 dans une entreprise comme dans un vieux film des années 70 parait peu probable. Une attaque à distance serait possible mais uniquement dans des appareils « préparés » à l’avance. Des objets connectés commercialisés dans l’intention de ce type d’attaque.
D’un autre côté, le scénario pacifiste se heurte à la survie de ces commandes spécifiques. L’ESP32 est apparu en 2016, 9 ans plus tard, ces commandes sont toujours non seulement toujours présentes, mais surtout toujours non documentées. S’il s’agit d’un oubli de la part des développeurs, il parait étrange qu’elles aient été oubliées aussi longtemps.

Une multiprise électrique programmable sous ESP32
Un troisième scénario découle de ces deux premiers, qu’ils soient vrais ou faux. C’est celui d’un fabricant tiers qui développerait un outil avec un ESP32, par exemple une multiprise connectée ou une solution de développement, et qui injecterait volontairement un code malveillant en amont de la commercialisation de son produit. La puce de base serait « propre » mais pas assez sécurisée avec des développements non documentés possibles. Mais le produit commercialisé serait quant à lui modifié pour exploiter ces failles et se comporter de manière à récupérer des données. Ce scénario parait improbable au premier abord, mais il suffit de se souvenir de la manipulation faite par les services secrets Israéliens sur les bipeurs utilisés par le Hezbollah au Liban pour se dire qu’une stratégie de déploiement ciblé de matériels sous ESP32 peut parfaitement être imaginable.
On peut même imaginer des scénarios mafieux ou ce type de solution seraient déployées à grande échelle en compromettant des appareils en amont, au sortir d’une usine, afin de récolter des données ou d’utiliser ces outils comme chevaux de Troie pour repérer des cibles et effectuer d’autres opérations comme des vols de cryptomonnaies ou une demande de rançon.

Quelles solutions possibles autour de ces produits exploitant l’ESP32?
Difficile de dire quelles contremesures seraient adaptées à l’usage de ces ESP32 est difficile. Peut-être que la solution la plus simple reste toujours de surveiller d’une manière ou d’une autre ce qui entre et sort de votre connexion à internet. En utilisant un routeur spécialisé ou une machine dédiée en aval de votre box opérateur. Il y a peu de chances que vous puissiez détecter vous-même si vos appareils sous puces Espressif posent un souci de sécurité.
La société n’a pas encore communiqué autour de ce problème et aucun outil de validation ne semble avoir été développé pour contrer cette attaque possible pour le moment.
Source : Bleepingcomputer
| 2,5€ par mois | 5€ par mois | 10€ par mois | Le montant de votre choix |





Ceci rappelle l’absolue nécessité de configurer un firewall pour protéger son réseau
Je vous propose cette lecture, plus détaillée mais en anglais :
https://darkmentor.com/blog/esp32_non-backdoor/
@orfait: Merci du lien. Je ne suis pas un média spécialisé ni assez affuté moi-même pour commenter aussi bien sur ce sujet.
@ALF: Oui.
J’ai pas mal d’outils en ESP pour ma domotique mais avec pour l’écrasante majorité du soft modifié la plupart du temps (Tasmota) ou du hardware bidouillable (Shelly)
N’étant pas assez armé pour mettre en critique le code de Tasmota, OpenBK ou Shelly (et ayant toujours en tête les failles de puces) j’ai pris la décision (lors de la mise en place de ma domotique) de couper tous les accès à extérieur des objets connectés y compris la box centrale.
Le peu d’infos venant du Web et nécessaire à mes automatisations Home assistant : injecté via Nodred actif sur une autre minimachine servant à mon autohébergement et mon accès à Home Assistant hors de chez moi est réalisé via un vpn auto hébergé.
Même si cela la domotique moins marrante, je crois que j’ai bien fait… encore une nouvelle qui rappelle l’absolue nécessité de ne pas faire confiance en ce qui concerne les objets connectés.
Si on se rappel de l’affaire XZ piraté par Jia Tia qui comprometait SSH…
je suppose que la backdoor commandité par le gouvernement chinois n’est pas forcément à classer en conspi.
@Imparfaitinconnu: C’est la voie à suivre effectivement même si cela demande pas mal de compétence et une culture qui n’est pas évidente par rapport à l’achat d’une prise commandée ou d’un système de contrôle de chauffage par exemple.
@Luz: C’est juste une manière de présenter les scénarios :)
@Pierre Lecourt: Je te rejoins : c’est un mouvement totalement en contradiction avec le marketing et la volonté des fabricants. C’est d’ailleurs ce qui m’a fait longuement hésité à mettre le doigt dans l’engrenage de la domotique. Les projets « open source » m’ont un peu rassuré mais cela demande pas mal de lecture et du temps pour éviter les obstacles/mauvais achats.
Une boutique pour ceux qui chercheraient des objets connectés déjà modifiés : mediarath. Déjà acheté via cette boutique. Je conseille.
@luz j’avais aussi cela en tête en lisant l’article
@orfait:
C’est en effet plus équilibré comme commentaire que Bleeping Computer: Dans les trucs qui semblent les embêter, on voit en particulier les lectures/écritures en mémoire/flash/registres ou le changement d’adresse MAC.
Alors déjà pour cette dernière en wifi cela fait partie des dispositions contre le pistage des mobiles: Tout smartphone cycle des adresses aléatoires et ne « divulgue » la vraie (programmée à la fabrication) qu’au moment de se connecter à un point d’accès déjà connu… On peut imaginer la volonté de se garder en réserve la possibilité de faire la même chose en bluetooth (même si la moindre portée rends l’affaire moins intéressante pour du pistage).
Pour le reste, les outils de debug et la simple possibilité de MAJ du firmware BT peuvent imposer des accès flash/mémoire/registres.
De toutes manières, quand on veut exploiter une plateforme commerciale, tout ce qui est réservé à la fabrication/test/mise-à-jour (du fait du fondeur des composants ou du fabricant qui les utilise) c’est là qu’il faut aller voir en premier. Et tant qu’il faudra fabriquer sans risquer de faire du jetable en bloquant physiquement toute possibilité de MAJ ou de compréhension ultérieures des problèmes, cela durera.
La possibilité de changer de MAC à la volée ou d’envoyer des trames custom, désormais documentée, risque à mon sens d’amener plus de clients à Espressif que lui en faire perdre!
@imparfaitinconnu:
Pour ma part, si j’avais des trucs connectés en wifi sur ma domotique ce serait sur un réseau dédié et sans connectivité externe.
Comme en prime c’est pas adapté à tout (trop consommateur pour des trucs à pile par exemple, j’ai fait le choix d’utiliser des modules avec des radios spécifiques à cet usage et qui se font leur propre réseau maillé bas débit séparé du reste: Zigbee (moins strictement standardisé que Zwave mais qui a commercialement le vent en poupe) ou Zwave (quand j’ai commencé, Zigbee était quasi inexistant).
Après il y a le choix pour contrôler tout cela de manière unifiée (via les radios utiles, généralement connectées en USB) sans être trop contraint dans ses choix ultérieurs par la partie contrôleur domotique d’un fabricant.
Home-Assistant semble avoir le vent dans le dos, mais je préfère pour ma part Domoticz pour ses capacités de scripting/customisation bien foutues (en plus d’être léger, codé en C++ compilé natif ça aide, n’utilisant que qq % de CPU d’un PI3B, et très stable: Pouvoir compter sur des mois d’uptime entre 2 MAJ kernel obligeant à un reboot, quand ça gère la baraque alarme scriptée perso comprise, c’est fondamental). Il y a Jeedom aussi, mais tout codé PHP très peu pour moi (HA est en Python, ce qui est à mon sens déjà mieux mais pose hélas les pb de dépendances/versions en boulet aux gros projets utilisant ce langage… avec la conteneurisation pour y pallier, pas sans rappeler la situation qui a commencé à faire passer Java de mode quand chaque applicatif s’est mis à traîner sa JVM et dépendances).
@yann
« Pour ma part, si j’avais des trucs connectés en wifi sur ma domotique ce serait sur un réseau dédié et sans connectivité externe. »
si c’est wifi, c’est accessible ^^
@yann
@ender
J’ai pensé bluetooth au début de mon installation (une partie des capteurs Shelly sont d’ailleurs en bt) avant de dériver sur le wifi.
J’étais un peu embêté avec le Zigbee (prix, accessibilité…). Ce serait à refaire (avec l’accumulation de l’expérience), j’envisagerai le zigbee sous un angle différent.
Pour mon installation centrale : Home assistant en version portable grâce au travail d’AlexxIT (github) mis sur un Windows 10 Entreprise version 2019 LTSC installé sur un MINIX Neo Z83-4 Z8350 isolé du Web
Je sais il y a mieux comme optimisation sur la machine de centralisation. Mais j’ai eu des problèmes lors de l’installation d’AgentDVR (système de caméra) via une installation Linux sur cette même machine. Ce volet de mon installation restera à revoir.
J’ai choisi Home Assistant parce que pas trop de dev en dur et une grosse communauté fr. Quand tu débutes, c’est un gros plus. Je regarderai en parallèle pour tester Domoticz ou Jeedom
Nota : le wifi ne consomme pas tant que cela sur mes outils équipé en CR123.
@yann:
@imparfaitinconnu:
Il existe aussi nymea.
https://nymea.io/
@Keneda:merci pour nymea. Je ne connaissais pas, l’architecture logicielle est intéressante.
La réponse de Espressif (qui vaut ce qu’elle vaut, mais qui a le mérite d’exister) : https://www.espressif.com/en/news/Response_ESP32_Bluetooth
@gUI merci
je trouve leur réponse est clair et transparente :
oui ces commande ne sont pas documenté
non elles ne sont pas une backdor
oui elles servent a du débug
oui elle seront ajouter a la doc pour éviter les théorie conspirationniste.
mais alors pourquoi ne pas les avoir mises des le début……..