Pentest IoT : Méthodologie Complète OWASP et Outils

Le marché de l'IoT dépasse les 15 milliards de dispositifs connectés en 2026, et chaque objet constitue un point d'entrée potentiel dans le système d'information de son propriétaire. Les audits de sécurité IoT que nous réalisons révèlent systématiquement des vulnérabilités critiques : mots de passe par défaut jamais modifiés, firmwares non signés téléchargeables sans authentification, communications en clair entre le capteur et le cloud, et API backend sans contrôle d'accès granulaire. Le référentiel OWASP IoT Top 10 fournit un cadre structuré pour évaluer ces risques dans un contexte où les incidents de sécurité IoT ont augmenté de 300% entre 2022 et 2025 selon le rapport annuel de Unit 42 de Palo Alto Networks. Son application pratique nécessite cependant une adaptation significative selon le type de dispositif audité. Un capteur industriel Modbus/TCP ne se teste pas comme une caméra IP Wi-Fi grand public, même si les deux partagent des vulnérabilités fondamentales communes. Ce guide détaille chaque phase du pentest IoT avec les outils, techniques et pièges à éviter, enrichi de retours d'expérience concrets issus de missions d'audit sur des dispositifs déployés en production dans des environnements critiques où la disponibilité du service prime sur toute autre considération de sécurité.

Cartographier la surface d'attaque d'un dispositif IoT

La première phase du pentest IoT consiste à identifier exhaustivement les vecteurs d'attaque du dispositif cible. Contrairement au pentest web où la surface d'attaque se limite aux endpoints HTTP, un objet connecté expose simultanément des interfaces physiques (ports UART, JTAG, SPI), des protocoles radio (Wi-Fi, BLE, Zigbee, LoRa), des services réseau (telnet, SSH, HTTP, MQTT), une application mobile compagnon et une infrastructure cloud backend. Chaque couche présente ses propres vulnérabilités et nécessite des outils spécifiques pour l'évaluation.

La reconnaissance physique du dispositif débute par l'ouverture du boîtier et l'identification des composants sur le PCB. Le processeur principal (souvent un SoC ARM comme les ESP32 d'Espressif ou les nRF52 de Nordic Semiconductor) détermine l'architecture cible pour le reverse engineering. Les puces mémoire flash (SPI NOR, eMMC) contiennent le firmware extractible via des outils comme un lecteur SPI ou un programmateur CH341A. Les ports de débogage UART et JTAG, fréquemment laissés accessibles sur le PCB de production, offrent un accès direct au système d'exploitation embarqué. L'article sur le hardware hacking JTAG/SWD/UART détaille les techniques d'identification et d'exploitation de ces interfaces physiques qui constituent souvent le chemin le plus court vers un accès root complet au dispositif audité.

Phase 1 : Extraction et analyse du firmware

L'extraction du firmware constitue la phase la plus productive du pentest IoT. Une fois le binaire récupéré — par dump SPI flash, interception de mise à jour OTA ou téléchargement depuis le portail constructeur — l'analyse statique révèle la majorité des vulnérabilités exploitables. Binwalk identifie les systèmes de fichiers embarqués (SquashFS, JFFS2, CramFS), extrait les arborescences et expose les fichiers de configuration contenant fréquemment des credentials hardcodés.

L'outil EMBA (Embedded Analyzer) automatise l'analyse de sécurité du firmware extrait en combinant détection de binaires vulnérables (BusyBox, OpenSSL obsolètes), recherche de credentials hardcodés, identification de services réseau compilés statiquement et analyse des scripts de démarrage. Firmwalker complète cette analyse en ciblant spécifiquement les fichiers sensibles : clés privées SSL/TLS, certificats, fichiers shadow, configurations Wi-Fi avec PSK en clair et tokens API. L'article sur le reverse engineering de firmware IoT approfondit les techniques d'analyse statique et dynamique avec Ghidra et radare2 pour les binaires ARM dépourvus de symboles de débogage, situation courante sur les firmwares de production optimisés et strippés par le constructeur.

L'émulation du firmware avec QEMU permet de tester dynamiquement les services réseau sans disposer du hardware physique. Le framework FirmAE automatise l'émulation de firmwares Linux embarqués en reconstituant l'environnement d'exécution (NVRAM, interfaces réseau virtuelles) pour rendre les services accessibles depuis la machine de l'auditeur. Cette technique accélère considérablement la phase de test des services web embarqués et des API REST exposées par le dispositif.

Phase 2 : Audit des protocoles réseau IoT

Les protocoles de communication IoT présentent des vulnérabilités spécifiques absentes des environnements IT traditionnels. MQTT, protocole dominant de l'IoT, fonctionne sur un modèle publish/subscribe où un broker central distribue les messages entre les dispositifs. L'absence d'authentification sur le broker (configuration par défaut de Mosquitto) permet à tout client de s'abonner au topic wildcard (#) et de recevoir l'intégralité des messages échangés entre les dispositifs. L'article dédié à la sécurité MQTT et CoAP détaille les scénarios d'attaque et les configurations de durcissement pour ces protocoles omniprésents dans les déploiements IoT industriels et résidentiels.

Le sniffing des communications radio (BLE, Zigbee, Z-Wave) nécessite des équipements spécifiques. Un dongle Ubertooth One capture le trafic Bluetooth Low Energy, tandis qu'un dongle CC2531 flashé avec le firmware Zigbee sniffer de Texas Instruments intercepte les communications Zigbee. L'analyse des trames capturées avec Wireshark et ses dissecteurs spécialisés révèle les données transmises en clair, les faiblesses du protocole d'appairage et les possibilités de rejeu de commandes. Les attaques wireless BLE et Zigbee exploitent ces faiblesses protocolaires pour intercepter, modifier ou injecter des commandes dans les réseaux de capteurs et d'actionneurs connectés déployés en environnement industriel et domotique.

Phase 3 : Pentest de l'API cloud et du backend

L'infrastructure cloud backend d'un dispositif IoT concentre souvent les vulnérabilités les plus critiques en termes d'impact. Les API REST qui reçoivent les données des capteurs et permettent le contrôle à distance présentent fréquemment des failles de type IDOR (Insecure Direct Object Reference) permettant d'accéder aux données d'autres utilisateurs, des endpoints d'administration non protégés et des mécanismes d'authentification faibles. L'approche de test suit la méthodologie OWASP Top 10 web classique enrichie des spécificités IoT : provisionnement de masse des dispositifs, gestion des certificats client et mécanismes de mise à jour OTA.

Le fuzzing des API IoT avec des outils comme Burp Suite ou Nuclei cible les endpoints spécifiques à l'IoT : enregistrement de nouveaux dispositifs (possibilité de cloner un dispositif légitime), envoi de commandes de contrôle (modification des paramètres d'un dispositif tiers), téléchargement de firmware (accès aux binaires sans authentification) et gestion de flotte (élévation de privilèges pour administrer des dispositifs hors scope). La corrélation entre les données extraites du firmware (URLs d'API, tokens hardcodés, certificats) et les vulnérabilités découvertes sur le backend cloud permet de construire des chaînes d'exploitation complètes allant de la compromission d'un seul dispositif à la prise de contrôle de l'ensemble de la flotte déployée en production.

Phase 4 : Audit de l'application mobile compagnon

L'application mobile compagnon constitue le maillon faible de nombreux écosystèmes IoT. L'analyse statique de l'APK Android avec jadx ou de l'IPA iOS avec class-dump révèle les secrets embarqués dans le code : clés API, URLs de staging, credentials de test et certificats. Le stockage local de l'application (SharedPreferences Android, Keychain iOS) contient fréquemment des tokens d'authentification, des identifiants de dispositifs et des données personnelles en clair ou avec un chiffrement réversible. La communication entre l'application et le dispositif via BLE ou Wi-Fi Direct expose des protocoles propriétaires souvent dépourvus de chiffrement et vulnérables au rejeu de commandes après capture du trafic avec un proxy BLE comme GATTacker ou un proxy HTTP comme mitmproxy.

Le test de l'appairage initial entre l'application mobile et le dispositif IoT est critique. De nombreux dispositifs utilisent un mécanisme d'appairage BLE Just Works sans confirmation utilisateur, permettant à un attaquant à portée radio de s'apparier avec le dispositif avant le propriétaire légitime. D'autres implémentent un code PIN statique identique pour tous les dispositifs du même modèle, rendant le mécanisme de protection totalement inefficace. L'audit de la sécurité mobile offensive complète ces tests avec l'analyse des mécanismes anti-tampering, de la protection du code source et de la conformité aux guides OWASP Mobile Security.

Outils essentiels du pentester IoT en 2026

La boîte à outils du pentester IoT combine équipements hardware et logiciels spécialisés. Côté hardware, l'investissement minimal inclut un analyseur logique Saleae pour identifier les protocoles sur les bus de communication, un programmateur CH341A ou Bus Pirate pour le dump SPI/I2C, un adaptateur UART-USB (FTDI) pour l'accès aux consoles série, et un Ubertooth One pour le sniffing BLE. Côté logiciel, la distribution AttifyOS regroupe les outils essentiels : Binwalk, Firmwalker, EMBA pour l'analyse firmware, Wireshark avec dissecteurs IoT, et les frameworks d'émulation QEMU/FirmAE.

Les frameworks d'automatisation accélèrent significativement les phases de reconnaissance et de découverte de vulnérabilités. RouterSploit fournit des modules d'exploitation ciblant spécifiquement les routeurs, caméras IP et autres dispositifs réseau embarqués. HomePwn cible les dispositifs domotiques (assistants vocaux, ampoules connectées, prises intelligentes). IoTSecFuzz automatise le fuzzing des protocoles IoT (MQTT, CoAP, AMQP) avec génération de cas de test mutants ciblant les parseurs de messages souvent implémentés sans validation stricte des entrées dans les firmwares embarqués aux ressources limitées.

Rédiger un rapport de pentest IoT exploitable

Le rapport de pentest IoT doit s'adapter à un public plus large que le rapport de pentest web classique. Les vulnérabilités hardware (port JTAG accessible, firmware non signé) nécessitent une explication du risque compréhensible par les équipes produit qui ne maîtrisent pas les concepts de sécurité offensive. Chaque vulnérabilité doit inclure une démonstration d'exploitation reproductible, une évaluation de l'impact sur l'ensemble de la flotte déployée (pas seulement le dispositif testé) et une recommandation de remédiation priorisée selon la faisabilité technique. Les vulnérabilités firmware nécessitant une mise à jour OTA ont un délai de correction bien plus long qu'un correctif backend, ce qui impacte la priorisation et le plan de remédiation proposé au client.

La classification des vulnérabilités IoT suit une matrice spécifique : les vulnérabilités exploitables à distance via Internet (API cloud, firmware OTA) sont systématiquement classées critiques ; les vulnérabilités nécessitant un accès réseau local (MQTT sans auth, BLE sans appairage sécurisé) sont classées élevées ; les vulnérabilités nécessitant un accès physique au dispositif (JTAG, dump SPI) sont classées moyennes sauf si le dispositif est déployé dans un environnement physiquement accessible au public. Cette classification pragmatique permet aux équipes de développement embarqué de prioriser efficacement la remédiation dans les contraintes de ressources et de calendrier des cycles de développement produit IoT.

Conclusion

Le pentest IoT requiert une méthodologie structurée couvrant les cinq couches de la surface d'attaque : hardware, firmware, réseau, cloud et mobile. L'alignement sur l'OWASP IoT Top 10 garantit une couverture exhaustive des vulnérabilités les plus fréquentes, tandis que les outils spécialisés comme EMBA, FirmAE et RouterSploit accélèrent la découverte et l'exploitation. L'investissement dans les compétences et l'équipement de pentest IoT est rentabilisé dès le premier audit par la criticité des vulnérabilités découvertes.