CVE-2017-12234

Falha de negação de serviço no parsing de pacotes CIP (Common Industrial Protocol) em Cisco IOS Software. Um atacante remoto não autenticado pode enviar pacotes CIP malformados e forçar o reload do dispositivo. O impacto real é limitado: o CIP vem desabilitado por padrão e só existe em equipamentos que o habilitam explicitamente, tipicamente switches Ethernet industriais.

A vulnerabilidade está classificada como CWE-20 (validação inadequada de entrada) na implementação do CIP dentro do Cisco IOS. O CIP é o protocolo usado em automação industrial (originalmente chamado Control and Information Protocol), disponível principalmente nos switches Cisco Industrial Ethernet. O parsing de pacotes CIP recebidos pelo dispositivo não trata corretamente determinados campos malformados, o que leva a uma condição de erro não tratada e força o processo a travar o sistema, causando reload.

O advisory do fornecedor agrupa esta CVE com a CVE-2017-12233 sob o mesmo Bug ID relacionado (CSCuz95334 e CSCvc43709), como duas falhas distintas dentro do mesmo subsistema de parsing CIP. A Cisco não detalhou publicamente o campo exato ou a estrutura de pacote que dispara o crash — não há write-up técnico independente disponível nas fontes consultadas que descreva o offset ou o tipo exato de malformação explorada.

O atacante controla o conteúdo do pacote CIP enviado, mas o vetor de exploração está restrito a um tipo de tráfego muito específico: pacotes IPv4 destinados às portas UDP 2222 ou 44818. Pacotes TCP, pacotes IPv6 e pacotes que apenas atravessam o dispositivo (sem serem destinados a ele) não acionam a falha, segundo o próprio fornecedor.

Pré-condição essencial, e é o ponto que a manchete e o CVSS 7.5 escondem: o recurso CIP vem desabilitado por padrão no Cisco IOS. Só está exposto em dispositivos onde um administrador habilitou explicitamente o CIP (comando 'cip enable' visível em 'show running-config | include cip enable') — na prática, switches Cisco Industrial Ethernet usados em ambientes de automação industrial/OT. Em roteadores e switches genéricos sem esse recurso ativo, a superfície de ataque simplesmente não existe.

Com o CIP ativo, a exploração não exige autenticação nem qualquer sessão prévia: basta acesso de rede às portas UDP 2222 ou 44818 do dispositivo alvo com pacotes IPv4. O atacante envia um pacote CIP craftado e o dispositivo processa a entrada malformada, gera um core file e reinicia — efeito de negação de serviço puro, sem execução de código nem exfiltração de dados (CVSS reflete isso: C:N/I:N/A:H).

A CVE está no catálogo KEV da CISA, o que confirma exploração ativa registrada, com data de inclusão em 2022-03-03 e prazo de correção definido pela CISA para 2022-03-24 — bem depois da publicação original (2017), indicando que o interesse ofensivo persistiu ou foi identificado tardiamente em ambientes industriais legados que raramente são atualizados.

A Cisco não oferece workaround: o próprio advisory declara 'There are no workarounds that address these vulnerabilities'. A única correção real é atualizar para uma versão fixa do Cisco IOS Software; o advisory lista essas versões em uma tabela de 'Fixed Software' que não constava no conteúdo capturado desta pesquisa — antes de aplicar qualquer atualização, consulte diretamente a seção 'Fixed Software' do advisory oficial (cisco-sa-20170927-cip) para o Bug ID CSCvc43709 e a versão exata correspondente à sua imagem/plataforma.

Como não há workaround suportado pelo fornecedor, o controle compensatório prático para quem não pode atualizar imediatamente é reduzir a exposição: desabilitar o CIP se ele não for necessário (é a mitigação mais simples e eficaz, já que o recurso é opcional), ou, quando o CIP for indispensável, restringir por ACL o acesso às portas UDP 2222 e 44818 apenas a hosts/redes de automação confiáveis, isolando esse tráfego de redes não confiáveis.

Não funciona como mitigação: achar que por rodar apenas TCP ou IPv6 já está protegido sem verificar — o vetor é especificamente IPv4/UDP, então basta bloquear/filtrar esse tráfego específico nas portas citadas para reduzir drasticamente a superfície, mesmo sem atualizar.

O próprio fornecedor indica o sinal mais confiável: exploração bem-sucedida causa reload do dispositivo com geração de core file. Um reload inesperado em um switch com CIP habilitado, acompanhado de core dump, é o indicador primário — a Cisco recomenda contatar o TAC para analisar esse core file e confirmar se houve exploração (não apenas crash acidental).

Em nível de rede, monitorar tráfego IPv4 UDP destinado às portas 2222 e 44818 endereçado a dispositivos com CIP ativo é o ponto de instrumentação possível, especialmente picos de tráfego anômalo ou pacotes malformados nessas portas provenientes de fontes não esperadas na rede de automação. Não há assinatura de payload documentada publicamente nas fontes consultadas, então a detecção depende mais de monitorar disponibilidade/reload do dispositivo do que de inspecionar o conteúdo do pacote.