UART exposé, MQTT vulnérable : les portes d’entrée qu’on oublie de fermer

Deux nouveaux trainings DVID sur les services oubliés et les interfaces qui ne devraient pas être là

Sur un device IoT/OT en production, il y a ce qui est documenté — et ce qui reste de la phase de développement. Les interfaces de debug, les ports techniques, les services laissés en écoute pour faciliter la mise au point. La plupart du temps, personne ne les regarde après la mise sur le marché. Et c’est exactement par là que passent les attaquants.

Deux nouveaux trainings DVID viennent illustrer ce phénomène avec deux scénarios distincts mais complémentaires : un débogage UART laissé actif sur un device industriel, et une exécution de code à distance sur un broker MQTT mal configuré. Deux portes d’entrée différentes, mais une même logique : ce qui est utile au développeur l’est aussi à l’attaquant.

Debug UART non sécurisé : la console du développeur, livrée avec le produit

Le premier training revient à la base : l’interface série. Sur la quasi-totalité des microcontrôleurs, l’UART est utilisé pendant la phase de développement pour afficher des logs, exécuter des commandes de test ou flasher un nouveau firmware. Une fois le device en production, cette interface devrait être désactivée, ou au minimum protégée. Dans la pratique, elle ne l’est pas.

Le scénario place le participant face à un device dont le shell de debug reste accessible via UART, sans authentification. Les participants découvrent comment :

• localiser physiquement les broches UART sur une carte non documentée ;
• établir une connexion série fonctionnelle avec les bons paramètres (baudrate, bits, parité) ;
• énumérer les commandes disponibles dans le shell de debug ;
• lire et écrire des zones mémoire arbitraires depuis cette interface ;
• modifier le comportement du firmware en cours d’exécution.

Ce que ce training met en évidence, c’est que l’UART de debug n’est pas une simple interface de logs : c’est souvent une porte d’entrée qui donne un accès complet au runtime du device, contournant toutes les protections applicatives.

Cette faille relève directement de l’Annexe I du CRA — exigence 2k (minimisation de la surface d’attaque) et exigence 2d (contrôle d’accès). Elle est aussi l’un des premiers points de contrôle de toute évaluation de sécurité hardware sérieuse.

RCE sur un broker MQTT : quand le bus de messages devient un bus d’attaque

Le second training change d’échelle. On quitte le device pour aller voir l’infrastructure qui l’entoure — et plus précisément le broker MQTT, ce composant central qui orchestre les échanges entre dizaines, centaines ou milliers de devices IoT.

MQTT est un protocole simple, léger, conçu pour les contraintes des objets connectés. Trop simple, parfois. Beaucoup de déploiements en production reposent sur des configurations laissées par défaut : authentification désactivée, ACL absentes, topics ouverts en lecture/écriture à tous les clients. Et lorsque le broker exécute en plus du code applicatif côté serveur — règles de routage, scripts de transformation, plugins — la combinaison devient explosive.

Le scénario du training place le participant en position d’attaquant disposant uniquement d’un accès réseau au broker. L’objectif : passer d’un simple CONNECT à une exécution de code arbitraire sur la machine qui héberge le broker. Les participants explorent :

• comment énumérer les topics actifs et identifier la structure d’un déploiement MQTT ;
• comment exploiter une mauvaise validation des messages côté broker pour injecter du code ;
• comment utiliser les mécanismes de routage interne pour pivoter vers d’autres devices ;
• comment durcir une configuration MQTT pour rendre ce type d’exploitation impossible.

L’intérêt de ce module dépasse le simple cas du protocole MQTT. C’est une démonstration concrète de ce qui se passe quand un composant d’infrastructure pensé pour la simplicité de déploiement se retrouve exposé sans les couches de sécurité qui devraient l’accompagner. Le même schéma se rejoue avec CoAP, AMQP ou des protocoles propriétaires.

Cette problématique recoupe plusieurs exigences du CRA : 2c (intégrité), 2d (contrôle d’accès), 2k (minimisation de la surface d’attaque) et 2g (protection contre les communications non autorisées).

Une approche 100 % pratique, fidèle à l’ADN DVID

Comme pour l’ensemble de nos modules, ces deux trainings reposent sur du vrai matériel et de vrais services en exécution. Apprendre en manipulant, pas en théorisant — c’est ce qui distingue un pentester capable de mener un audit d’un ingénieur qui aura simplement lu un document.

Les participants travaillent avec :

• un microcontrôleur ESP32 ou STM32 pour le scénario UART ;
• un broker MQTT (Mosquitto ou équivalent) déployé dans un environnement isolé pour le scénario réseau ;
• des outils standards : screen / minicom / pyserial côté UART, mosquitto-clients et scripts Python côté MQTT ;
• un kit de scripts d’exploitation et de durcissement, pensés pour être réutilisables en environnement professionnel.

Chaque étape est progressive et reproductible. L’objectif n’est pas seulement de réussir l’exploitation, mais de comprendre exactement pourquoi elle fonctionne — et donc comment la prévenir.

Ce que les participants retiennent

Au-delà de chaque scénario, ces deux modules transmettent une série de réflexes que toute équipe sérieuse en sécurité IoT/OT devrait avoir intégrés :

• désactiver les interfaces de debug en production, ou les protéger par une authentification matérielle ;
• ne jamais considérer l’accès physique comme un scénario hors-périmètre — c’est précisément le scénario que cible le CRA ;
• imposer une authentification forte sur les brokers MQTT et tout service de messaging IoT ;
• segmenter les topics et appliquer des ACL strictes par device ou par classe de device ;
• traiter le broker comme un composant critique : monitoring, mise à jour, durcissement OS sous-jacent ;
• valider rigoureusement tout payload entrant côté broker avant de l’interpréter.

Pour qui ?

Ces deux modules s’adressent aux profils techniques qui conçoivent, opèrent ou auditent des architectures IoT/OT :

• ingénieurs firmware et développeurs embarqués ;
• architectes IoT/OT et ingénieurs cloud ;
• pentesters orientés hardware et infrastructure ;
• équipes SOC et CERT amenées à investiguer des incidents IoT ;
• responsables sécurité produit en préparation de la conformité CRA.

Aucun prérequis avancé n’est nécessaire. Une connaissance de base des réseaux TCP/IP et des interfaces série facilite la prise en main, mais chaque concept est introduit au fil des exercices.

Disponibles dès maintenant

Ces deux trainings s’intègrent naturellement dans un parcours de montée en compétence IoT/OT, que ce soit pour renforcer une équipe interne, préparer la conformité CRA ou structurer une démarche de sécurité by design.

En savoir plus : https://dvid.eu/fr
Nous contacter : https://dvid.eu/fr#contact
Suivre notre actualité : https://www.linkedin.com/company/dvid/