Un shell root depuis le trottoir

« Ce n’est qu’une ampoule connectée. » C’est exactement l’argument qui rend la cible intéressante. Présentés à BarbHack 2026, ces travaux d’une équipe de recherche française sur la passerelle d’un grand écosystème d’éclairage connecté aboutissent à une chaîne d’exécution de code complète, obtenue par la radio Zigbee, sans accès physique et sans accès au réseau local de la victime. Terminus : un shell root. Les failles ont été signalées à l’éditeur en novembre 2025 et corrigées dans une mise à jour de sécurité diffusée en février 2026.

Dixième volet de notre couverture de BarbHack. C’est le meilleur exemple que nous ayons vu cette année de l’écart entre la valeur apparente d’un objet et sa valeur réelle pour un attaquant.

Pourquoi la passerelle, et pas l’ampoule

La passerelle occupe une position charnière : elle est raccordée en Ethernet au réseau local de l’utilisateur d’un côté, et parle Zigbee aux lampes et accessoires de l’autre. Elle est donc, par construction, un pont entre un réseau radio ouvert sur l’extérieur et un réseau interne réputé de confiance.

La compromettre ne sert pas à éteindre les lumières. Elle sert à obtenir un point d’entrée persistant sur le réseau, d’où l’on vise ensuite ce qui n’est jamais exposé directement : serveur de stockage, système d’alarme, caméras de surveillance. L’éclairage n’est que la porte.

Étape 1 : ouvrir la boîte pour trouver le bug

Le travail commence par l’obtention du micrologiciel. L’URL de téléchargement des mises à jour officielles a été retrouvée dans un dépôt de notes en ligne, mais le fichier est dans un format propriétaire chiffré, et la clé ne se trouve que sur le matériel. Il a donc fallu démonter l’appareil.

Un port série est bien présent sur la carte, mais limité à la lecture des journaux de démarrage. La méthode retenue est classique et efficace : court-circuiter la puce de mémoire flash pendant le démarrage, ce qui fait échouer le chargement normal et provoque un repli du chargeur d’amorçage vers le port série, avec un shell root à la clé. Un accès SSH permanent est ensuite installé en injectant une clé publique. Dessous, on trouve un Linux embarqué de type OpenWRT avec BusyBox.

Ces manipulations relèvent de la phase de recherche, pas de l’attaque. L’exploitation finale, elle, ne demandera ni démontage, ni câble, ni la moindre proximité physique. C’est une distinction essentielle quand on évalue le risque réel d’une publication de ce type.

Étape 2 : choisir la bonne surface d’attaque

Après avoir écarté le protocole d’accessoires domotiques fonctionnant en TCP, l’équipe se concentre sur la pile Zigbee. Le choix est stratégique : la portée radio de ce protocole peut atteindre une centaine de mètres. L’attaquant n’a donc besoin ni du mot de passe Wi-Fi, ni d’être entré quelque part. Le trottoir suffit.

Reste à s’associer au réseau Zigbee. La procédure d’appariement veut qu’un appareil émette une requête de balisage, que le coordinateur réponde, puis qu’une clé réseau soit transmise, elle-même chiffrée par une clé de liaison. Or, dans cet écosystème, cette clé de liaison est un secret par défaut partagé par tous les appareils, publiquement connu depuis des années. Autrement dit, elle ne protège personne.

Deux façons d’entrer dans la fenêtre d’appariement ont été envisagées :

• Passive : écouter la fréquence et attendre que l’utilisateur ajoute lui-même un équipement.
• Active : brouiller brièvement la fréquence Zigbee pour provoquer la déconnexion puis la ré-association automatique des périphériques existants. L’attaquant choisit son moment.

Étape 3 : le bug, et il vaut le détour

L’appareil embarque deux processeurs : un principal qui gère les services et les couches hautes de Zigbee, et un second dédié à l’émission et à la réception des trames radio, qui convertit les paquets binaires en chaînes lisibles avant de les transmettre à l’application.

La vulnérabilité se niche dans la Zigbee Cluster Library, sur une commande propriétaire ajoutée par le fabricant au cluster « BASIC », destinée à recevoir de longs blocs de configuration. Comme un paquet Zigbee est plafonné à 127 octets, la passerelle reconstitue la configuration par agrégation, via une machine à états.

Voici le mécanisme précis. À l’arrivée du premier paquet, un tampon est alloué dynamiquement à la taille totale annoncée. Pour chaque paquet suivant, la fonction compare consciencieusement la taille du paquet et son décalage à cette taille totale, afin d’empêcher tout dépassement. La validation existe donc, et elle a l’air correcte. Le problème est ailleurs : la taille totale est relue et mise à jour depuis chaque nouveau paquet reçu.

Il suffit alors d’annoncer 0x20 dans le premier paquet, ce qui détermine la taille du tampon, puis 0x70 dans le second. La comparaison se fait désormais contre la nouvelle valeur, la vérification passe, et le tampon déborde. Le contrôle vérifiait une valeur fournie par celui qu’il était censé contrôler.

Étape 4 : du débordement au shell

L’allocateur mémoire est une version d’uClibc datant de 2019, et l’exploitation passe par son mécanisme de consolidation des blocs libres. Le débordement écrase les pointeurs de chaînage d’un bloc adjacent et altère un bit d’état pour le faire passer pour libre, forçant la fusion. Lors de cette consolidation, l’allocateur effectue les écritures nécessaires au retrait du bloc de la liste chaînée : c’est là qu’apparaît une primitive d’écriture arbitraire, contrainte, puisqu’on ne peut y écrire que des valeurs ayant la forme d’adresses.

Trois faiblesses de durcissement font le reste :

• Binaire non compilé en PIE, donc les adresses sont figées et connues d’avance.
• En enchaînant des écritures d’adresses, les chercheurs contournent la contrainte de format et parviennent à écrire un shellcode dans une section mémoire à la fois inscriptible et exécutable.
• Le pointeur d’une fonction appelée systématiquement après réception de chaque paquet Zigbee est écrasé pour pointer vers ce shellcode. Le déclenchement est donc immédiat et fiable.

La charge finale se contente d’appeler system avec une commande contrôlée par l’attaquant.

Étape 5 : le matériel, à moins de dix euros

Côté attaquant, l’équipement tient dans une poche : un dongle radio USB à bas coût. Son micrologiciel d’origine ne sait qu’écouter, il a donc été remplacé par un micrologiciel ouvert capable d’émettre des trames arbitraires, flashé via les broches d’un Raspberry Pi.

Le passage à la pratique a réservé la difficulté habituelle de ce genre de projet : des latences dans les acquittements radio qui faisaient rejeter la connexion par la passerelle. La solution a consisté à modifier le micrologiciel du dongle pour qu’il gère lui-même les réponses de bas niveau, mise au point à l’aide des diodes du dongle en guise de sortie de débogage, faute de débogueur matériel. Ce détail dit bien ce qu’est réellement ce métier.

L’exploit final est un script Python s’appuyant sur Scapy. Il réalise quatre écritures mémoire successives, trois pour injecter le shellcode et une pour détourner le pointeur de fonction. Résultat en démonstration : accès administrateur complet sur la passerelle, avec pour effet de bord l’interruption de l’application mobile légitime.

Ce qu’on en retient chez Humanix

• Un contrôle qui vérifie une valeur fournie par l’attaquant n’est pas un contrôle. C’est la leçon centrale, et elle est réutilisable telle quelle. Dès qu’un protocole réassemble des fragments, la taille totale doit être figée au premier fragment et plus jamais relue ensuite. Si vous faites relire du code réseau, c’est le premier motif à chercher.
• Un secret par défaut partagé par tout un écosystème n’est pas un secret. Il faut le traiter comme une valeur publique dès la conception, et bâtir la sécurité au-dessus, jamais dessus.
• Le modèle de menace, ici, c’est « à portée radio ». Pas « dans le couloir », pas « sur votre Wi-Fi ». Une centaine de mètres, un dongle à quelques euros, et aucune trace côté réseau filaire. Pour un site professionnel équipé d’objets connectés, cela déplace complètement la frontière de la zone de confiance.
• Les contre-mesures sont simples, et l’une d’elles suffit à casser la chaîne. Appliquer les mises à jour, ne jamais exposer ce type d’équipement sur Internet (des milliers restent identifiables par les moteurs de recherche d’objets connectés), et surtout isoler l’IoT dans un VLAN dédié. La compromission radio reste possible, mais elle ne mène plus nulle part. C’est le meilleur rapport effort sur risque de tout cet article.
• Et c’est un cas d’école pour convaincre. Expliquer qu’un objet de confort « élargit la surface d’attaque » ne finance aucun projet de segmentation. Montrer la lampe qui s’éteint puis l’invite root qui apparaît, si. C’est exactement pour cela que nous travaillons par la démonstration : la preuve avant le verdict.

Note. Compte-rendu, à visée pédagogique, d’une conférence de BarbHack 2026 présentant une évaluation de sécurité menée à l’automne 2025 par une équipe de recherche française, dans le cadre de la préparation d’une compétition de sécurité offensive tenue en Irlande. Les vulnérabilités ont fait l’objet d’une divulgation coordonnée auprès de l’éditeur et sont corrigées depuis février 2026 : si vous utilisez ce type d’équipement, vérifiez simplement qu’il est à jour. Dixième volet de notre couverture de l’événement. Des objets connectés sur votre réseau professionnel, et aucune segmentation ? Contactez-nous.