Surface d'attaque IoT¶

Un système IoT expose des dizaines de vecteurs d'attaque hétérogènes — comprendre la surface complète est le préalable indispensable à toute défense efficace.

Les six familles de vecteurs¶

1. Attaques physiques¶

L'accès physique à un device IoT — même quelques minutes — peut compromettre l'ensemble du système. Les attaquants disposent d'une boîte à outils spécialisée :

Dump flash. La mémoire flash non protégée se lit directement avec un programmateur SOIC-8 (Bus Pirate, FT232H). En quelques minutes, l'attaquant obtient le firmware complet, les clés en clair éventuelles, les certificats.

Débogage JTAG/SWD. Les interfaces de débogage laissées actives en production permettent l'accès complet à la mémoire, l'arrêt du processeur, la modification du code à chaud. Le standard JTAG (IEEE 1149.1) est présent sur la quasi-totalité des MCU ARM.

Glitching. Les attaques par injection de faute (voltage glitching, clock glitching, EM injection) peuvent contourner les vérifications de signature en forçant des sauts d'instructions au bon moment. Des outils comme le ChipWhisperer permettent ces attaques à moins de 300 €.

Side-channel. L'analyse de consommation (SPA/DPA) ou d'émissions électromagnétiques (EMA) permet d'extraire des clés cryptographiques si l'implémentation n'est pas protégée.

2. Attaques réseau¶

Sniffing radio. Les communications sans fil non chiffrées (Zigbee sans AES, LoRa en clair, BLE advertising) s'écoutent avec un simple récepteur SDR (RTL-SDR à 20 €, HackRF, YARD Stick One). Les trames capturées révèlent les protocoles, les identifiants, parfois les commandes de contrôle.

Replay. Sans numéro de séquence ou nonce, un message capturé peut être rejoué pour déclencher une action : ouverture de porte, activation d'actionneur, fausse lecture de capteur.

Man-in-the-Middle (MitM). Sans validation de certificat côté device, un attaquant peut intercepter et modifier le trafic entre le device et le broker MQTT ou le cloud.

Déni de service (DoS) radio. Le brouillage ciblé d'une fréquence (868 MHz, 2,4 GHz) neutralise des zones entières de déploiement.

3. Attaques firmware¶

Rétro-ingénierie (RE). Un firmware extrait se décompile avec Ghidra (NSA), IDA Pro, ou Binary Ninja. Les fonctions crypto, les hardcoded credentials et les URLs backend deviennent lisibles.

Injection de code. Les mises à jour OTA non sécurisées (pas de vérification de signature, transport HTTP) permettent de pousser un firmware malveillant sur l'ensemble du parc.

Vulnérabilités mémoire. Les firmwares C/C++ sans protection (stack canaries, ASLR, NX bit) sont vulnérables aux buffer overflows classiques si l'interface réseau est exposée.

4. Attaques cloud et API¶

Credentials en clair. Les clés API, tokens MQTT, mots de passe codés en dur dans le firmware ou dans les fichiers de configuration sont la première cible lors d'un audit.

API non authentifiées. Les endpoints de gestion (shadow IoT, OTA backend, device registry) sans authentification forte exposent l'ensemble du parc à une prise de contrôle massive.

Privilege escalation. Un device compromis peut tenter d'accéder aux données d'autres devices dans un tenant mal isolé (confused deputy attack).

5. Attaques supply chain¶

Composants contrefaits. Des circuits intégrés contrefaits ou modifiés à la fabrication (hardware trojans) peuvent contenir des backdoors indétectables.

Firmware de développement en production. Des firmwares livrés avec des interfaces de debug actives, des clés de test, ou des fonctionnalités désactivables par flag.

Dépendances logicielles. Les bibliothèques open source embarquées (mbed TLS, LwIP, FreeRTOS) peuvent contenir des CVE non patchées si aucun processus de suivi des vulnérabilités n'existe.

6. Ingénierie sociale et insider¶

Les opérateurs ayant accès aux systèmes de configuration et de mise à jour représentent un vecteur souvent négligé dans les analyses de risque IoT industriel.

Kill chain IoT¶

La kill chain IoT adapte le modèle Lockheed Martin à la réalité des systèmes embarqués. Un attaquant sophistiqué progresse méthodiquement :

flowchart TD
    A["1. Reconnaissance\nCartographie du parc\nIdentification des modèles\nRecherce CVE publiques"] --> B["2. Accès initial\nDump flash physique\nSniffing radio\nFirmware OTA non signé"]
    B --> C["3. Persistance\nModification firmware\nBackdoor bootloader\nCertificat rouge ajouté"]
    C --> D["4. Élévation de privilèges\nJTAG débogage\nGlitching secure boot\nExploitation buffer overflow"]
    D --> E["5. Mouvement latéral\nPivot vers réseau OT\nAccès broker MQTT\nDisposition device fleet"]
    E --> F["6. Impact\nSabotage process industriel\nVol de données\nRançongiciel OT\nDéni de service physique"]

    style A fill:#fff3e0
    style B fill:#ffccbc
    style C fill:#ef9a9a
    style D fill:#e57373
    style E fill:#d32f2f,color:#fff
    style F fill:#b71c1c,color:#fff

Surface d'attaque par couche¶

graph TB
    subgraph PHY["Couche physique"]
        P1["Flash non protégée"]
        P2["JTAG/SWD actif"]
        P3["Glitching / side-channel"]
        P4["Debug UART en clair"]
    end

    subgraph FW["Firmware"]
        F1["Credentials codés en dur"]
        F2["Pas de vérification OTA"]
        F3["CVE bibliothèques embarquées"]
        F4["Stack overflow réseau"]
    end

    subgraph NET["Réseau"]
        N1["Radio non chiffrée"]
        N2["Replay d'ordres"]
        N3["MitM / pas de cert pinning"]
        N4["Brouillage DoS"]
    end

    subgraph CLOUD["Cloud / backend"]
        C1["API sans auth forte"]
        C2["Tokens en dur firmware"]
        C3["OTA backend non signé"]
        C4["Multi-tenant mal isolé"]
    end

    subgraph SUPPLY["Supply chain"]
        S1["Hardware trojans"]
        S2["Firmware de dev en prod"]
        S3["Dépendances CVE non patchées"]
    end

    PHY --> FW
    FW --> NET
    NET --> CLOUD
    SUPPLY -.->|"contamine"| PHY
    SUPPLY -.->|"contamine"| FW

Évaluation rapide des risques par vecteur¶

Modèle de menace STRIDE appliqué à l'IoT¶

Le modèle STRIDE (Microsoft) s'applique naturellement aux systèmes IoT :

Ce qu'il faut retenir¶

• La surface d'attaque IoT est multidimensionnelle : physique, firmware, réseau, cloud et supply chain sont tous des vecteurs réels.
• Les attaques les plus courantes en production sont les plus simples : credentials en dur, JTAG actif, OTA sans signature.
• La kill chain IoT est progressive — chaque étape non sécurisée augmente le rayon d'explosion d'une compromission initiale.
• Modéliser les menaces (STRIDE, PASTA) avant de concevoir, pas après.

Chapitre suivant : Secure Boot & Root of Trust — comment ancrer la confiance dans le silicium pour résister aux attaques physiques et firmware.