pcrosby-1990/cip-security-pocPrueba de concepto que reproduce la falla de clave codificada de CVE-2021-22681 y valida una corrección de TLS mutuo/CRL por dispositivo sobre EtherNet/IP simulado, con mapeo de IEC 62443-4-2.
Seis scripts ejecutables — tráfico real de protocolo EtherNet/IP (Prueba 1), mecánica real de TLS/PKI (Pruebas 3–6) — cero software o licencias de Rockwell en toda la cadena. Construido para probar una afirmación antes de documentarla, no para defenderla por fe.
Procedencia: construido el 2026-07-31, junto con una investigación paralela sobre la planta de tratamiento de aguas residuales (WWTF) de Braham, MN — una de las cuatro utilidades divulgadas públicamente en el incidente coordinado del sector hídrico de Minnesota del 26–27 de julio de 2026. El contexto de ese incidente se encuentra en el aviso de CISA AA26-097A (conjunto FBI/CISA/NSA/EPA/DOE/USCYBERCOM/Tesorería; emitido el 2026-04-07, ampliado el 2026-07-22), que cubre la campaña en curso CyberAv3ngers afiliada al IRGC. Salvedad de atribución, sostenida con precisión: ninguna agencia ha atribuido formalmente el incidente de Minnesota específicamente a ese grupo — solo la campaña más amplia en curso lo está. Esta carpeta es el lado de la corrección técnica, mantenida separada de la investigación del incidente a propósito.
Se contactó a Rockwell PSIRT ([email protected]) y a RA Secure Mail ([email protected]) el 2026-07-31, antes de que este repositorio y el informe se hicieran públicos (~30 minutos antes, según las marcas de tiempo de los archivos). El equipo de arquitectura de seguridad de Rockwell revisó el repositorio y respondió el 2026-08-03. Citado directamente, no parafraseado para convertirlo en una afirmación más fuerte de la que hicieron:
Rockwell Automation no respalda ni valida su interpretación, su mapeo de IEC 62443-4-2, ni ninguna conclusión derivada de la prueba de concepto. Por favor, no presente el trabajo como revisado, aprobado o respaldado por Rockwell Automation... los scripts demuestran principios generales de criptografía y autenticación, más que algo específico de CIP Security o de CVE-2021-22681.
Este trabajo no ha sido revisado, aprobado ni respaldado por Rockwell Automation, punto. Su
caracterización técnica — principios generales, no específicos de CIP Security — es la misma distinción
que la tabla "El límite estricto" a continuación ya establece sobre las afirmaciones de este propio repositorio; su revisión lo confirma
de forma independiente en lugar de refutarlo. Para utilidades en hardware que no puede alcanzar CIP Security,
Rockwell señaló su propia Guía de Diseño e Implementación de Ethernet Convergente de Planta (CPwE)
(citada en PHASED_ROLLOUT.md Fase 1) — el recurso existente del proveedor hacia el que este proyecto intenta orientar
a las personas en lugar de duplicarlo.
El hallazgo de la Prueba 1 — sin autenticación en el estado predeterminado del protocolo — no es exclusivo de EtherNet/IP. Modbus TCP, todavía uno de los protocolos más ampliamente desplegados en sistemas de control de agua/aguas residuales, no tiene ningún concepto de autenticación en la especificación del protocolo; data de comunicaciones seriales de 1979 y nunca fue diseñado con la seguridad en mente. CISA ha nombrado repetidamente exactamente esta falla en avisos de ICS (p. ej., la serie MELSEC iQ-F de Mitsubishi Electric: "MODBUS/TCP carece de autenticación adecuada," permitiendo lectura/escritura/detención no autorizadas). La propia respuesta de la Organización Modbus, Seguridad Modbus/TCP, es encapsulación TLS con certificados X.509 — estructuralmente la misma categoría de corrección que la Prueba 3 demuestra aquí, estandarizada a nivel de la organización del protocolo en lugar de la de un solo proveedor. DNP3 tiene una extensión opcional de Autenticación Segura (SAv5, estandarizada en 2012); tanto análisis independientes como relatos de implementadores la describen como raramente configurada en la práctica, citando brechas de interoperabilidad entre fabricantes de OT y una complejidad genuina del protocolo — dejando la misma exposición que la Prueba 1 demuestra para EtherNet/IP.
El punto arquitectónico, expresado con precisión para no sobrevenderse: la corrección de la Prueba 3 — TLS mutuo, identidad por dispositivo vinculada en el certificado (no solo validez de CA), revocación mediante CRL — opera en la capa de transporte, no en el protocolo de aplicación ICS. El principio es igualmente aplicable debajo de Modbus, DNP3 o un protocolo propietario; lo que cambia es el envoltorio, no la forma de la corrección. Este repositorio no ha construido ni ejecutado una PoC específica de Modbus o DNP3 — esta es una generalización arquitectónica a partir de documentación pública, sujeta a la misma clasificación de "demostrado vs. con fuente" que todo lo demás aquí, no una afirmación nueva probada.
Fuentes: Avisos ICS de CISA sobre brechas de autenticación Modbus/TCP — Industrial Cyber · Descripción general de Seguridad Modbus/TCP — Veridify · Desafíos de adopción de DNP3 SAv5/SAv6 — Step Function I/O
Un paquete de divulgación vive o muere por no mezclar estas, porque cada una tiene una corrección diferente:
La corrección demostrada aquí — vinculación de identidad por dispositivo (Prueba 3) — aborda la falla de la clave de flota.
| Afirmación | Nivel | Por qué | |
|---|---|---|---|
| El principio arquitectónico | "un secreto compartido único en una flota se ve comprometido en toda la flota por una sola fuga; la autenticación vinculada a identidad por dispositivo cierra eso" | PROBADO | demostrado con código real en ejecución incluyendo el control negativo que prueba que la verificación es necesaria, no meramente que se activa: en un endpoint estricto, el certificado genuinamente válido por CA del Dispositivo B es rechazado por identidad (Prueba 3 · caso 3), pero en un endpoint de validez-de-CA-solo, el mismo certificado es aceptado (caso 4 — el control) → "firmado válidamente por CA solo == acceso en toda la flota == Prueba 2 con ropaje TLS." La vinculación también se sostiene en sentido inverso: un servidor rogue que presenta un certificado de flota válido es rechazado por el cliente (caso 5). La Prueba 1 muestra por separado la línea base más amplia sin autenticación. |
| La implementación específica de CIP Security de Rockwell se comporta de manera idéntica | "habilitar CIP Security en hardware real de Rockwell remedia CVE-2021-22681 exactamente de esta manera" | HIPÓTESIS PRINCIPAL, con fuente no verificada | este es el lenguaje del propio aviso de Rockwell (PN1550) — "Cuando se implementa correctamente, CIP Security remedia esta vulnerabilidad... no hace uso de ninguna clave codificada" — no algo que hayamos confirmado de forma independiente contra hardware Logix real. Probamos el principio que describe su aviso, no su implementación exacta a nivel de cable. |
