cip-security-poc — Nachweis des Prinzips der Behebung hinter CVE-2021-22681 (nicht nur dessen Schwachstelle)

Sechs ausführbare Skripte — echter EtherNet/IP-Protokollverkehr (Test 1), echte TLS/PKI-Mechanik (Tests 3–6) — keinerlei Rockwell-Software oder -Lizenzierung in der gesamten Kette. Entwickelt, um eine Behauptung zu testen, bevor sie niedergeschrieben wird, nicht um sie blind zu vertreten.

Herkunft: erstellt am 31.07.2026, parallel zu einer Untersuchung der Kläranlage in Braham, MN — einer der vier öffentlich bekannt gewordenen Versorgungsunternehmen 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; herausgegeben am 07.04.2026, erweitert am 22.07.2026), die die laufende, dem IRGC zugeschriebene Kampagne CyberAv3ngers abdeckt. Präzise gehaltener Zuschreibungsvorbehalt: Keine Behörde hat den Vorfall in Minnesota im Speziellen formell dieser Gruppe zugeordnet — nur die breitere, laufende Kampagne. Dieser Ordner behandelt die technische Behebungsseite und ist bewusst getrennt von der Vorfalluntersuchung gehalten.

Status des Herstellers (aktualisiert am 03.08.2026)

Rockwell PSIRT ([email protected]) und RA Secure Mail ([email protected]) wurden am 31.07.2026 kontaktiert, bevor dieses Repository und der Bericht live gingen (~30 Minuten vorher, laut Dateizeitstempeln). Das Sicherheitsarchitektur-Team von Rockwell hat das Repository geprüft und am 03.08.2026 geantwortet. Direkt zitiert, nicht zu einer stärkeren Aussage umformuliert, als sie gemacht haben:

Rockwell Automation befürwortet oder validiert weder Ihre Interpretation, noch Ihre IEC-62443-4-2-Zuordnung, noch Schlussfolgerungen aus dem Proof of Concept. Bitte stellen Sie die Arbeit nicht als von Rockwell Automation geprüft, genehmigt oder befürwortet dar... die Skripte demonstrieren allgemeine kryptografische und Authentifizierungsprinzipien und nicht etwas spezifisch für CIP Security oder CVE-2021-22681.

Diese Arbeit wurde von Rockwell Automation weder geprüft, genehmigt noch befürwortet, Punkt. Ihre technische Charakterisierung — allgemeine Prinzipien, nicht CIP-Security-spezifisch — ist dieselbe Unterscheidung, die die Tabelle „Die harte Grenze" unten bereits über die eigenen Behauptungen dieses Repos trifft; ihre Prüfung bestätigt sie unabhängig, anstatt sie anzufechten. Für Versorgungsunternehmen mit Hardware, die CIP Security nicht erreichen kann, verwies Rockwell auf ihren eigenen Converged Plantwide Ethernet (CPwE) Design and Implementation Guide (zitiert in PHASED_ROLLOUT.md Phase 1) — die bestehende Herstellerressource, zu der dieses Projekt die Leute hinführen möchte, anstatt sie zu duplizieren.

Diese Form ist nicht Rockwell-spezifisch

Die Erkenntnis aus Test 1 — keine Authentifizierung im Standardzustand des Protokolls — ist nicht einzigartig für EtherNet/IP. Modbus TCP, immer noch eines der am weitesten verbreiteten Protokolle in Wasser-/Abwasser- Leitsystemen, hat in der Protokollspezifikation überhaupt kein Authentifizierungskonzept; es stammt aus der seriellen Kommunikation von 1979 und wurde nie mit Blick auf Sicherheit entwickelt. CISA hat genau dieses Versagen wiederholt in ICS-Warnungen benannt (z. B. Mitsubishi Electrics MELSEC-iQ-F-Serie: „MODBUS/TCP mangelt es an ordnungsgemäßer Authentifizierung", was unbefugtes Lesen/Schreiben/Anhalten ermöglicht). Die eigene Antwort der Modbus-Organization, Modbus/TCP Security, ist TLS-Kapselung mit X.509-Zertifikaten — strukturell dieselbe Behebungskategorie, die Test 3 hier demonstriert, standardisiert auf Ebene der Protokollorganisation statt bei einem einzelnen Hersteller. DNP3 hat eine optionale Secure-Authentication-Erweiterung (SAv5, 2012 standardisiert); unabhängige Analysen und Berichte von Implementierern beschreiben sie gleichermaßen als in der Praxis selten konfiguriert, unter Verweis auf Interoperabilitätslücken zwischen OT-Herstellern und echte Protokollkomplexität — was dieselbe Exposition hinterlässt, die Test 1 für EtherNet/IP demonstriert.

Der architektonische Punkt, präzise formuliert, damit er nicht überverkauft wird: Die Behebung aus Test 3 — gegenseitiges TLS, geräteindividuelle Identität im Zertifikat gebunden (nicht nur CA-Gültigkeit), Widerruf per CRL — arbeitet auf der Transportschicht, nicht auf dem ICS-Anwendungsprotokoll. Das Prinzip ist gleichermaßen anwendbar unter Modbus, DNP3 oder einem proprietären Protokoll; was sich ändert, ist der Wrapper, nicht die Form der Behebung. Dieses Repo hat keinen Modbus- oder DNP3-spezifischen PoC erstellt oder ausgeführt — dies ist eine architektonische Verallgemeinerung aus öffentlicher Dokumentation, gehalten an derselben „demonstriert vs. belegt"- Abstufung wie alles andere hier, keine neue getestete Behauptung.

Quellen: CISA-ICS-Warnungen zu Modbus/TCP-Authentifizierungslücken — Industrial Cyber · Modbus/TCP-Security-Überblick — Veridify · Herausforderungen bei der Einführung von DNP3 SAv5/SAv6 — Step Function I/O

Drei verschiedene Fehler — halten Sie sie getrennt

Ein Offenlegungspaket steht und fällt damit, diese nicht zu vermischen, denn jeder hat eine andere Behebung:

• Keine / fehlende Authentifizierung (Test 1) — ein Gerät, das ohne jegliche Anmeldeebene exponiert ist. Die breite Basislinie, auf die sich die CyberAv3ngers-Kampagne stützte (viele Opfer waren mit fehlenden oder Standard-Anmeldedaten erreichbar).
• Ein fest verdrahteter / gemeinsamer Schlüssel über eine 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-Anmeldedaten — Werks-Anmeldedaten nie geändert. Hier nicht modelliert; benannt, damit es nicht mit den beiden obigen verwechselt wird.

Die hier demonstrierte Behebung — geräteindividuelle Identitätsbindung (Test 3) — adressiert den Flotten-Schlüssel-Fehler.

Die harte Grenze (zuerst lesen)

	Behauptung	Stufe	Warum
Das architektonische Prinzip	„Ein einzelnes gemeinsames Geheimnis über eine Flotte wird durch einen einzigen Leak flottenweit kompromittiert; geräteindividuelle, identitätsgebundene Authentifizierung schließt das"	BEWIESEN	demonstriert mit echtem, laufendem Code einschließlich der Negativkontrolle, die beweist, dass die Prüfung notwendig ist, nicht nur, dass sie greift: an einem strengen Endpunkt wird Gerät B's echt CA-gültiges Zertifikat bei Gerät A abgelehnt aufgrund der Identität (Test 3 · Fall 3), aber an einem Endpunkt mit nur CA-Gültigkeit wird dasselbe Zertifikat akzeptiert (Fall 4 — die Kontrolle) → „allein gültig CA-signiert == flottenweiter Zugriff == Test 2 im TLS-Gewand." Die Bindung gilt auch umgekehrt: Ein betrügerischer Server, der ein gültiges Flottenzertifikat präsentiert, wird vom Client abgelehnt (Fall 5). Test 1 zeigt separat die breitere No-Auth-Basislinie.
Rockwells spezifische CIP-Security-Implementierung verhält sich identisch	„Das Aktivieren von CIP Security auf echter Rockwell-Hardware behebt CVE-2021-22681 genau auf diese Weise"	LEAD, belegt nicht verifiziert	dies ist die Sprache von Rockwells eigener Warnung (PN1550) — „Bei ordnungsgemäßer Bereitstellung behebt CIP Security diese Schwachstelle... verwendet keine fest verdrahteten Schlüssel" — nichts, was wir unabhängig gegen echte Logix-Hardware bestätigt haben. Wir haben das Prinzip getestet, das ihre Warnung beschreibt, nicht ihre exakte Implementierung auf Drahtebene.