Test d’intrusion IoT : ce que nous attaquons et trouvons
Ce que couvre un pentest IoT, des ports de debug et du firmware à la radio, aux applications et au cloud, les failles les plus fréquentes et comment vous préparer.
Zyberum Security Team · Publié le · 7 min de lecture
Un produit IoT n’est jamais un simple appareil. C’est du matériel, un firmware, une liaison radio, une application et un service cloud, et il suffit à un attaquant que l’un d’eux soit faible. Un test d’intrusion IoT les examine tous ensemble, car les attaques intéressantes franchissent généralement les frontières entre eux.
Voici ce que nous faisons réellement lors d’un tel test, et ce que nous retrouvons sans cesse.
Les cinq couches que nous attaquons
1. Matériel
Nous commençons par ouvrir l’appareil. Sur la carte, nous cherchons les interfaces de debug (UART, JTAG, SWD), les points de test et la puce flash. Une console série qui donne directement un shell root reste l’un des résultats les plus fréquents sur le terrain.
Si le port de debug est verrouillé, nous essayons d’obtenir le firmware autrement : en lisant directement la puce flash, ou en provoquant un glitch pour que le processeur saute une vérification.
2. Firmware
Une fois le firmware extrait, nous le décompressons et nous le lisons. Questions typiques :
- Y a-t-il des mots de passe, des clés d’API ou des clés privées codés en dur ?
- Quels composants open source contient-il, et de quand datent-ils ?
- Existe-t-il une chaîne de secure boot, et chaque étape vérifie-t-elle vraiment la suivante ?
- Comment les mises à jour sont-elles contrôlées ? Signées, ou simplement comparées à un checksum ?
3. Radio et interfaces locales
Bluetooth LE, Wi-Fi, Zigbee, Thread, LoRaWAN ou une liaison sub-GHz propriétaire : nous capturons le trafic, nous le rejouons et nous le modifions. L’appairage est une cible de choix, car beaucoup d’appareils acceptent quiconque se présente au bon moment.
4. Application
L’application compagnon en sait souvent plus qu’elle ne devrait. Nous la décompilons, nous y cherchons des secrets et nous observons comment elle communique avec l’appareil et le cloud.
5. Cloud et API
Ici, nous testons si un client peut atteindre les appareils d’un autre client. Le contrôle d’accès défaillant sur les identifiants d’appareil est le grand classique : changez un seul chiffre dans une requête et vous contrôlez le produit de quelqu’un d’autre.
Ce que nous trouvons le plus souvent
| Résultat | Pourquoi c’est important |
|---|---|
| Console de debug ouverte (UART/JTAG) | Contrôle total avec un accès physique, et un chemin rapide vers le firmware |
| Identifiants ou clés codés en dur dans le firmware | Un seul appareil extrait compromet toute la flotte |
| Mises à jour non signées ou faiblement vérifiées | Un attaquant peut installer son propre firmware |
| Composants obsolètes avec des vulnérabilités connues | Les exploits publics fonctionnent tels quels |
| Appairage sans véritable authentification | N’importe qui à proximité peut prendre le contrôle de l’appareil |
| L’API cloud fait confiance à l’identifiant de l’appareil | Accès aux appareils et aux données d’autres clients |
| Même mot de passe par défaut sur tous les appareils | Compromission de masse depuis Internet |
Rien de tout cela ne demande de techniques exotiques. Il faut quelqu’un qui regarde.
Comment se déroule un test
- Appel de cadrage. Quinze minutes pour nous mettre d’accord sur l’appareil, ses interfaces et la profondeur du test.
- Démontage et firmware. Nous entrons dans l’appareil et nous extrayons ce qui y tourne.
- Attaque. Matériel, radio, application et cloud, puis les combinaisons entre eux.
- Rapport et restitution. Chaque résultat avec sa preuve de concept, sa sévérité et un correctif, expliqué à vos ingénieurs.
- Retest. Nous vérifions que les correctifs tiennent.
Comment vous préparer
- Envoyez au moins deux appareils. L’un d’eux pourrait ne pas survivre.
- Fournissez un environnement de test dans le cloud, séparé de la production.
- Donnez-nous les images firmware et la documentation si vous en avez. Cela fait gagner des jours.
- Désignez un ingénieur capable de répondre rapidement aux questions.
Pourquoi maintenant
Depuis le 1er août 2025, les exigences de cybersécurité de la directive sur les équipements radioélectriques (RED) s’appliquent aux appareils sans fil, et à partir de décembre 2027 le Cyber Resilience Act s’appliquera à presque tout ce qui comporte des éléments numériques. Les deux textes attendent que les produits soient testés avant leur mise sur le marché.
Vous voulez savoir comment votre appareil résiste ? Découvrez nos tests de sécurité IoT ou demandez un devis de pentest.
FAQ
Questions fréquentes
De quoi avez-vous besoin de notre part pour un pentest IoT ?
Deux ou trois appareils, idéalement dont un avec l’accès debug activé, l’application compagnon, un compte de test pour le cloud et toute la documentation existante. Plus nous recevons d’éléments, plus nous pouvons aller en profondeur dans le même temps.
Le test va-t-il endommager l’appareil ?
Les attaques matérielles peuvent le faire. Nous ouvrons les appareils, soudons sur des points de test et retirons parfois des puces flash, c’est pourquoi nous demandons plus d’un exemplaire.
Un pentest IoT suffit-il pour le Cyber Resilience Act ?
C’est une pièce importante : le CRA exige que les produits soient livrés sans vulnérabilités exploitables connues et qu’ils soient testés. Il vous faut aussi des processus de développement sécurisé, une gestion des vulnérabilités et une documentation.