cip-security-poc — provando o princípio da correção por trás do CVE-2021-22681 (não apenas sua falha)

Quatro scripts executáveis. Tráfego real de protocolo EtherNet/IP, criptografia real, zero software Rockwell ou licenciamento 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 31/07/2026, em paralelo a uma investigação sobre o Braham, MN WWTF — uma das quatro concessionárias divulgadas publicamente no incidente coordenado no setor de água de Minnesota de 26 a 27 de julho de 2026. O contexto desse incidente está no advisory da CISA AA26-097A (emissão conjunta FBI/CISA/NSA/EPA/DOE/USCYBERCOM/Treasury; emitido em 07/04/2026, expandido em 22/07/2026), que cobre a campanha contínua CyberAv3ngers associada ao IRGC. Ressalva de atribuição, mantida precisamente: nenhuma agência atribuiu formalmente o incidente de Minnesota especificamente a esse grupo — apenas a campanha mais ampla em curso o foi. Esta pasta é o lado da correção técnica, mantida separada da investigação do incidente de propósito.

Três falhas distintas — mantenha-as separadas

Um pacote de divulgação vive ou morre por não misturar essas coisas, porque cada uma tem uma correção diferente:

• Sem / ausência de autenticação (Teste 1) — um dispositivo exposto sem nenhuma camada de credenciais. A base ampla em que a campanha CyberAv3ngers se apoiou (muitas vítimas eram alcançáveis com credenciais ausentes ou padrão).
• Uma chave hardcoded / compartilhada em toda uma frota (a forma específica do CVE-2021-22681, modelada pelo Teste 2) — extraia a única chave uma vez, comprometa a frota inteira. Este é o CVE real.
• Credenciais padrão — credenciais de fábrica nunca alteradas. Não modelado aqui; nomeado para não ser confundido com os dois acima.

A correção demonstrada aqui — vínculo de identidade por dispositivo (Teste 3) — trata da falha de chave de frota.

O limite rígido (leia isto primeiro)

Não confunda as duas linhas. O princípio está comprovado. 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.

Ferramentas

test1_baseline_vulnerable.py — a linha de base sem autenticação, ao vivo

Inicia um simulador real de PLC EtherNet/IP (cpppo, emulando um Allen-Bradley ControlLogix) e lê + escreve uma tag de controle com zero credenciais. (Escopo: esta é a linha de base sem autenticação ampla em que a campanha se apoiou — não o mecanismo específico de chave hardcoded do CVE-2021-22681. Mantida distinta de propósito; veja "Três falhas distintas" acima.)

python test1_baseline_vulnerable.py

test2_shared_secret_fails.py — a forma da falha de chave de frota (ponte narrativa, não um teste)

Dois endpoints guardam uma chave estática; uma credencial do Dispositivo A abre o Dispositivo B inalterado — o análogo estrutural mais próximo da falha de uma-chave-para-todos do CVE-2021-22681. Mas é tautológico: ambos os manipuladores são construídos para aceitar essa chave, então não há caminho de execução em que ela possa falhar. Isso não demonstra nada que o código não defina como existente. Mantido como a ponte narrativa do Teste 1 ao Teste 3; não carrega nenhum peso probatório e deliberadamente não é um pilar de prova.

python test2_shared_secret_fails.py

test3_mutual_tls_fix.py — a correção, com seu controle negativo e ambas as direções

CA real, dois certificados de dispositivo individualmente únicos — identidade vinculada no SubjectAlternativeName, não no CommonName obsoleto. Cinco casos, todos executados:

• [1] Certificado do próprio Dispositivo A → CONCEDIDO · [2] sem certificado → rejeitado no handshake TLS · [3] Certificado válido pela CA do Dispositivo B → NEGADO por identidade (endpoint estrito).
• [4] O CONTROLE — o mesmo certificado do Dispositivo B contra um endpoint que verifica apenas a validade da CA → CONCEDIDO. É isso que dá significado ao [3]: sem a verificação de identidade, qualquer certificado de frota abre qualquer dispositivo (== Teste 2, em roupagem de TLS).
• [5] REVERSO — um servidor malicioso apresentando o certificado do Dispositivo B é rejeitado por um cliente que vincula device-a (check_hostname contra um SAN real). Mútuo — ambas as extremidades vinculam identidade.

python test3_mutual_tls_fix.py

test4_revocation.py — a perna do ciclo de vida: revogação

Uma CRL real assinada por CA. Uma credencial de cliente (engineer-1) é concedida; então seu serial é adicionado à CRL, e a mesma credencial ainda válida, não expirada e assinada pela CA é negada — o conteúdo empírico da cláusula de revogação CR 1.8 / 1.9. Unicidade (Teste 3) ≠ revogabilidade; isso mostra que uma credencial pode ser retirada.

python test4_revocation.py

Limites de escopo (o que NÃO é afirmado)

• Revogação — agora demonstrada (test4_revocation.py); rotação — ainda não. A unicidade por dispositivo (Teste 3) não é o mesmo que revogabilidade; o Teste 4 fecha essa lacuna — uma credencial ainda válida, não expirada e assinada pela CA é concedida antes da revogação e negada depois, somente porque a CRL assinada pela CA agora lista seu serial. Rotação (reemitir uma credencial substituta e aposentar a antiga) é intimamente relacionada e habilitada pela mesma PKI, mas não é demonstrada separadamente aqui — portanto, "vínculo de identidade por dispositivo" ainda não deve se expandir silenciosamente para "rotação resolvida."
• Tempo constante (baixa severidade, nomeado por higiene). As comparações de strings de identidade (presented == KEY, identity in SAN) não são de tempo constante. Não explorável aqui — os valores comparados são strings de identidade quase públicas e o TLS já fez a autenticação criptográfica real antes de a comparação ser executada —, mas sinalizado porque o padrão é copiado para lugares onde isso importa.

Configuração

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

Próximos passos (resta um item real, além de dois pequenos opcionais)

• Mapeamento 62443-4-2 SL 2 — RASCUNHADO → 62443-4-2_SL2_MAPPING.md (CR 1.2 / 1.8 / 1.9 / 1.14 / 3.1, honestamente classificados, cada lacuna nomeada; CR 1.2, CR 1.9 e a parte de emissão/validação/revogação do CR 1.8 agora estão demonstrados). Antes do PSIRT ([email protected] / [email protected]): verificar o texto normativo de cada CR contra uma cópia adquirida da IEC 62443-4-2:2019.
• Implantação em fases — RASCUNHADO → PHASED_ROLLOUT.md (Fase 0 estancar o sangramento · 1 segmentar · 2 controles compensatórios · 3 CIP Security/PKI, conforme o hardware permitir · 4 operar). Dimensionado para uma pequena concessionária; honesto quanto ao CIP Security ser limitado por hardware, portanto as Fases 0–2 carregam a redução de risco de qualquer forma.
• Ainda em aberto — o item restante real: sequenciamento da divulgação responsável. Contato com o PSIRT primeiro, artigo público / LinkedIn depois, para que a cadeia de proveniência seja documentada em ordem. Ainda não redigido: o próprio e-mail ao PSIRT.
• Dois pequenos itens técnicos, nomeados e não escondidos (conforme o resumo do próprio documento de mapeamento): um teste de rotação (reemitir + aposentar) para mover o CR 1.8 de "habilitado" para totalmente demonstrado, e um teste de injeção de adulteração para mover o CR 3.1 de "por construção" para demonstrado. Nenhum deles é essencial para a afirmação central; ambos são pequenos se forem assumidos.

Citações — recuperadas, não lembradas (e recupere novamente antes da submissão)

Cada identificador externo aqui foi obtido de uma fonte viva em 31/07/2026, não lembrado do treinamento: AA26-097A (multifonte, incl. WaterISAC / Tenable / SecurityWeek), Braham como uma das quatro vítimas divulgadas, CyberAv3ngers/IRGC, PN1550 confirmou o advisory real da Rockwell com sua citação da Linha 2 verificada verbatim ("Quando implantado corretamente, o CIP Security remedia essa vulnerabilidade"

• "não faz uso de nenhuma chave hardcoded"), "não pode ser mitigado com um patch" verbatim, CVSS 10.0 / CRÍTICO (v3.1), rastreamento da CISA ICSA-21-056-03, e 62443-4-2 CR 1.8 (PKI) + CR 3.1 (integridade de comunicação) confirmados exatamente. Disciplina para o pacote: recuperar novamente cada identificador de fontes primárias no momento da submissão. Advisories são renumerados, expandidos e substituídos — AA26-097A já mostra uma expansão —, portanto "verificado em 31/07/2026" não é "verificado no envio." O mapeamento formal completo CR por CR do 62443-4-2 está agora escrito (62443-4-2_SL2_MAPPING.md) — o que resta é recuperar o texto normativo citado contra uma cópia adquirida do padrão antes da submissão, não escrever o mapeamento.

l0gic — Patrick Crosby · 31/07/2026.

Registro de endurecimento: O Teste 3 foi reforçado para incluir o controle negativo (caso 4, provando necessidade, não apenas que dispara), o caso de direção reversa (caso 5, vínculo mútuo) e identidade baseada em SAN (não CN), e depois reverificado ao executar novamente todos os cinco casos; o Teste 4 (revogação por CRL) foi adicionado. As legendas dos Testes 1/2 foram ajustadas para manter as três classes de falha distintas; o Teste 2 foi rebaixado de "teste" para ponte narrativa; os limites de escopo de revogação e tempo constante foram adicionados. A cadeia de citações foi recuperada de fontes primárias e carimbada para nova recuperação no momento da submissão.