pcrosby-1990/cip-security-pocProof-of-concept reproducing CVE-2021-22681's hardcoded-key flaw and validating a per-device mutual TLS/CRL fix over simulated EtherNet/IP, with IEC 62443-4-2 mapping.
Six runnable scripts — real EtherNet/IP protocol traffic (Test 1), real TLS/PKI mechanics (Tests 3–6) — zero Rockwell software or licensing anywhere in the chain. Built to test a claim before writing it up, not to argue for it on faith.
Provenance: built 2026-07-31, alongside a parallel investigation into the Braham, MN WWTF — one of the four utilities publicly disclosed in the coordinated Minnesota water-sector incident of July 26–27, 2026. Context for that incident lives in CISA advisory AA26-097A (joint FBI/CISA/NSA/EPA/DOE/USCYBERCOM/Treasury; issued 2026-04-07, expanded 2026-07-22), which covers the ongoing IRGC-affiliated CyberAv3ngers campaign. Attribution caveat, held precisely: no agency has formally attributed the Minnesota incident specifically to that group — only the broader ongoing campaign is. This folder is the technical-fix side, kept separate from the incident investigation on purpose.
Rockwell PSIRT ([email protected]) and RA Secure Mail ([email protected]) were contacted 2026-07-31, before this repository and writeup went live (~30 minutes before, by file timestamps). Rockwell's security architecture team reviewed the repository and replied 2026-08-03. Quoted directly, not paraphrased into a stronger claim than they made:
Rockwell Automation does not endorse or validate your interpretation, your IEC 62443-4-2 mapping, or any conclusions drawn from the proof of concept. Please do not represent the work as reviewed, approved, or endorsed by Rockwell Automation... the scripts demonstrate general cryptographic and authentication principles rather than anything specific to CIP Security or to CVE-2021-22681.
This work has not been reviewed, approved, or endorsed by Rockwell Automation, full stop. Their
technical characterization — general principles, not CIP-Security-specific — is the same distinction
"The hard boundary" table below already draws about this repo's own claims; their review confirms it
independently rather than contesting it. For utilities on hardware that can't reach CIP Security,
Rockwell pointed to their own Converged Plantwide Ethernet (CPwE) Design and Implementation Guide
(cited in PHASED_ROLLOUT.md Phase 1) — the existing vendor resource this project tries to route
people toward rather than duplicate.
Test 1's finding — no authentication in the protocol's default state — is not unique to EtherNet/IP. Modbus TCP, still one of the most widely deployed protocols in water/wastewater control systems, has no authentication concept in the protocol specification at all; it dates to 1979 serial communications and was never designed with security in mind. CISA has repeatedly named exactly this failure across ICS advisories (e.g. Mitsubishi Electric's MELSEC iQ-F series: "MODBUS/TCP lacks proper authentication," allowing unauthorized read/write/halt). The Modbus Organization's own answer, Modbus/TCP Security, is TLS encapsulation with X.509 certificates — structurally the same fix category Test 3 demonstrates here, standardized at the protocol-organization level instead of one vendor's. DNP3 has an optional Secure Authentication extension (SAv5, standardized 2012); independent analysis and implementer accounts both describe it as rarely configured in practice, citing interoperability gaps between OT manufacturers and genuine protocol complexity — leaving the same exposure Test 1 demonstrates for EtherNet/IP.
The architectural point, stated precisely so it isn't oversold: Test 3's fix — mutual TLS, per-device identity bound in the certificate (not just CA validity), revocation via CRL — operates at the transport layer, not the ICS application protocol. The principle is equally applicable underneath Modbus, DNP3, or a proprietary protocol; what changes is the wrapper, not the shape of the fix. This repo has not built or run a Modbus- or DNP3-specific PoC — this is an architectural generalization from public documentation, held to the same "demonstrated vs. sourced" tiering as everything else here, not a new tested claim.
Sources: CISA ICS advisories on Modbus/TCP authentication gaps — Industrial Cyber · Modbus/TCP Security overview — Veridify · DNP3 SAv5/SAv6 adoption challenges — Step Function I/O
A disclosure packet lives or dies on not smearing these together, because each has a different fix:
The fix demonstrated here — per-device identity binding (Test 3) — addresses the fleet-key failure.
| Claim | Tier | Why | |
|---|---|---|---|
| The architectural principle | "a single shared secret across a fleet is compromised fleet-wide by one leak; per-device identity-bound authentication closes that" | PROVEN | demonstrated with real running code including the negative control that proves the check is necessary, not merely that it fires: on a strict endpoint Device B's genuinely CA-valid cert is rejected on identity (Test 3 · case 3), but on a CA-validity-only endpoint the same cert is accepted (case 4 — the control) → "validly CA-signed alone == fleet-wide access == Test 2 in TLS clothing." The binding also holds in reverse: a rogue server presenting a valid fleet cert is rejected by the client (case 5). Test 1 separately shows the broader no-auth baseline. |
| Rockwell's specific CIP Security implementation behaves identically | "enabling CIP Security on real Rockwell hardware remediates CVE-2021-22681 exactly this way" | LEAD, sourced not verified | this is Rockwell's own advisory (PN1550) language — "When properly deployed, CIP Security remediates this vulnerability... does not make use of any hardcoded keys" — not something we've independently confirmed against real Logix hardware. We tested the principle their advisory describes, not their exact wire-level implementation. |
Do not conflate the two rows. The principle is proven. The vendor's specific implementation of it is credible (it's their own stated design intent) but untested by us against real equipment.
test1_baseline_vulnerable.py — the no-auth baseline, liveSpins up a real EtherNet/IP PLC simulator (cpppo, emulating an Allen-Bradley ControlLogix) and
reads + writes a control tag with zero credentials. (Scope: this is the broad
no-authentication baseline the campaign leaned on — not the specific hardcoded-key mechanism
of CVE-2021-22681. Kept distinct on purpose; see "Three different failures" above.)
python test1_baseline_vulnerable.py