Audit & réponse à incident IoT¶

Tester la sécurité d'un système IoT avant qu'un attaquant ne le fasse — et savoir réagir efficacement quand la compromission survient malgré tout.

La démarche d'audit IoT¶

Un audit de sécurité IoT est fondamentalement différent d'un test d'intrusion web classique. Il combine des compétences en électronique (analyse matérielle), en systèmes embarqués (firmware, protocoles bas niveau), en réseau (sniffing radio, protocoles industriels), et en cloud (APIs, backend IoT).

L'objectif d'un audit défensif est d'identifier les vulnérabilités avant un attaquant réel, de les documenter, et d'établir un plan de remédiation priorisé par risque.

Outillage du pentesteur IoT¶

Analyse matérielle et firmware¶

Analyse réseau et radio¶

Environnements et frameworks¶

Méthodologie d'audit IoT¶

Phase 1 : Reconnaissance passive¶

Avant tout accès au device :

• Collecte OSINT : notices, datasheets publics, CVE liées aux composants identifiés
• Analyse des applications mobiles associées (décompilation APK, extraction API endpoints)
• Recherche firmware sur le site fabricant ou via Google (site:manufacturer.com firmware)
• Scan SHODAN/Censys pour identifier les instances du même device exposées sur Internet

Phase 2 : Analyse matérielle¶

flowchart LR
    DISS["Dissection\ndu device"]
    PCB["Analyse PCB\nIdentification SoC, flash\nUART, JTAG pads"]
    CONS["Test connectivité\nMultimètre, oscilloscope\nIdentification UART (bauds)"]
    DUMP["Dump flash\nSoIC clip ou soudure\nFT232H + Flashrom"]
    JTAG["Test JTAG\nOpenOCD + GDB\nSi non locké"]

    DISS --> PCB
    PCB --> CONS
    CONS --> DUMP
    CONS --> JTAG

Identification des interfaces UART :

1. Mesurer la tension de chaque pin inconnu (VCC, GND, TX, RX, ou DTR/RTS)
2. TX émet des données au démarrage — oscilloscope ou analyseur logique
3. Calculer le baud rate depuis la largeur du bit le plus court
4. Typiques : 115200, 57600, 9600 bauds

Phase 3 : Analyse firmware¶

flowchart TD
    BIN["firmware.bin\n(extrait ou téléchargé)"]
    BINWALK["Binwalk\nIdentification sections\nExtraction FS"]
    STRINGS["Strings / Firmwalker\nCredentials, URLs, clés\nConfiguration hardcodée"]
    GHIDRA["Ghidra / IDA\nRétro-ingénierie binaire\nFonctions crypto, réseau"]
    CVE["Analyse dépendances\nBusyBox version, OpenSSL\nCVE lookup"]
    EMBA["EMBA / FACT\nAnalyse automatisée\nRapport vulnérabilités"]

    BIN --> BINWALK
    BINWALK --> STRINGS
    BINWALK --> GHIDRA
    BINWALK --> CVE
    BIN --> EMBA

Phase 4 : Tests dynamiques¶

• Tests d'authentification : credentials par défaut, brute force, bypass
• Fuzzing des interfaces réseau exposées (MQTT, HTTP, CoAP)
• Tests OTA : replay de manifests, intégrité de signature
• Tests de cloisonnement réseau : escape de VLAN, pivot

Checklist d'audit IoT¶

Sécurité physique et matérielle¶

Secure boot et firmware¶

Réseau et communications¶

Gestion des identités¶

Conformité et processus¶

Forensics embarqué¶

Lorsqu'un device est suspecté d'être compromis, l'investigation forensique embarquée suit une méthodologie spécifique.

Préservation des preuves¶

L'ordre de volatilité en embarqué (du plus volatile au moins volatile) :

1. Registres CPU et RAM (perdus à l'extinction)
2. Mémoire cache
3. Processus en cours d'exécution, connexions réseau
4. Système de fichiers en RAM (tmpfs)
5. Flash interne (persistante)
6. EEPROM externe
7. Logs cloud (si synchronisés)

Règle fondamentale : ne jamais éteindre le device suspecté avant d'avoir capturé la RAM si possible.

Dump mémoire live via JTAG¶

Si le device est accessible physiquement et que JTAG n'est pas verrouillé (ou en cours d'audit autorisé) :

# OpenOCD + GDB — dump RAM complète
openocd -f interface/jlink.cfg -f target/stm32f4x.cfg

# Dans GDB :
(gdb) target remote localhost:3333
(gdb) dump binary memory ram_dump.bin 0x20000000 0x20020000
(gdb) dump binary memory flash_dump.bin 0x08000000 0x08100000

Analyse post-mortem du dump flash¶

# Analyse structure firmware
binwalk -e firmware_dump.bin

# Recherche de credentials et artefacts suspects
firmwalker ./firmware_dump/

# Analyse strings sensibles
strings firmware_dump.bin | grep -E "(password|key|token|secret|BEGIN CERTIFICATE)"

# Comparaison avec firmware officiel (détection de modification)
sha256sum firmware_officiel.bin firmware_dump.bin
diff <(strings firmware_officiel.bin) <(strings firmware_dump.bin)

Plan de réponse à incident IoT¶

Les 6 phases (NIST SP 800-61 adapté IoT)¶

flowchart LR
    P1["1. Préparation\nProcédures documentées\nOutillage prêt\nContacts d'urgence"]
    P2["2. Détection\nAnomalie réseau\nAlerte SOC\nSignalement terrain"]
    P3["3. Confinement\nIsoler device du réseau\nRévoquer certificat\nBlocker broker MQTT"]
    P4["4. Éradication\nAnalyse forensique\nIdentifier la cause\nNettoyer / rebuilder"]
    P5["5. Récupération\nRe-provisionner\nTest de sécurité\nSurveillance renforcée"]
    P6["6. Retour d'expérience\nPost-mortem\nMise à jour procédures\nCommunication"]

    P1 --> P2 --> P3 --> P4 --> P5 --> P6
    P6 -.->|"amélioration continue"| P1

Actions de confinement immédiates¶

Matrice de décision : isolation vs continuité¶

Disclosure responsable (Responsible Disclosure)¶

Quand vous découvrez une vulnérabilité dans un produit IoT, la disclosure responsable (Coordinated Vulnerability Disclosure — CVD) est la démarche éthique et légalement recommandée.

Processus CVD¶

1. Documenter la vulnérabilité : preuve de concept, versions affectées, impact estimé
2. Identifier le contact sécurité du fabricant (security@, CERT, page Bugbounty, RFC 9116 .well-known/security.txt)
3. Notifier en privé avec un délai de correction raisonnable (90 jours, norme Google Project Zero)
4. Suivre la correction et maintenir la communication avec le fabricant
5. Publication coordonnée après correction ou à l'échéance du délai
6. Attribution CVE via MITRE si vulnérabilité significative

Ressources de notification¶

Ce qu'il faut retenir¶

• Un audit IoT combine électronique, firmware, réseau et cloud — il nécessite une équipe aux compétences transverses.
• La checklist d'audit est un outil vivant : l'adapter au contexte (SL cible IEC 62443, provisions ETSI 303 645 applicables).
• En cas d'incident, le confinement (révocation certificat + blocage broker) doit intervenir en moins de 15 minutes.
• La forensique embarquée commence par préserver la volatilité — ne pas éteindre avant d'avoir capturé la RAM.
• La disclosure responsable protège les utilisateurs finaux tout en permettant au fabricant de corriger dans un délai raisonnable.

Retour : Systèmes Embarqués & IoT — retour à l'index du tutoriel.