La surface d'attaque d'un système IoT

Jour 1 · Attaquer pour comprendre · 25 min

Un système IoT présente plus de surfaces qu'une application classique, parce qu'il déborde du réseau : il a un corps physique, une radio, et il se met à jour tout seul.

L'OWASP IoT Top 10, appliqué à Thermeo

L'OWASP publie une liste des dix faiblesses les plus répandues. Confrontons-la à ce que vous avez construit — l'exercice est instructif.

Ce que l'IoT a de particulier

• L'objet est physiquement accessible. Un capteur sur un toit peut être emporté, ouvert, son firmware extrait et lu. Tout secret qu'il contient est un secret public.
• Le parc est nombreux et durable. Cent objets déployés pour dix ans : une faille découverte en 2029 devra être corrigée sur du matériel installé en 2026.
• La mise à jour est une arme. Le mécanisme qui vous permet de corriger une faille permet aussi, s'il est mal protégé, d'installer n'importe quoi sur tout le parc.

Quiz — Surface d'attaque

Jour 1 · Attaquer pour comprendre · 7 min

TP 1 — Auditer sa propre maquette

Jour 1 · Attaquer pour comprendre · 1 h 15

Passer votre installation au crible des dix faiblesses OWASP, avec des preuves.

1. Inventoriez ce qui écoute sur votre poste. Toute écoute non justifiée est un constat :
   copier

   docker ps --format 'table {{{{.Names}}}}\t{{{{.Ports}}}}'
   lsof -iTCP -sTCP:LISTEN -P -n | grep -E '1883|8883|8086|3000|1880|8000'

2. Pour chaque port, répondez par écrit : qui doit y accéder, et qu'est-ce qui l'en empêche aujourd'hui ?
3. Vérifiez les réglages par défaut. Grafana, InfluxDB, Node-RED sont-ils protégés ?
   copier

   curl -s -o /dev/null -w 'grafana  %{{http_code}}\n' http://localhost:3000/api/health
   curl -s -o /dev/null -w 'influx   %{{http_code}}\n' http://localhost:8086/api/v2/buckets
   curl -s -o /dev/null -w 'nodered  %{{http_code}}\n' http://localhost:1880/flows

4. Node-RED répond très probablement sans authentification, et il peut publier sur votre broker. Mesurez ce que cela permet à quelqu'un sur le même réseau.
5. Testez votre API de M4 : est-elle authentifiée ?
   copier

   curl -s http://localhost:8000/api/etat | head -c 200

6. Cherchez les secrets qui traînent dans votre dépôt — la faiblesse la plus répandue :
   copier

   git log --all -p | grep -iE 'token|password|BEGIN (RSA|PRIVATE)' | head -20
   git ls-files | xargs grep -lIE 'token|passwd|\.key$' 2>/dev/null

7. Examinez la question de la vie privée : à partir de vos relevés de température de bureau, que peut-on déduire ? Écrivez la réponse — horaires d'occupation, absences, week-ends. C'est le constat que les équipes oublient systématiquement.
8. Vérifiez l'âge de vos images :
   copier

   docker images --format '{{{{.Repository}}}}:{{{{.Tag}}}}\t{{{{.CreatedSince}}}}'

9. Produisez un tableau d'audit : une ligne par faiblesse OWASP, avec constat, preuve, gravité et correction proposée. C'est le premier livrable du module.

Écouter, rejouer, injecter

Jour 1 · Attaquer pour comprendre · 20 min

Trois attaques suffisent à comprendre pourquoi le chiffrement seul ne protège pas.

L'écoute

Sans TLS, tout transite en clair : valeurs, identifiants, topics. Vous l'avez déjà constaté au TP 3 de M1 avec Wireshark. C'est l'attaque la plus simple, et la parade est connue.

Le rejeu

Plus subtile, parce qu'elle survit au chiffrement dans certains montages. Le principe : capturer un message légitime et le réémettre plus tard.

Trois parades, à combiner :

• Horodatage dans la charge utile, et rejet de tout message trop ancien. Impose des horloges synchronisées.
• Compteur croissant par capteur : un numéro déjà vu est refusé.
• Signature du message incluant l'horodatage, pour qu'on ne puisse pas le modifier.

L'injection

Publier de fausses valeurs sur un topic légitime. C'est le scénario évoqué en M1 : une température falsifiée qui trompe la régulation.

La parade est celle que vous avez déjà en place — les ACL par certificat. Encore faut-il qu'elles soient strictes : un capteur qui a le droit d'écrire sur thermeo/# peut usurper tous les autres.

TP 2 — Rejouer contre soi-même

Jour 1 · Attaquer pour comprendre · 1 h 15

Monter une attaque par rejeu sur votre maquette, puis la rendre inopérante.

1. Placez-vous dans la peau d'un attaquant qui a obtenu un identifiant. Capturez un message légitime :
   copier

   mosquitto_sub -h localhost -p 8883 --cafile certs/ca.crt \
     --cert certs/capt-01.crt --key certs/capt-01.key \
     -t 'thermeo/lyon/etage1/capt-01/temperature' -C 1 -v

2. Rejouez-le une heure plus tard, tel quel :
   copier

   mosquitto_pub -h localhost -p 8883 --cafile certs/ca.crt \
     --cert certs/capt-01.crt --key certs/capt-01.key \
     -t 'thermeo/lyon/etage1/capt-01/temperature' -m '21.4'

3. Regardez Grafana : la valeur rejouée est indiscernable d'une mesure réelle. Le système est chiffré, authentifié, et pourtant trompé.
4. Ajoutez maintenant les défenses. Enrichissez la charge utile du capteur avec un horodatage et un compteur :
   copier

   import time, json
   
   compteur = 0
   
   def charge(valeur):
       global compteur
       compteur += 1
       return json.dumps({
           "valeur": valeur,
           "ts": int(time.time()),
           "n": compteur,
       })

5. Écrivez côté réception un contrôle qui rejette les messages suspects :
   copier

   import time
   
   FENETRE = 60          # secondes de tolerance
   vus = {}              # capteur -> dernier compteur accepte
   
   def accepter(capteur, msg):
       if abs(time.time() - msg["ts"]) > FENETRE:
           return False, "horodatage hors fenetre"
       if msg["n"] <= vus.get(capteur, 0):
           return False, "compteur deja vu"
       vus[capteur] = msg["n"]
       return True, "ok"

6. Rejouez le message capturé : il doit être rejeté deux fois — par l'horodatage et par le compteur. Consignez les deux refus.
7. Éprouvez la limite : rejouez immédiatement, dans la fenêtre de 60 secondes. Seul le compteur vous sauve. Que se passe-t-il si le capteur redémarre et repart à zéro ? Traitez ce cas — il est réel, un capteur en deep sleep redémarre à chaque réveil.
8. Ajoutez un contrôle de plausibilité : rejeter toute valeur hors de −30 à +60 °C, ou s'écartant de plus de 10 °C de la précédente. Testez avec une injection aberrante.

Point de contrôle — fin du jour 1

Jour 1 · Attaquer pour comprendre · 15 min

Mettre à jour sans se tirer dessus

Jour 2 · Durcir et déployer · 25 min

Cent capteurs sur des toits. Une faille est publiée. Vous devez corriger — et le mécanisme qui vous le permet est précisément celui qui peut détruire le parc.

Les trois exigences

1. La signature

L'objet doit vérifier que la mise à jour vient de vous. Le principe est celui des certificats de M1, appliqué à un fichier : vous signez le firmware avec une clé privée, l'objet vérifie avec la clé publique qu'il embarque.

2. La double partition

On n'écrase jamais la version qui fonctionne. La nouvelle s'écrit dans la partition libre, et la bascule n'a lieu qu'une fois l'écriture vérifiée. Une coupure en cours de transfert laisse l'ancienne version intacte.

3. Le retour arrière

La nouvelle version doit confirmer son bon démarrage — se connecter au broker, publier une fois. Sans confirmation dans un délai donné, l'objet repart sur l'ancienne partition.

Le déploiement par vagues

Même signé, même avec retour arrière, on ne déploie jamais sur cent objets d'un coup.

Ce que le simulateur ne fera pas

TP 3 — Signer et vérifier un firmware

Jour 2 · Durcir et déployer · 1 h

Implémenter la chaîne de confiance d'une mise à jour, de la signature au refus.

1. Générez la paire de clés de signature. Elle est distincte de l'autorité TLS de M1 : signer du code et authentifier un service sont deux usages différents.
   copier

   openssl genrsa -out certs/firmware-signature.key 2048
   openssl rsa -in certs/firmware-signature.key -pubout \
     -out certs/firmware-signature.pub

2. Fabriquez un firmware factice et signez-le :
   copier

   echo 'FIRMWARE v2 — corrige la faille du parseur' > firmware-v2.bin
   
   openssl dgst -sha256 -sign certs/firmware-signature.key \
     -out firmware-v2.sig firmware-v2.bin

3. Écrivez le vérificateur — c'est ce que ferait l'objet avant d'installer :
   copier

   openssl dgst -sha256 -verify certs/firmware-signature.pub \
     -signature firmware-v2.sig firmware-v2.bin

4. La commande répond Verified OK. Maintenant, attaquez : modifiez un octet du firmware et relancez la vérification.
5. Le contrôle échoue. C'est exactement ce qui doit se produire :
   copier

   echo 'code malveillant' >> firmware-v2.bin
   openssl dgst -sha256 -verify certs/firmware-signature.pub \
     -signature firmware-v2.sig firmware-v2.bin
   # Verification Failure

6. Écrivez maintenant un script maj.py qui reproduit la logique complète d'un objet recevant une mise à jour :
   copier

   # 1. telecharger firmware + signature
   # 2. verifier la signature -> si echec, ABANDON, on ne touche a rien
   # 3. verifier que la version est superieure a l'actuelle
   # 4. ecrire dans la partition inactive
   # 5. marquer 'a essayer' et redemarrer
   # 6. au demarrage : si pas de confirmation en 60 s -> retour arriere
   #
   # Simulez les partitions par deux fichiers et l'etat par un troisieme.

7. Éprouvez les quatre scénarios et consignez le comportement de chacun : signature valide, signature invalide, version inférieure ou égale, et démarrage sans confirmation.
8. Le cas de la version inférieure est le plus souvent oublié : sans lui, un attaquant réinstalle une ancienne version signée — qui contenait la faille que vous venez de corriger. C'est une attaque par retour en arrière.

L'industriel n'est pas l'informatique

Jour 2 · Durcir et déployer · 20 min

Thermeo intervient dans des bâtiments tertiaires. Le jour où le client est une usine, les règles changent — et l'erreur classique est d'y appliquer les réflexes de l'informatique de gestion.

Deux mondes, deux priorités

Les protocoles que vous rencontrerez

La segmentation, principe central de l'OT

Puisqu'on ne peut pas sécuriser les équipements eux-mêmes — trop anciens, trop critiques pour être touchés — on sécurise ce qui les entoure. Le modèle de référence empile des niveaux, du terrain à la bureautique, avec une zone démilitarisée entre l'industriel et l'informatique de gestion.

Votre passerelle IoT se place précisément là : elle lit les équipements industriels et n'expose que ce qui doit sortir. Elle ne doit jamais permettre d'écrire dans le sens inverse sans contrôle explicite.

Quiz — Mise à jour et industriel

Jour 2 · Durcir et déployer · 7 min

TP 4 — Le plan de durcissement

Jour 2 · Durcir et déployer · 1 h 30

Corriger ce que l'audit a révélé et produire le dossier de sécurité du système.

1. Reprenez votre tableau d'audit du TP 1 et classez les constats par gravité, en croisant impact et facilité d'exploitation.
2. Corrigez les trois plus graves. Typiquement : authentifier Node-RED, protéger l'API de M4, retirer les secrets du dépôt.
3. Pour l'API, ajoutez une authentification par en-tête :
   copier

   from fastapi import Header, HTTPException
   import os, secrets
   
   def verifier(x_api_key: str = Header(None)):
       attendu = os.environ["API_KEY"]
       if not x_api_key or not secrets.compare_digest(x_api_key, attendu):
           raise HTTPException(401, "cle invalide")
   
   @app.get("/api/etat", dependencies=[Depends(verifier)])
   def etat():
       ...

4. Notez l'usage de compare_digest plutôt que == : la comparaison à temps constant évite de révéler la clé caractère par caractère. Expliquez pourquoi dans votre rendu.
5. Si des secrets sont dans votre historique Git, le retrait du fichier ne suffit pas — ils restent dans les commits antérieurs. Documentez la procédure :
   copier

   # le fichier retire reste dans l'historique :
   git log --all --full-history -- certs/ca.key
   
   # la reecriture d'historique est necessaire, et les secrets exposes
   # doivent de toute facon etre consideres comme compromis et regeneres

6. Ajoutez le contrôle de plausibilité du TP 2 dans votre chaîne d'ingestion, en production.
7. Rédigez le dossier de sécurité du système, en quatre parties : la surface d'attaque et les mesures en place ; le tableau d'audit avec ce qui est corrigé et ce qui est accepté ; la procédure de mise à jour, signature comprise ; et la conduite à tenir en cas de compromission d'un capteur.
8. Rédigez enfin une note d'une page sur le passage en environnement industriel : ce qui changerait dans votre architecture si Thermeo équipait une usine plutôt qu'un immeuble de bureaux.

Point de contrôle — fin du module M5

Jour 2 · Durcir et déployer · 20 min