pcrosby-1990/cip-security-pocPreuve de concept reproduisant la faille de clé codée en dur de CVE-2021-22681 et validant un correctif TLS mutuel/CRL par appareil sur EtherNet/IP simulé, avec mise en correspondance IEC 62443-4-2.
Six scripts exécutables — trafic réel du protocole EtherNet/IP (Test 1), mécanismes réels TLS/PKI (Tests 3–6) — zéro logiciel ou licence Rockwell dans toute la chaîne. Conçus pour tester une affirmation avant de la rédiger, pas pour la défendre par simple conviction.
Provenance : construit le 2026-07-31, en parallèle d'une enquête sur la station de traitement des eaux usées de Braham, MN — l'une des quatre installations publiquement divulguées lors de l'incident coordonné du secteur de l'eau du Minnesota des 26 et 27 juillet 2026. Le contexte de cet incident figure dans l'avis CISA AA26-097A (conjoint FBI/CISA/NSA/EPA/DOE/USCYBERCOM/Treasury ; publié le 2026-04-07, étendu le 2026-07-22), qui couvre la campagne en cours CyberAv3ngers affiliée à l'IRGC. Réserve d'attribution, tenue avec précision : aucune agence n'a formellement attribué l'incident du Minnesota spécifiquement à ce groupe — seule la campagne plus large en cours l'est. Ce dossier est le volet technique de la correction, volontairement séparé de l'enquête sur l'incident.
Rockwell PSIRT ([email protected]) et RA Secure Mail ([email protected]) ont été contactés le 2026-07-31, avant la mise en ligne de ce dépôt et de cette analyse (~30 minutes avant, selon les horodatages des fichiers). L'équipe d'architecture de sécurité de Rockwell a examiné le dépôt et a répondu le 2026-08-03. Citation directe, non reformulée en une affirmation plus forte que la leur :
Rockwell Automation n'approuve ni ne valide votre interprétation, votre correspondance avec l'IEC 62443-4-2, ni aucune conclusion tirée de la preuve de concept. Veuillez ne pas présenter ce travail comme ayant été examiné, approuvé ou cautionné par Rockwell Automation... les scripts démontrent des principes généraux de cryptographie et d'authentification plutôt que quoi que ce soit de spécifique à CIP Security ou à CVE-2021-22681.
Ce travail n'a pas été examiné, approuvé ni cautionné par Rockwell Automation, point final. Leur
caractérisation technique — principes généraux, pas spécifiques à CIP Security — est la même distinction
que le tableau « La frontière stricte » ci-dessous établit déjà concernant les affirmations de ce dépôt ;
leur examen la confirme indépendamment plutôt que de la contester. Pour les installations sur du matériel
qui ne peut pas atteindre CIP Security, Rockwell a renvoyé vers son propre guide de conception et de mise
en œuvre Converged Plantwide Ethernet (CPwE) (cité dans PHASED_ROLLOUT.md Phase 1) — la ressource
fournisseur existante vers laquelle ce projet tente d'orienter les gens plutôt que de la dupliquer.
La conclusion du Test 1 — aucune authentification dans l'état par défaut du protocole — n'est pas propre à EtherNet/IP. Modbus TCP, toujours l'un des protocoles les plus déployés dans les systèmes de contrôle de l'eau et des eaux usées, ne comporte aucune notion d'authentification dans la spécification du protocole ; il date des communications série de 1979 et n'a jamais été conçu avec la sécurité à l'esprit. La CISA a régulièrement cité exactement cette défaillance dans ses avis ICS (par ex. la série MELSEC iQ-F de Mitsubishi Electric : « MODBUS/TCP manque d'authentification appropriée », permettant des lectures/écritures/ arrêts non autorisés). La réponse propre de la Modbus Organization, Modbus/TCP Security, est une encapsulation TLS avec certificats X.509 — structurellement la même catégorie de correction que le Test 3 démontre ici, normalisée au niveau de l'organisation du protocole plutôt que chez un seul fournisseur. DNP3 dispose d'une extension optionnelle Secure Authentication (SAv5, normalisée en 2012) ; des analyses indépendantes et des témoignages d'intégrateurs décrivent tous deux qu'elle est rarement configurée en pratique, citant des écarts d'interopérabilité entre fabricants d'OT et une complexité protocolaire réelle — laissant la même exposition que le Test 1 démontre pour EtherNet/IP.
Le point architectural, énoncé avec précision pour ne pas être survendu : la correction du Test 3 — TLS mutuel, identité par périphérique liée dans le certificat (pas seulement la validité de l'AC), révocation via CRL — opère au niveau de la couche transport, pas au niveau du protocole applicatif ICS. Le principe est également applicable sous Modbus, DNP3 ou un protocole propriétaire ; ce qui change, c'est l'emballage, pas la forme de la correction. Ce dépôt n'a pas construit ni exécuté de PoC spécifique Modbus ou DNP3 — il s'agit d'une généralisation architecturale à partir de documentation publique, soumise au même classement « démontré vs sourcé » que tout le reste ici, pas d'une nouvelle affirmation testée.
Sources : Avis ICS de la CISA sur les lacunes d'authentification Modbus/TCP — Industrial Cyber · Vue d'ensemble de Modbus/TCP Security — Veridify · Défis d'adoption DNP3 SAv5/SAv6 — Step Function I/O
Un dossier de divulgation se joue ou se perd sur le fait de ne pas mélanger ces éléments, car chacun a une correction différente :
La correction démontrée ici — liaison d'identité par périphérique (Test 3) — répond à la défaillance de la clé de parc.
| Affirmation | Niveau | Pourquoi | |
|---|---|---|---|
| Le principe architectural | « un secret unique partagé sur un parc est compromis à l'échelle du parc par une seule fuite ; une authentification liée à l'identité par périphérique comble cette faille » | PROUVÉ | démontré avec du code réellement exécuté y compris le contrôle négatif qui prouve que le contrôle est nécessaire, pas seulement qu'il se déclenche : sur un point de terminaison strict, le certificat réellement valide CA du périphérique B est rejeté sur l'identité (Test 3 · cas 3), mais sur un point de terminaison à validité CA uniquement, le même certificat est accepté (cas 4 — le contrôle) → « une signature CA valide seule == accès à l'échelle du parc == Test 2 en habit TLS ». La liaison tient aussi dans le sens inverse : un serveur rogue présentant un certificat de parc valide est rejeté par le client (cas 5). Le Test 1 montre séparément la base plus large sans authentification. |
| L'implémentation spécifique de CIP Security chez Rockwell se comporte à l'identique | « activer CIP Security sur du matériel Rockwell réel corrige CVE-2021-22681 exactement de cette façon » | PISTE, sourcée non vérifiée | c'est le langage de l'avis propre de Rockwell (PN1550) — « Lorsqu'il est correctement déployé, CIP Security corrige cette vulnérabilité... n'utilise aucune clé codée en dur » — pas quelque chose que nous avons confirmé indépendamment contre du matériel Logix réel. Nous avons testé le principe que leur avis décrit, pas leur implémentation exacte au niveau du câble. |
