Des articles approfondis sur les technologies qui façonnent l'avenir.

Quand des pirates dégivrent votre supermarché : leçons OT

Des pirates ont dégivré des frigos de supermarchés en Europe. Pourquoi l'OT échoue et comment sécuriser les systèmes industriels.

Allée vide de congélateurs de supermarché la nuit, avec du givre qui fond et un voyant d'alarme rouge sur un panneau de commande.
Quand une commande de dégivrage arrive à 3 heures du matin, personne n'est là pour la remarquer avant que les dégâts ne soient faits.

Imaginez que vous êtes responsable de l'équipe de nuit d'un supermarché à Lyon. À 3 heures du matin, l'équipe remarque du givre qui fond sur les vitrines de surgelés. Puis les alarmes des compresseurs se déclenchent, non pas sur une allée, mais dans tout le magasin. Au moment où quelqu'un comprend ce qui se passe, les chambres froides ont été commandées à distance en mode dégivrage, et des milliers d'euros de stock surgelé se réchauffent discrètement vers le seuil légal de destruction. C'est à peu près ce qui s'est produit lorsque des attaquants ont visé les contrôleurs de réfrigération de chaînes de supermarchés françaises cette année, et c'est un bon rappel pour quiconque pense que la sécurité des technologies opérationnelles est le problème de quelqu'un d'autre.

L'attaque n'avait rien d'un exploit à la Hollywood. Selon les rapports, les attaquants ont déclenché des cycles de dégivrage automatiques sur des contrôleurs de réfrigération accessibles depuis Internet — des unités commerciales d'un grand fabricant industriel — et les dégâts se sont propagés à des magasins dans plusieurs pays. À peu près à la même période, un incident distinct a obligé un groupe de distribution belgo-néerlandais à mettre hors ligne une partie de son informatique, perturbant la distribution et les livraisons. Coïncidence ou coordination, le résultat est le même : le monde physique a été piraté à travers le monde numérique.

Pourquoi un congélateur est-il connecté à Internet, de toute façon ?

La réaction la plus courante face à cette histoire — et elle a envahi les commentaires partout — était quelque chose comme « pourquoi diable connecter un frigo à Internet ? ». La question semble rhétorique, mais il y a une vraie réponse, et faire comme si ce n'était pas le cas, c'est ce qui nous oblige à reprendre cette discussion tous les deux ou trois ans.

La réfrigération commerciale n'est pas un simple frigo. Un supermarché de taille moyenne fait fonctionner un système thermique distribué : des dizaines de vitrines, des chambres froides et congélateurs, des racks de compresseurs, des condenseurs, le tout orchestré par des contrôleurs qui arbitrent entre température et coût énergétique. L'intérêt business de la connectivité à distance est réel :

  • Diagnostic à distance. Un prestataire de réfrigération qui s'occupe de centaines de magasins peut repérer la signature d'un compresseur défaillant plusieurs jours avant la panne. Envoyer un technicien appuyer physiquement sur un bouton pour un dégivrage de routine coûte cher ; une commande à distance ne coûte rien.
  • Optimisation énergétique. Les supermarchés font partie des bâtiments les plus gourmands en énergie au mètre carré. Les enseignes ajustent les températures des vitrines et les plannings de dégivrage sur l'ensemble de leur parc, et certaines participent à des programmes d'effacement où le fournisseur d'électricité les rémunère pour réduire leur consommation en période de tension sur le réseau.
  • Traçabilité réglementaire. La réglementation sur la sécurité alimentaire impose un enregistrement continu des températures. Les contrôleurs connectés produisent une piste d'audit automatique : plus de cahier papier, plus de relevés falsifiés.
  • Comparaison de flotte. Quand vous gérez 2 000 magasins, repérer qu'un magasin consomme 15 % d'énergie de plus que ses homologues permet de détecter une fuite de fluide frigorigène avant qu'elle ne devienne une facture de réparation à cinq chiffres.

Donc la connectivité n'est pas idiote. Ce qui est idiot, c'est la mise en œuvre. Les premiers éléments suggèrent que beaucoup de ces contrôleurs étaient joignables directement depuis Internet — certains avec leur propre modem cellulaire et carte SIM, posés sur des adresses IP publiques sans VPN, sans passerelle, sans liste d'autorisation. Et l'histoire de l'authentification, selon un récit largement partagé, était un identifiant admin associé à un mot de passe dérivé de la date du jour. Ce n'est pas une surface d'attaque, c'est une porte ouverte avec un paillasson de bienvenue.

Voilà à quoi ressemble réellement une attaque OT

Les ingénieurs logiciels ont tendance à imaginer les cyberattaques comme du vol de données : bases exfiltrées, identifiants qui fuitent, messages de rançongiciel. Les attaques OT sont différentes par nature, pas seulement par degré. La cible n'est pas une information, c'est un processus physique. La charge utile n'est pas un chiffrement, c'est une commande d'apparence légitime envoyée à un appareil qui fait confiance à quiconque se présente.

Remarquez à quel point l'attaque par dégivrage est élégante. Les attaquants n'ont pas eu besoin d'écrire un malware, d'élever leurs privilèges, ni même de comprendre totalement le protocole. Un cycle de dégivrage est une fonction normale et autorisée du contrôleur : il existe parce que le givre s'accumule sur les serpentins d'évaporation et doit être fondu périodiquement. L'attaquant n'a fait que le déclencher hors planning, à grande échelle. Aucune sécurité de sûreté ne s'est enclenchée, car du point de vue du contrôleur, rien d'anormal n'a été demandé. C'est l'équivalent OT du problème de l'adjoint confus : l'appareil exécute fidèlement des commandes qu'il n'aurait jamais dû recevoir.

Ce schéma se généralise tristement bien. Des stations de traitement d'eau ont été « attaquées » par quelqu'un qui a déplacé un curseur de dosage chimique. Des systèmes de gestion technique du bâtiment ont été pris par le biais de l'accès à distance du fournisseur de CVC. Dans presque tous les cas, la capacité dangereuse n'est pas un bug, c'est une fonctionnalité accessible à des personnes qui n'auraient jamais dû y accéder. C'est pourquoi la solution n'est pas une meilleure revue de code. C'est l'architecture.

Les vulnérabilités OT les plus dangereuses ne sont pas des corruptions de mémoire. Ce sont des fonctions légitimes exposées à des appelants illégitimes.

Le correctif que personne n'a appliqué

Voici le détail qui devrait faire grimacer chaque ingénieur sécurité : la vulnérabilité sous-jacente de ces contrôleurs avait été divulguée publiquement quelques mois plus tôt, dans un processus coordonné avec le fournisseur. Des chercheurs en sécurité ont publié une analyse détaillée. Des correctifs existaient, au moins pour certains modèles. Et l'attaque a eu lieu quand même.

C'est le sale secret des mises à jour industrielles. Dans l'informatique d'entreprise, nous sommes gâtés : une CVE critique tombe, et en quelques jours vos outils de gestion de parc ont relancé, préparé et déployé le correctif. L'OT ne fonctionne pas ainsi. Le contrôleur d'une vitrine de supermarché peut tourner quinze ans. Il appartient au magasin, est entretenu par un prestataire de réfrigération tiers, fabriqué par un fournisseur et configuré par un installateur qui a quitté l'entreprise il y a six ans. Qui, exactement, est responsable de l'application d'une mise à jour firmware sur 2 400 sites dans neuf pays ? En pratique : personne.

Pire encore, le fournisseur a apparemment livré le correctif sans le signaler clairement comme critique pour la sécurité. Pour un prestataire de maintenance avec une liste de matériel réellement en panne, « mise à jour du firmware disponible » ressemble à une corvée facultative. C'est autant un échec de communication qu'un échec technique. Si vous livrez un correctif pour une vulnérabilité qui permet à des inconnus de dégivrer les courses d'un pays, les notes de version doivent le dire en termes qu'un responsable des installations ne peut pas manquer. Le fossé entre spécification et implémentation ne crée pas seulement des bugs : il crée des flottes entières d'appareils non corrigés dont les exploitants ignorent qu'ils sont vulnérables.

Rayonnage sans fin de boîtiers de contrôle industriels identiques, dont un seul brille, fraîchement mis à jour.
Une flotte de contrôleurs embarqués peut tourner quinze ans sans que personne ne soit clairement responsable de leurs mises à jour.

Sécurité par défaut : concevoir pour le pire jour

Parlons de ce à quoi ressemble une bonne approche, car les principes ne sont pas exotiques. Ce sont les mêmes idées de conception défensive que nous appliquons dans les logiciels critiques pour la sûreté, mais rarement imposées dans le monde OT. J'ai déjà écrit sur l'ingénierie défensive qui résiste aux catastrophes, et les contrôleurs de réfrigération sont un cas d'école.

Limiter le débit des changements d'état dangereux

Un cycle de dégivrage est physiquement sans danger s'il tourne occasionnellement, et destructeur s'il tourne en continu. Il faut donc imposer la physique dans le firmware : après la fin d'un dégivrage, refuser un nouveau cycle pendant un intervalle minimal, quelle que soit la commande distante reçue. L'attaquant qui peut envoyer une demande de dégivrage peut en envoyer mille ; l'appareil ne doit pas accepter plus que ce que la physique permet. Cela coûte quelques lignes de code et un minuteur, et cela limite le rayon d'impact de toute compromission du plan de contrôle.

Les verrouillages locaux priment sur l'autorité distante

Si la température de la vitrine dépasse déjà un seuil, ou si les sondes produit indiquent une chaleur anormale, une commande de dégivrage à distance doit être rejetée et journalisée bruyamment. Le contrôleur dispose des données de capteurs pour savoir qu'une commande est absurde. Faites-le utiliser ces données. Une commande qui pousserait le système vers un état connu comme dangereux n'est pas une commande : c'est une erreur.

Des commandes signées, pas des mots de passe

Les mots de passe sur les appareils embarqués sont une cause perdue : ils seront par défaut, partagés, notés sur un post-it ou dérivés de la date. Le modèle plus solide est asymétrique : les contrôleurs vérifient une signature sur chaque commande distante, par rapport à une clé publique du fournisseur ou de l'exploitant, gravée lors du provisionnement. Ainsi, voler un mot de passe ne sert à rien : il faut la clé de signature, qui vit dans un HSM au centre d'exploitation, et non sur 2 400 vitrines. Oui, cela implique une infrastructure de gestion, de rotation et de révocation des clés. Oui, ça vaut le coup. Nous avons résolu ce problème pour les mises à jour logicielles il y a une dizaine d'années ; les canaux de commande méritent le même traitement.

Considérer le réseau comme hostile

Si un appareil est livré avec un modem cellulaire et un identifiant par défaut, il finira sur un moteur de recherche d'appareils exposés dans les semaines suivant son déploiement. La seule solution durable est de concevoir comme si cela était garanti : connexions entrantes refusées par défaut, télémétrie sortante uniquement vers un courtier, plan de gestion accessible uniquement via un tunnel à authentification mutuelle. « Ne l'exposez pas à Internet » est un conseil ; « rendre l'exposition survivable » est de l'ingénierie.

L'isolation n'est pas facultative : une segmentation bien faite

Tous les cadres de sécurité OT — IEC 62443, les recommandations du NIST, le fameux modèle de Purdue — disent la même chose : gardez les systèmes de contrôle hors des réseaux plats. Et pourtant, le modem cellulaire de la vitrine est l'anti-pattern incarné. Il contourne entièrement le pare-feu d'entreprise, créant des milliers de points d'entrée non surveillés et adressables individuellement, que l'équipe sécurité ne soupçonne peut-être même pas.

L'architecture qui fonctionne réellement ressemble à ceci :

  1. Les contrôleurs vivent sur un VLAN OT dédié, sans route vers Internet ni vers l'IT d'entreprise. Une seule passerelle peut leur parler.
  2. La passerelle applique des listes d'autorisation de protocoles — le contrôleur parle Modbus ou le protocole du fournisseur à la passerelle, et rien d'autre. Les anomalies ici sont des alertes à fort signal, car le trafic légitime est banal et prévisible.
  3. L'accès distant passe par un bastion avec MFA, enregistrement de session et identifiants à durée limitée. Le prestataire de réfrigération obtient une fenêtre de quatre heures sur un magasin précis, pas un VPN permanent sur tout le parc.
  4. Télémétrie sortante uniquement. Si le cloud du fournisseur a besoin des données de température, la passerelle les pousse. Rien ne tire depuis l'intérieur.
  5. Inventorier tout. On ne segmente pas ce qu'on ne connaît pas. Ce modem cellulaire de la vitrine est exactement le type de connectivité fantôme que les inventaires manquent — jusqu'à ce que Shodan le trouve pour vous.

Rien de tout cela n'est hypothétique ni coûteux comparé à l'alternative. La difficulté est organisationnelle, pas technique : il faut que l'équipe des installations, l'équipe sécurité IT et les fournisseurs s'accordent sur qui possède quoi. Dans la plupart des organisations de distribution, l'OT tombe dans l'interstice entre ces équipes : trop physique pour l'IT, trop connecté pour les installations. Cette ambiguïté est la vraie vulnérabilité, et c'est la même qui transforme les failles d'authentification cloud en intrusions invisibles, comme nous l'avons vu avec les angles morts de la journalisation de l'authentification cloud : si personne ne possède la télémétrie, personne ne voit l'attaque.

Vue aérienne d'un château aux remparts concentriques avec un donjon unique lumineux, métaphore de la segmentation réseau.
La défense en profondeur pour l'OT signifie un seul chemin étroit et surveillé entre le monde extérieur et le plan de contrôle.

Ce que les ingénieurs logiciels doivent retenir

Vous ne toucherez peut-être jamais à un contrôleur de réfrigération, mais les modes de défaillance ici sont ceux de tout système connecté, et ils deviennent de plus en plus votre problème. La frontière entre IT et OT ne cesse de se dissoudre : vos robots d'entrepôt, la climatisation de vos bureaux, vos instruments de laboratoire, votre bâtiment intelligent tournent tous sous Linux embarqué et parlent à des clouds. Certaines machines de laboratoire hospitalier refusent désormais de lancer des analyses tant que leur compte d'abonnement n'est pas approvisionné : une panne de facturation ou une fuite côté connecté peut donc paralyser le diagnostic médical. Nous avons construit ce monde, une fonctionnalité pratique à la fois.

Les leçons s'appliquent donc directement. Inventoriez votre exposition : si vous ne savez pas ce qui écoute, quelqu'un d'autre le trouvera. Traitez les opérations dangereuses comme privilégiées, même quand ce sont des « fonctionnalités normales », car l'attaquant qui atteint votre plan de contrôle se servira de vos fonctionnalités contre vous. Signez ce qui compte et faites expirer le reste. Concevez l'état de défaillance comme l'état sûr : un contrôleur qui perd la connectivité doit continuer à refroidir, et non considérer comme fiable chaque commande en attente. Et quand vous livrez un correctif de sécurité, dites-le haut et fort : un correctif que personne n'applique ne se distingue pas de l'absence de correctif.

L'attaque sur le dégivrage des supermarchés sera surtout retenue pour son absurdité : des pirates contre des petits pois surgelés. Mais la prochaine ne visera pas les glaces. Elle visera la même catégorie de contrôleurs exposés, non corrigés et faiblement authentifiés, dans un entrepôt pharmaceutique à froid, une centrale de refroidissement de data center ou un réseau d'eau municipal. Le matériel est le même. Les identifiants sont tout aussi mauvais. La seule variable, c'est ce qui chauffe, inonde ou s'arrête quand quelqu'un tape le mot de passe du jour.