Secrets dans le firmware : trois failles, une même cause

Trois nouveaux trainings DVID pour explorer les fuites de secrets dans les systèmes embarqués

Une clé d’API en dur dans le binaire. Un mot de passe administrateur affiché en clair dans la console de debug. Un firmware accepté sans la moindre vérification de signature. Pris isolément, chacun de ces défauts paraît évident à corriger. Mais sur le terrain, ce sont précisément ces erreurs élémentaires qui reviennent dans la majorité des audits de devices IoT/OT.

Trois nouveaux trainings DVID viennent compléter notre catalogue d’avril 2026 autour d’un thème commun : comment les secrets fuitent d’un système embarqué, et comment un attaquant les exploite. Trois scénarios, trois approches, mais une même conclusion — la sécurité d’un device se joue souvent à la conception, pas au déploiement.

Mot de passe codé en dur : quand le binaire devient un trousseau de clés

Le premier training s’attaque à un classique : un identifiant administrateur stocké directement dans le code source du firmware. Le développeur l’a peut-être placé là pendant la phase de prototypage, en pensant le retirer avant la mise en production. Il y est toujours.

Les participants découvrent comment :

• extraire un firmware depuis un microcontrôleur via une interface de debug ou une lecture mémoire ;
• analyser le binaire pour identifier des chaînes de caractères suspectes ;
• isoler les identifiants, clés d’API ou tokens présents en clair ;
• réutiliser ces secrets pour s’authentifier sur le device ou sur les services qu’il consomme.

Ce module illustre une réalité que les équipes firmware sous-estiment souvent : un binaire compilé n’est pas une boîte noire. Avec quelques outils gratuits et un peu de méthode, n’importe quel attaquant ayant accès physique au device peut en extraire les secrets en quelques minutes.

Cette faille est explicitement visée par l’Annexe I du Cyber Resilience Act (CRA) — exigences 2b (gestion des identifiants par défaut) et 2h (protection de la confidentialité des données stockées). Le training couvre directement ces deux points.

Données sensibles dans les logs : la fuite invisible

Le deuxième training adresse une faille plus discrète, mais tout aussi répandue : la journalisation excessive. Pendant la phase de développement, les ingénieurs ajoutent des printf un peu partout pour suivre le comportement du firmware. Mots de passe, tokens, clés de session, contenus de trames réseau — tout y passe. Et tout reste, parce que ces logs ne sont jamais nettoyés avant la mise en production.

Le scénario de ce module simule un device industriel dont la sortie de debug est accessible via UART. Sans exploiter aucune vulnérabilité logique, les participants observent :

• comment un simple branchement série suffit à intercepter des informations sensibles en temps réel ;
• comment des données censées rester internes (identifiants, configuration, payloads applicatifs) transitent par les logs ;
• comment ces fuites permettent à un attaquant de cartographier l’infrastructure derrière le device, sans même le compromettre ;
• comment auditer une politique de logging pour repérer ce qui ne devrait pas y figurer.

Ce point relève de l’exigence 2h du CRA (confidentialité des données traitées) ainsi que de l’exigence 2k (minimisation de la surface d’attaque). Une interface de debug bavarde, c’est une surface d’attaque qui n’a pas lieu d’exister en production.

Vérification de signature firmware : quand n’importe quel binaire devient légitime

Le troisième training touche à un mécanisme critique : le secure boot et la vérification de signature. Beaucoup de devices implémentent un processus de mise à jour OTA. Beaucoup moins vérifient correctement la signature du firmware reçu.

Les cas d’erreurs sont nombreux et le training les passe en revue de manière concrète :

• une vérification présente dans le code… mais jamais réellement appelée ;
• une signature contrôlée uniquement sur l’en-tête, jamais sur le payload complet ;
• une clé publique de vérification stockée dans une zone réinscriptible ;
• un fallback qui accepte les firmwares non signés en cas d’échec de vérification.

Le scénario place le participant en position d’attaquant disposant d’un firmware modifié. L’objectif : faire accepter ce firmware par le device et obtenir l’exécution de code arbitraire dès le prochain démarrage. Une fois l’étape franchie, l’attaquant ne contrôle pas seulement une session — il contrôle l’appareil de façon persistante, y compris après un reset ou une mise à jour.

Cette faille est au cœur de l’exigence 2j du CRA (intégrité des mises à jour) et de l’exigence 2c (protection contre les modifications non autorisées). C’est aussi l’une des cibles privilégiées des attaques sur la chaîne d’approvisionnement logicielle.

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

Comme pour l’ensemble de notre catalogue, ces trois trainings reposent sur du vrai matériel, du vrai firmware et des scénarios représentatifs de ce que rencontrent les équipes en audit ou en réponse à incident. Apprendre en manipulant, pas en théorisant — c’est le principe qui structure chaque module.

Les participants travaillent avec :

• un ESP32 ou un STM32 selon le scénario ;
• une interface UART à 9600 bauds pour l’interaction avec le device ;
• des outils standards d’analyse binaire (strings, objdump, ghidra free edition selon le module) ;
• des scripts Python pour automatiser l’interaction avec le firmware ;
• un environnement reproductible, alignée avec la philosophie de la carte DVID open source.

Chaque étape est progressive. Aucun prérequis avancé n’est demandé : les outils sont introduits au fur et à mesure, et les concepts cryptographiques nécessaires (hash, signature, chaîne de confiance) sont expliqués dans le contexte de l’exercice.

Ce que les participants retiennent

Au-delà de chaque scénario, ces trois modules transmettent des réflexes essentiels pour la conception et l’audit de systèmes embarqués :

• ne jamais stocker un secret en dur dans un firmware destiné à la production ;
• utiliser les zones de stockage sécurisées proposées par le silicium (secure element, eFuse, OTP) ;
• réviser systématiquement les niveaux de log avant chaque release, et désactiver les sorties de debug en production ;
• mettre en place une chaîne de vérification de signature sans fallback permissif ;
• intégrer ces contrôles dans la CI/CD plutôt que de compter sur la vigilance individuelle.

Ces bonnes pratiques sont au cœur de la conformité CRA et de toute démarche de security by design sérieuse.

Pour qui ?

Ces trois modules s’adressent aux équipes qui conçoivent, auditent ou maintiennent des systèmes embarqués :

• ingénieurs firmware et développeurs embarqués ;
• architectes IoT/OT ;
• pentesters spécialisés sur le hardware ;
• responsables sécurité produit ;
• équipes en charge de la conformité CRA.

Aucun prérequis avancé n’est nécessaire : tout est expliqué, démontré et mis en pratique. Une familiarité avec C, Python et les interfaces série facilite la prise en main, mais ne constitue pas un blocage.

Disponibles dès maintenant

Ces trois 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/