cip-security-poc — prouver le principe du correctif derrière CVE-2021-22681 (pas seulement sa faille)

Quatre scripts exécutables. Trafic de protocole EtherNet/IP réel, cryptographie réelle, zéro logiciel ou licence Rockwell dans la chaîne. Conçus pour tester une affirmation avant de la documenter, pas pour la défendre par simple foi.

Provenance : construit le 2026-07-31, en parallèle d'une investigation sur la WWTF 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 se trouve dans l'avis CISA AA26-097A (conjoint FBI/CISA/NSA/EPA/DOE/USCYBERCOM/Trésor ; publié le 2026-04-07, étendu le 2026-07-22), qui couvre la campagne CyberAv3ngers en cours, affiliée à l'IRGC. Réserve d'attribution, scrupuleusement respectée : aucune agence n'a officiellement attribué l'incident du Minnesota en particulier à ce groupe — seule la campagne plus large en cours l'est. Ce dossier est le volet correctif technique, volontairement tenu séparé de l'investigation sur l'incident.

Trois défaillances différentes — à ne pas confondre

Un dossier de divulgation se joue sur le fait de ne pas mélanger ces éléments, car chacun a un correctif différent :

• Aucune / absence d'authentification (Test 1) — un dispositif exposé sans aucune couche d'identifiants. La base large sur laquelle s'appuyait la campagne CyberAv3ngers (de nombreuses victimes étaient joignables avec des identifiants absents ou par défaut).
• Une clé codée en dur / partagée sur toute une flotte (la forme spécifique de CVE-2021-22681, modélisée par le Test 2) — extraire l'unique clé une seule fois, usurper toute la flotte. C'est la véritable CVE.
• Identifiants par défaut — des identifiants d'usine jamais modifiés. Non modélisés ici ; mentionnés pour ne pas être confondus avec les deux précédents.

Le correctif démontré ici — liaison d'identité par dispositif (Test 3) — répond à la défaillance de la clé de flotte.

La frontière stricte (à lire en premier)

Ne confondez pas les deux lignes. Le principe est prouvé. L'implémentation spécifique qu'en fait le fournisseur est crédible (c'est son intention de conception déclarée) mais non testée par nous sur du matériel réel.

Outils

test1_baseline_vulnerable.py — la base sans authentification, en direct

Démarre un véritable simulateur d'automate EtherNet/IP (cpppo, émulant un Allen-Bradley ControlLogix) et lit + écrit une balise de contrôle avec zéro identifiant. (Périmètre : il s'agit de la large base sans authentification sur laquelle s'appuyait la campagne — pas le mécanisme spécifique de clé codée en dur de CVE-2021-22681. Volontairement distinct ; voir « Trois défaillances différentes » ci-dessus.)

python test1_baseline_vulnerable.py

test2_shared_secret_fails.py — la forme de la faille de clé de flotte (pont narratif, pas un test)

Deux points de terminaison détiennent une clé statique ; un identifiant du Dispositif A ouvre le Dispositif B sans modification — l'analogue structurel le plus proche de la faille une-clé-pour-tous de CVE-2021-22681. Mais c'est tautologique : les deux gestionnaires sont construits pour accepter cette clé, il n'existe donc aucun chemin d'exécution où elle peut échouer. Cela ne démontre rien que le code ne définisse pas lui-même. Conservé comme pont narratif du Test 1 au Test 3 ; il n'a aucun poids probant et n'est délibérément pas une étape de preuve.

python test2_shared_secret_fails.py

test3_mutual_tls_fix.py — le correctif, avec son témoin négatif et ses deux sens

Vraie CA, deux certificats de dispositif individuellement uniques — identité liée dans le SubjectAlternativeName, pas dans le CommonName déprécié. Cinq cas, tous exécutés :

• [1] le propre certificat du Dispositif A → ACCORDÉ · [2] aucun certificat → rejeté à la poignée de main TLS · [3] le certificat valide CA du Dispositif B → REFUSÉ sur l'identité (point de terminaison strict).
• [4] LE TÉMOIN — le même certificat du Dispositif B contre un point de terminaison à validité CA uniquement → ACCORDÉ. C'est ce qui donne son sens à [3] : sans le contrôle d'identité, n'importe quel certificat de flotte ouvre n'importe quel dispositif (== Test 2, sous habillage TLS).
• [5] SENS INVERSE — un serveur rogue présentant le certificat du Dispositif B est rejeté par un client qui lie device-a (check_hostname contre un vrai SAN). Mutuel — les deux extrémités lient l'identité.

python test3_mutual_tls_fix.py

test4_revocation.py — le volet cycle de vie : la révocation

Une CRL réelle signée par la CA. Un identifiant client (engineer-1) est accordé ; puis son numéro de série est ajouté à la CRL, et le même identifiant, toujours valide, non expiré, signé par la CA, est refusé — le contenu empirique de la clause de révocation CR 1.8 / 1.9. L'unicité (Test 3) ≠ la révocabilité ; cela montre qu'un identifiant peut être retiré.

python test4_revocation.py

Limites du périmètre (ce qui n'est PAS affirmé)

• Révocation — désormais démontrée (test4_revocation.py) ; rotation — pas encore. L'unicité par dispositif (Test 3) n'est pas la même chose que la révocabilité ; le Test 4 comble cet écart — un identifiant toujours valide, non expiré, signé par la CA est accordé avant la révocation et refusé après, uniquement parce que la CRL signée par la CA liste désormais son numéro de série. La rotation (réémettre un identifiant de remplacement et retirer l'ancien) est étroitement liée et rendue possible par la même PKI, mais n'est pas démontrée séparément ici — donc « liaison d'identité par dispositif » ne doit pas encore s'étendre silencieusement en « rotation résolue ».
• Temps constant (sévérité faible, mentionné par hygiène). Les comparaisons de chaînes d'identité (presented == KEY, identity in SAN) ne sont pas à temps constant. Non exploitable ici — les valeurs comparées sont des chaînes d'identité quasi publiques et TLS a déjà effectué la véritable authentification cryptographique avant que la comparaison ne s'exécute — mais signalé car le motif est copié dans des endroits où cela compte vraiment.

Installation

python -m venv venv
venv\Scripts\activate        # or: source venv/bin/activate
pip install -r requirements.txt

Prochaines étapes (une vraie tâche restante, plus deux petites options)

• Correspondance 62443-4-2 SL 2 — RÉDIGÉE → 62443-4-2_SL2_MAPPING.md (CR 1.2 / 1.8 / 1.9 / 1.14 / 3.1, honnêtement classés par niveau, chaque lacune nommée ; le volet émission/validation/révocation des CR 1.2, CR 1.9 et CR 1.8 est désormais démontré). Avant le PSIRT ([email protected] / [email protected]) : vérifier le texte normatif de chaque CR par rapport à un exemplaire acheté de l'IEC 62443-4-2:2019.
• Déploiement par phases — RÉDIGÉ → PHASED_ROLLOUT.md (Phase 0 stopper l'hémorragie · 1 segmenter · 2 contrôles compensatoires · 3 CIP Security/PKI, si le matériel le permet · 4 exploiter). Dimensionné pour une petite régie ; honnête sur le fait que CIP Security est conditionné par le matériel, donc les phases 0–2 portent la réduction des risques dans tous les cas.
• Toujours ouverte — la véritable tâche restante : le séquencement de la divulgation responsable. Contact PSIRT d'abord, article public / post LinkedIn ensuite, afin que la chaîne de provenance soit documentée dans l'ordre. Pas encore rédigé : l'e-mail au PSIRT lui-même.
• Deux petits éléments techniques, nommés et non dissimulés (selon le résumé du document de correspondance lui-même) : un test de rotation (réémettre + retirer) pour faire passer CR 1.8 de « activé » à pleinement démontré, et un test d'injection de données falsifiées pour faire passer CR 3.1 de « par construction » à démontré. Aucun n'est déterminant pour l'affirmation centrale ; les deux sont de petite taille s'ils sont entrepris.

Citations — récupérées, non ressorties de mémoire (et à re-récupérer avant soumission)

Chaque identifiant externe ici a été extrait d'une source en ligne le 2026-07-31, et non ressorti de mémoire d'entraînement : AA26-097A (multi-source, incl. WaterISAC / Tenable / SecurityWeek), Braham comme l'une des quatre victimes divulguées, CyberAv3ngers/IRGC, PN1550 a confirmé qu'il s'agissait du véritable avis Rockwell, avec sa citation de la ligne 2 vérifiée mot pour mot (« When properly deployed, CIP Security remediates this vulnerability » + « does not make use of any hardcoded keys »), « cannot be mitigated with a patch » mot pour mot, CVSS 10.0 / CRITIQUE (v3.1), numéro de suivi CISA ICSA-21-056-03, et 62443-4-2 CR 1.8 (PKI) + CR 3.1 (intégrité des communications) confirmés exacts. Discipline pour le dossier : re-récupérer chaque identifiant depuis des sources primaires au moment de la soumission. Les avis sont renumérotés, étendus et remplacés — AA26-097A montre déjà une extension — donc « vérifié le 2026-07-31 » n'est pas « vérifié à la soumission ». La correspondance formelle complète 62443-4-2, CR par CR, est désormais rédigée (62443-4-2_SL2_MAPPING.md) — ce qui reste, c'est de re-récupérer son texte normatif cité par rapport à un exemplaire acheté de la norme avant soumission, pas de rédiger la correspondance elle-même.

l0gic — Patrick Crosby · 2026-07-31.

Journal de durcissement : le Test 3 a été renforcé pour inclure le témoin négatif (cas 4, prouvant la nécessité et pas seulement le déclenchement), le cas en sens inverse (cas 5, liaison mutuelle) et l'identité basée sur le SAN (pas le CN), puis re-vérifié en ré-exécutant les cinq cas ; le Test 4 (révocation par CRL) a été ajouté. Les légendes des Tests 1/2 ont été ajustées pour garder les trois classes de défaillance distinctes ; le Test 2 a été rétrogradé de « test » à pont narratif ; les limites de périmètre sur la révocation et le temps constant ont été ajoutées. La chaîne de citations a été extraite de sources primaires et marquée pour re-récupération à la soumission.