cip-security-poc — Beweis für das Fix-Prinzip hinter CVE-2021-22681 (nicht nur dessen Schwachstelle)

Vier ausführbare Skripte. Echter EtherNet/IP-Protokollverkehr, echte Kryptografie, null Rockwell-Software oder -Lizenzierung in der gesamten Kette. Gebaut, um eine Behauptung vor dem Niederschreiben zu testen, nicht um sie blind zu vertreten.

Provenienz: erstellt am 31.07.2026, parallel zu einer Untersuchung der Kläranlage (WWTF) in Braham, MN — einer der vier öffentlich bekannt gewordenen Versorgungsbetriebe im koordinierten Vorfall im Wassersektor von Minnesota vom 26.–27. Juli 2026. Kontext zu diesem Vorfall findet sich in der CISA-Warnung AA26-097A (gemeinsam von FBI/CISA/NSA/EPA/DOE/USCYBERCOM/Finanzministerium; veröffentlicht am 07.04.2026, erweitert am 22.07.2026), die die laufende, IRGC-nahe CyberAv3ngers-Kampagne behandelt. Attributionsvorbehalt, präzise formuliert: Keine Behörde hat den Vorfall in Minnesota im Speziellen offiziell dieser Gruppe zugeschrieben — nur die breitere, laufende Kampagne. Dieser Ordner ist die technische Fix-Seite und wurde bewusst getrennt von der Vorfalluntersuchung gehalten.

Drei verschiedene Fehlerklassen — sauber auseinanderhalten

Ein Offenlegungspaket steht und fällt damit, diese nicht zu vermischen, denn jede hat einen anderen Fix:

• Keine / fehlende Authentifizierung (Test 1) — ein Gerät, das ganz ohne Berechtigungsebene exponiert ist. Die breite Baseline, auf die sich die CyberAv3ngers-Kampagne stützte (viele Opfer waren ohne oder mit Standard-Zugangsdaten erreichbar).
• Ein hartkodierter / gemeinsamer Schlüssel über eine gesamte Flotte (die spezifische Form von CVE-2021-22681, modelliert durch Test 2) — den einen Schlüssel einmal extrahieren, flottenweit fälschen. Das ist die eigentliche CVE.
• Standard-Zugangsdaten — Werks-Zugangsdaten, nie geändert. Hier nicht modelliert; benannt, um eine Verwechslung mit den beiden obigen zu vermeiden.

Der hier demonstrierte Fix — gerätebezogene Identitätsbindung (Test 3) — adressiert den Flotten-Schlüssel-Fehler.

Die harte Grenze (zuerst lesen)

Die beiden Zeilen nicht vermischen. Das Prinzip ist bewiesen. Die spezifische Implementierung des Herstellers ist glaubwürdig (es ist ihre eigene erklärte Designabsicht), aber von uns nicht gegen echte Geräte getestet.

Werkzeuge

test1_baseline_vulnerable.py — die No-Auth-Baseline, live

Startet einen echten EtherNet/IP-SPS-Simulator (cpppo, emuliert eine Allen-Bradley ControlLogix) und liest + schreibt ein Control-Tag mit null Zugangsdaten. (Umfang: Dies ist die breite Nicht-Authentifizierungs-Baseline, auf die sich die Kampagne stützte — nicht der spezifische Hardcoded-Key-Mechanismus von CVE-2021-22681. Bewusst getrennt gehalten; siehe „Drei verschiedene Fehlerklassen" oben.)

python test1_baseline_vulnerable.py

test2_shared_secret_fails.py — die Form des Flotten-Schlüssel-Fehlers (narrative Brücke, kein Test)

Zwei Endpunkte halten einen statischen Schlüssel; eine Berechtigung von Gerät A öffnet Gerät B unverändert — das strukturelle Analogon, das der Ein-Schlüssel-für-alle-Schwachstelle von CVE-2021-22681 am nächsten kommt. Aber das ist tautologisch: Beide Handler sind so konstruiert, dass sie diesen Schlüssel akzeptieren, es gibt also keinen Ausführungspfad, in dem es scheitern kann. Es demonstriert nichts, was der Code nicht selbst definiert. Beibehalten als narrative Brücke von Test 1 zu Test 3; es trägt kein Beweisgewicht und ist bewusst keine Beweis-Säule.

python test2_shared_secret_fails.py

test3_mutual_tls_fix.py — der Fix, mit Negativkontrolle und beiden Richtungen

Echte CA, zwei individuell eindeutige Gerätezertifikate — Identität gebunden im SubjectAlternativeName, nicht im veralteten CommonName. Fünf Fälle, alle ausgeführt:

• [1] Das eigene Zertifikat von Gerät A → GEWÄHRT · [2] kein Zertifikat → beim TLS-Handshake abgelehnt · [3] Das CA-valide Zertifikat von Gerät B → aus Identitätsgründen VERWEIGERT (strenger Endpunkt).
• [4] DIE KONTROLLE — das gleiche Zertifikat von Gerät B gegen einen Endpunkt, der nur die CA-Gültigkeit prüft → GEWÄHRT. Das ist es, was [3] bedeutungsvoll macht: Ohne die Identitätsprüfung öffnet jedes Flottenzertifikat jedes Gerät (== Test 2, im TLS-Gewand).
• [5] UMGEKEHRT — ein Rogue-Server, der das Zertifikat von Gerät B präsentiert, wird von einem Client abgelehnt, der an device-a bindet (check_hostname gegen einen echten SAN). Gegenseitig — beide Enden binden die Identität.

python test3_mutual_tls_fix.py

test4_revocation.py — der Lebenszyklus-Teil: Sperrung

Eine echte, CA-signierte CRL. Eine Client-Berechtigung (engineer-1) wird gewährt; dann wird ihre Seriennummer zur CRL hinzugefügt, und die gleiche, weiterhin gültige, nicht abgelaufene, CA-signierte Berechtigung wird verweigert — der empirische Gehalt der Sperr-Klausel von CR 1.8 / 1.9. Eindeutigkeit (Test 3) ≠ Sperrbarkeit; das zeigt, dass eine Berechtigung zurückgenommen werden kann.

python test4_revocation.py

Scope-Grenzen (was NICHT behauptet wird)

• Sperrung — jetzt demonstriert (test4_revocation.py); Rotation — noch nicht. Gerätebezogene Eindeutigkeit (Test 3) ist nicht dasselbe wie Sperrbarkeit; Test 4 schließt diese Lücke — eine weiterhin gültige, nicht abgelaufene, CA-signierte Berechtigung wird vor der Sperrung gewährt und danach verweigert, allein weil die CA-signierte CRL nun ihre Seriennummer listet. Rotation (eine Ersatz-Berechtigung neu ausstellen und die alte zurückziehen) ist eng verwandt und wird von derselben PKI ermöglicht, wird hier aber nicht separat demonstriert — daher darf sich „gerätebezogene Identitätsbindung" nicht stillschweigend zu „Rotation gelöst" ausweiten.
• Konstantzeit (niedriger Schweregrad, aus Hygienegründen benannt). Die Identitäts-String-Vergleiche (presented == KEY, identity in SAN) sind nicht konstantzeitlich. Hier nicht ausnutzbar — die verglichenen Werte sind halböffentliche Identitäts-Strings, und TLS hat die eigentliche kryptografische Authentifizierung bereits durchgeführt, bevor der Vergleich läuft — aber markiert, weil das Muster an Stellen kopiert wird, wo es doch eine Rolle spielt.

Setup

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

Nächste Schritte (ein echter Punkt bleibt offen, plus zwei kleine optionale)

• 62443-4-2-SL-2-Mapping — ENTWORFEN → 62443-4-2_SL2_MAPPING.md (CR 1.2 / 1.8 / 1.9 / 1.14 / 3.1, ehrlich abgestuft, jede Lücke benannt; CR 1.2, CR 1.9 und der Ausstellungs-/Validierungs-/Sperrungsteil von CR 1.8 sind nun demonstriert). Vor der PSIRT-Kontaktaufnahme ([email protected] / [email protected]): den normativen Text jeder CR gegen eine gekaufte Kopie von IEC 62443-4-2:2019 verifizieren.
• Phasenweiser Rollout — ENTWORFEN → PHASED_ROLLOUT.md (Phase 0 Blutung stoppen · 1 segmentieren · 2 kompensierende Kontrollen · 3 CIP Security/PKI, soweit die Hardware es zulässt · 4 betreiben). Passend dimensioniert für einen kleinen Versorgungsbetrieb; ehrlich darin, dass CIP Security hardwareabhängig ist, sodass die Phasen 0–2 die Risikoreduktion unabhängig davon tragen.
• Noch offen — das tatsächlich verbleibende Thema: die Reihenfolge der verantwortungsvollen Offenlegung (Responsible Disclosure). Zuerst PSIRT kontaktieren, danach öffentlicher Bericht / LinkedIn, damit die Provenienzkette in der richtigen Reihenfolge dokumentiert ist. Noch nicht entworfen: die PSIRT-E-Mail selbst.
• Zwei kleine technische Punkte, benannt und nicht unterschlagen (laut eigener Zusammenfassung des Mapping-Dokuments): ein Rotations-Test (neu ausstellen + zurückziehen), um CR 1.8 von „aktiviert" zu vollständig demonstriert zu bringen, und ein Manipulations-Injektions-Test, um CR 3.1 von „konstruktionsbedingt" zu demonstriert zu bringen. Keiner von beiden ist tragend für die zentrale Behauptung; beide sind klein, falls sie aufgegriffen werden.

Zitate — abgerufen, nicht erinnert (und vor der Einreichung erneut abrufen)

Jede externe Kennung hier wurde am 31.07.2026 aus einer Live-Quelle gezogen, nicht aus Trainingsdaten erinnert: AA26-097A (mehrere Quellen, inkl. WaterISAC / Tenable / SecurityWeek), Braham als eines der vier offengelegten Opfer, CyberAv3ngers/IRGC, PN1550 als echte Rockwell-Warnung bestätigt, mit ihrem Zeilen-2-Zitat wörtlich geprüft („When properly deployed, CIP Security remediates this vulnerability... does not make use of any hardcoded keys"), „cannot be mitigated with a patch" wörtlich, CVSS 10.0 / CRITICAL (v3.1), CISA-Tracking ICSA-21-056-03, und 62443-4-2 CR 1.8 (PKI) + CR 3.1 (Kommunikationsintegrität) exakt bestätigt. Disziplin für das Paket: Jede Kennung zum Zeitpunkt der Einreichung erneut aus Primärquellen ziehen. Sicherheitswarnungen werden umnummeriert, erweitert und ersetzt — AA26-097A zeigt bereits eine Erweiterung — also ist „verifiziert am 31.07.2026" nicht „verifiziert bei Einreichung“. Das vollständige formale CR-für-CR-62443-4-2-Mapping ist jetzt geschrieben (62443-4-2_SL2_MAPPING.md) — was bleibt, ist vor der Einreichung den zitierten normativen Text gegen eine gekaufte Normenkopie abzugleichen, nicht das Mapping selbst zu schreiben.

l0gic — Patrick Crosby · 2026-07-31.

Härtungsprotokoll: Test 3 wurde um die Negativkontrolle (Fall 4, beweist die Notwendigkeit, nicht nur dass sie greift), den Fall der umgekehrten Richtung (Fall 5, gegenseitige Bindung) und SAN-basierte Identität (nicht CN) erweitert und anschließend durch erneutes Ausführen aller fünf Fälle verifiziert; Test 4 (CRL-Sperrung) wurde hinzugefügt. Die Beschreibungen von Test 1/2 wurden nachjustiert, um die drei Fehlerklassen auseinanderzuhalten; Test 2 wurde vom „Test" zur narrativen Brücke herabgestuft; Scope-Grenzen für Sperrung und Konstantzeit wurden ergänzt. Die Zitationskette wurde aus Primärquellen abgerufen und für den erneuten Abruf bei der Einreichung markiert.