pcrosby-1990/cip-security-pocProva de conceito que reproduz a falha de chave hardcoded da CVE-2021-22681 e valida uma correção de TLS mútuo/CRL por dispositivo sobre EtherNet/IP simulado, com mapeamento para IEC 62443-4-2.
Seis scripts executáveis — tráfego real de protocolo EtherNet/IP (Teste 1), mecânica real de TLS/PKI (Testes 3–6) — zero software ou licenciamento Rockwell em qualquer ponto da cadeia. Construído para testar uma afirmação antes de documentá-la, não para defendê-la por fé.
Proveniência: construído em 2026-07-31, em paralelo a uma investigação sobre a WWTF de Braham, MN — uma das quatro concessionárias divulgadas publicamente no incidente coordenado do setor de água de Minnesota de 26–27 de julho de 2026. O contexto desse incidente está no advisory CISA AA26-097A (conjunto FBI/CISA/NSA/EPA/DOE/USCYBERCOM/Treasury; emitido em 2026-04-07, expandido em 2026-07-22), que cobre a campanha contínua CyberAv3ngers afiliada ao IRGC. Ressalva de atribuição, mantida com precisão: nenhuma agência atribuiu formalmente o incidente de Minnesota especificamente a esse grupo — apenas a campanha mais ampla e contínua o é. Esta pasta é o lado da correção técnica, mantida separada da investigação do incidente de propósito.
O Rockwell PSIRT ([email protected]) e o RA Secure Mail ([email protected]) foram contatados em 2026-07-31, antes de este repositório e documento irem ao ar (~30 minutos antes, pelos carimbos de data/hora dos arquivos). A equipe de arquitetura de segurança da Rockwell revisou o repositório e respondeu em 2026-08-03. Citado diretamente, não parafraseado para uma afirmação mais forte do que a que fizeram:
A Rockwell Automation não endossa nem valida sua interpretação, seu mapeamento IEC 62443-4-2, ou quaisquer conclusões tiradas da prova de conceito. Por favor, não represente o trabalho como revisado, aprovado ou endossado pela Rockwell Automation... os scripts demonstram princípios gerais de criptografia e autenticação, em vez de algo específico do CIP Security ou do CVE-2021-22681.
Este trabalho não foi revisado, aprovado ou endossado pela Rockwell Automation, ponto final. Sua
caracterização técnica — princípios gerais, não específicos do CIP Security — é a mesma distinção
que a tabela "O limite rígido" abaixo já traça sobre as afirmações deste próprio repositório; a revisão deles a confirma
de forma independente, em vez de contestá-la. Para concessionárias em hardware que não alcança o CIP Security,
a Rockwell apontou para seu próprio Guia de Design e Implementação Converged Plantwide Ethernet (CPwE)
(citado em PHASED_ROLLOUT.md Fase 1) — o recurso existente do fornecedor para o qual este projeto tenta direcionar
as pessoas, em vez de duplicá-lo.
A descoberta do Teste 1 — sem autenticação no estado padrão do protocolo — não é exclusiva do EtherNet/IP. Modbus TCP, ainda um dos protocolos mais amplamente implantados em sistemas de controle de água/esgoto, não tem nenhum conceito de autenticação na especificação do protocolo; ele data de comunicações seriais de 1979 e nunca foi projetado com segurança em mente. A CISA nomeou repetidamente exatamente essa falha em advisories de ICS (por exemplo, a série MELSEC iQ-F da Mitsubishi Electric: "MODBUS/TCP carece de autenticação adequada," permitindo leitura/escrita/parada não autorizadas). A resposta da própria Modbus Organization, Modbus/TCP Security, é encapsulamento TLS com certificados X.509 — estruturalmente a mesma categoria de correção que o Teste 3 demonstra aqui, padronizada no nível da organização do protocolo em vez de um único fornecedor. DNP3 tem uma extensão opcional de Secure Authentication (SAv5, padronizada em 2012); análises independentes e relatos de implementadores descrevem-na como raramente configurada na prática, citando lacunas de interoperabilidade entre fabricantes de OT e complexidade genuína do protocolo — deixando a mesma exposição que o Teste 1 demonstra para o EtherNet/IP.
O ponto arquitetural, declarado com precisão para não ser supervendido: a correção do Teste 3 — TLS mútuo, identidade por dispositivo vinculada no certificado (não apenas validade da CA), revogação via CRL — opera na camada de transporte, não no protocolo de aplicação ICS. O princípio é igualmente aplicável sob Modbus, DNP3 ou um protocolo proprietário; o que muda é o invólucro, não a forma da correção. Este repositório não construiu nem executou um PoC específico de Modbus ou DNP3 — esta é uma generalização arquitetural a partir de documentação pública, mantida no mesmo nível de "demonstrado vs. referenciado" que tudo o mais aqui, não uma nova afirmação testada.
Fontes: Advisories de ICS da CISA sobre lacunas de autenticação Modbus/TCP — Industrial Cyber · Visão geral do Modbus/TCP Security — Veridify · Desafios de adoção do DNP3 SAv5/SAv6 — Step Function I/O
Um pacote de divulgação vive ou morre por não misturar estas coisas, porque cada uma tem uma correção diferente:
A correção demonstrada aqui — vinculação de identidade por dispositivo (Teste 3) — aborda a falha da chave de frota.
| Afirmação | Nível | Por quê | |
|---|---|---|---|
| O princípio arquitetural | "um único segredo compartilhado em uma frota é comprometido em toda a frota por um vazamento; autenticação vinculada à identidade por dispositivo fecha isso" | PROVADO | demonstrado com código real em execução incluindo o controle negativo que prova que a verificação é necessária, não apenas que ela dispara: em um endpoint estrito, o certificado genuinamente válido pela CA do Dispositivo B é rejeitado por identidade (Teste 3 · caso 3), mas em um endpoint somente de validade-CA o mesmo certificado é aceito (caso 4 — o controle) → "somente assinado validamente pela CA == acesso em toda a frota == Teste 2 em roupagem TLS." O vínculo também se sustenta no sentido inverso: um servidor rogue apresentando um certificado de frota válido é rejeitado pelo cliente (caso 5). O Teste 1 mostra separadamente a linha de base mais ampla sem autenticação. |
| A implementação específica do CIP Security da Rockwell se comporta de forma idêntica | "habilitar o CIP Security em hardware real da Rockwell remedia o CVE-2021-22681 exatamente desta forma" | LÍDER, referenciado não verificado | esta é a linguagem do próprio advisory da Rockwell (PN1550) — "Quando implantado adequadamente, o CIP Security remedia esta vulnerabilidade... não faz uso de nenhuma chave fixa" — não algo que confirmamos de forma independente contra hardware Logix real. Testamos o princípio que o advisory deles descreve, não sua implementação exata no nível de wire. |
Não confunda as duas linhas. O princípio está provado. A implementação específica do fornecedor dele é crível (é a intenção de design declarada por eles) mas não testada por nós contra equipamento real.
