cip-security-poc — dimostrare il principio della correzione dietro CVE-2021-22681 (non solo la sua vulnerabilità)

Sei script eseguibili — traffico reale del protocollo EtherNet/IP (Test 1), meccanismi reali TLS/PKI (Test 3–6) — zero software Rockwell o licenze in qualsiasi punto della catena. Costruito per testare un'affermazione prima di scriverla, non per sostenerla per fede.

Provenienza: costruito il 31-07-2026, parallelamente a un'indagine sull'impianto di trattamento acque reflue di Braham, MN — uno dei quattro servizi pubblici divulgati pubblicamente nell'incidente coordinato del settore idrico del Minnesota del 26–27 luglio 2026. Il contesto di quell'incidente è descritto nell'advisory CISA AA26-097A (congiunta FBI/CISA/NSA/EPA/DOE/USCYBERCOM/Treasury; emessa il 07-04-2026, ampliata il 22-07-2026), che copre la campagna in corso CyberAv3ngers affiliata all'IRGC. Precisazione sull'attribuzione, mantenuta con rigore: nessuna agenzia ha attribuito formalmente l'incidente del Minnesota nello specifico a quel gruppo — solo la più ampia campagna in corso lo è. Questa cartella riguarda il lato della correzione tecnica, tenuta separata dall'indagine sull'incidente di proposito.

Stato del fornitore (aggiornato al 03-08-2026)

Rockwell PSIRT ([email protected]) e RA Secure Mail ([email protected]) sono stati contattati il 31-07-2026, prima che questo repository e il documento andassero online (~30 minuti prima, secondo i timestamp dei file). Il team di architettura della sicurezza di Rockwell ha esaminato il repository e ha risposto il 03-08-2026. Citato direttamente, non parafrasato in un'affermazione più forte di quella fatta:

Rockwell Automation non approva né valida la tua interpretazione, la tua mappatura IEC 62443-4-2, o qualsiasi conclusione tratta dalla proof of concept. Ti preghiamo di non presentare il lavoro come revisionato, approvato, o approvato da Rockwell Automation... gli script dimostrano principi crittografici e di autenticazione generali piuttosto che qualcosa di specifico per CIP Security o per CVE-2021-22681.

Questo lavoro non è stato revisionato, approvato o avallato da Rockwell Automation, punto. La loro caratterizzazione tecnica — principi generali, non specifici di CIP Security — è la stessa distinzione che la tabella "Il confine netto" qui sotto traccia già riguardo alle affermazioni di questo repo; la loro revisione la conferma in modo indipendente piuttosto che contestarla. Per i servizi pubblici su hardware che non può raggiungere CIP Security, Rockwell ha indicato la propria Converged Plantwide Ethernet (CPwE) Design and Implementation Guide (citata in PHASED_ROLLOUT.md Fase 1) — la risorsa esistente del fornitore verso cui questo progetto cerca di indirizzare le persone piuttosto che duplicarla.

Questa forma non è specifica di Rockwell

Il risultato del Test 1 — nessuna autenticazione nello stato predefinito del protocollo — non è unico di EtherNet/IP. Modbus TCP, ancora uno dei protocolli più ampiamente distribuiti nei sistemi di controllo acqua/reflui, non ha alcun concetto di autenticazione nella specifica del protocollo; risale alle comunicazioni seriali del 1979 e non è mai stato progettato pensando alla sicurezza. La CISA ha ripetutamente segnalato esattamente questo difetto nelle advisory ICS (ad es. la serie MELSEC iQ-F di Mitsubishi Electric: "MODBUS/TCP manca di una corretta autenticazione," consentendo lettura/scrittura/arresto non autorizzati). La risposta della stessa Modbus Organization, Modbus/TCP Security, è l'incapsulamento TLS con certificati X.509 — strutturalmente la stessa categoria di correzione che il Test 3 dimostra qui, standardizzata a livello di organizzazione del protocollo invece che di un singolo fornitore. DNP3 ha un'estensione opzionale Secure Authentication (SAv5, standardizzata nel 2012); analisi indipendenti e resoconti di implementatori descrivono entrambi come raramente configurata nella pratica, citando lacune di interoperabilità tra i produttori OT e una genuina complessità del protocollo — lasciando la stessa esposizione che il Test 1 dimostra per EtherNet/IP.

Il punto architetturale, espresso con precisione per non essere sopravvalutato: la correzione del Test 3 — TLS reciproco, identità per-dispositivo vincolata nel certificato (non solo validità CA), revoca tramite CRL — opera a livello di trasporto, non sul protocollo applicativo ICS. Il principio è ugualmente applicabile sotto Modbus, DNP3 o un protocollo proprietario; ciò che cambia è il wrapper, non la forma della correzione. Questo repo non ha costruito o eseguito una PoC specifica per Modbus o DNP3 — questa è una generalizzazione architetturale dalla documentazione pubblica, mantenuta allo stesso livello "dimostrato vs. fontato" di tutto il resto qui, non una nuova affermazione testata.

Fonti: Advisory ICS CISA sulle lacune di autenticazione Modbus/TCP — Industrial Cyber · Panoramica Modbus/TCP Security — Veridify · Sfide di adozione DNP3 SAv5/SAv6 — Step Function I/O

Tre diversi tipi di guasto — tenerli distinti

Un pacchetto di divulgazione vive o muore sul non mescolare questi elementi, perché ognuno ha una correzione diversa:

• Nessuna / assente autenticazione (Test 1) — un dispositivo esposto senza alcun livello di credenziali. La baseline ampia su cui la campagna CyberAv3ngers faceva affidamento (molte vittime erano raggiungibili con credenziali assenti o predefinite).
• Una chiave hardcoded / condivisa su un'intera flotta (la forma specifica di CVE-2021-22681, modellata dal Test 2) — estrai l'unica chiave una volta, falsifica a livello di flotta. Questa è la vera CVE.
• Credenziali predefinite — credenziali di fabbrica mai modificate. Non modellate qui; nominate così da non essere confuse con le due precedenti.

La correzione dimostrata qui — vincolo dell'identità per-dispositivo (Test 3) — affronta il guasto della chiave di flotta.

Il confine netto (leggere prima questo)

	Affermazione	Livello	Perché
Il principio architetturale	"un singolo segreto condiviso su una flotta è compromesso a livello di flotta da una singola fuga; l'autenticazione per-dispositivo vincolata all'identità chiude questo"	DIMOSTRATO	dimostrato con codice reale in esecuzione incluso il controllo negativo che prova che il controllo è necessario, non solo che scatta: su un endpoint rigoroso, il certificato genuinamente valido per CA del Dispositivo B viene rifiutato sull'identità (Test 3 · caso 3), ma su un endpoint solo-validità-CA lo stesso certificato viene accettato (caso 4 — il controllo) → "firmato validamente dalla CA da solo == accesso a livello di flotta == Test 2 in veste TLS." Il vincolo vale anche in senso inverso: un server rogue che presenta un certificato di flotta valido viene rifiutato dal client (caso 5). Il Test 1 mostra separatamente la più ampia baseline senza autenticazione.
L'implementazione CIP Security specifica di Rockwell si comporta in modo identico	"abilitare CIP Security su hardware Rockwell reale corregge CVE-2021-22681 esattamente in questo modo"	INDIZIO, fontato non verificato	questo è il linguaggio dell'advisory stessa di Rockwell (PN1550) — "Quando implementata correttamente, CIP Security corregge questa vulnerabilità... non fa uso di alcuna chiave hardcoded" — non qualcosa che abbiamo confermato in modo indipendente contro hardware Logix reale. Abbiamo testato il principio che la loro advisory descrive, non la loro esatta implementazione a livello di protocollo.