CVE-2017-12233

Falha de negação de serviço na implementação do Common Industrial Protocol (CIP) do Cisco IOS: pacotes CIP malformados enviados a switches Ethernet industriais fazem o dispositivo reiniciar. O CVSS de 7.5 já reflete que não exige autenticação, mas o impacto real é restrito a equipamentos com o feature CIP habilitado — algo fora do padrão na maioria das redes corporativas, e comum apenas em ambientes de automação industrial.

A vulnerabilidade está no parser de pacotes CIP do Cisco IOS, classificada como CWE-20 (validação de entrada imprópria). O CIP é um protocolo de camada de aplicação usado em automação industrial, historicamente chamado de Control and Information Protocol, e nos switches Cisco Industrial Ethernet ele roda sobre UDP, escutando nas portas 2222 e 44818. Quando o dispositivo recebe um pacote CIP construído de forma inválida — campos fora do esperado pelo parser —, o código de tratamento falha e o processo trava, levando o IOS a recarregar.

O advisory da Cisco agrupa duas CVEs sob os mesmos bugs (CSCuz95334 e CSCvc43709): CVE-2017-12233 e CVE-2017-12234, ambas com a mesma causa raiz e mesmo efeito — parsing incorreto de pacotes CIP resultando em reload. A Cisco não detalha qual estrutura específica do pacote dispara a falha, nem publicou prova de conceito.

O vetor é estritamente IPv4/UDP: pacotes TCP, pacotes IPv6 e pacotes apenas em trânsito pelo dispositivo (não destinados a ele) não acionam a falha. Isso restringe a superfície a UDP destinado diretamente ao próprio equipamento nas portas 2222 ou 44818.

Pré-requisito central, que a nota de CVSS não deixa claro: o feature CIP precisa estar habilitado no dispositivo, e ele vem desabilitado por padrão. Um administrador pode confirmar se está ativo com "show running-config | include cip enable" — se o comando não retornar nada, o equipamento não está exposto a este vetor. Isso reduz drasticamente o universo de alvos reais para switches Cisco Industrial Ethernet configurados para automação industrial, não para roteadores/switches genéricos rodando IOS.

Com CIP habilitado, a exploração não exige autenticação nem interação do usuário (AC:L, PR:N, UI:N no vetor CVSS): basta acesso de rede para enviar pacotes UDP malformados às portas 2222 ou 44818 do dispositivo. Não há elevação de privilégio nem comprometimento de confidencialidade/integridade — o impacto é reload forçado e indisponibilidade (C:N/I:N/A:H).

A CVE está no catálogo KEV da CISA (adicionada em 2022-03-03, com prazo de mitigação em 2022-03-24), confirmando exploração ativa observada, embora nem o advisory da Cisco nem a entrada da CISA detalhem a campanha ou o ator. Não há indicação de uso em ransomware.

A Cisco declara explicitamente que não existe workaround para estas vulnerabilidades — a única correção é atualizar o Cisco IOS para uma versão corrigida. O advisory não lista aqui as versões específicas que recebem o patch; a orientação da Cisco é consultar a seção "Fixed Software" do próprio advisory (cisco-sa-20170927-cip) e usar o Cisco IOS Software Checker para o release exato em uso, já que o corte varia por trem de release dentro da faixa 12.4–15.6.

Como controle compensatório, caso a atualização não seja imediata, desabilitar o feature CIP elimina a exposição — já que o protocolo vem desligado por padrão e só afeta quem o habilitou intencionalmente para automação industrial. Onde o CIP for necessário operacionalmente, restringir acesso UDP às portas 2222 e 44818 por ACL/segmentação de rede, permitindo tráfego apenas de hosts de controle industrial confiáveis, reduz a superfície de ataque, embora não seja uma correção da falha em si.

ATM não há mitigação por configuração alternativa reconhecida pelo fornecedor além de desligar o feature — não se trata de um bug corrigível por hardening de protocolo ou filtro de payload no próprio IOS.

A própria Cisco indica o sinal mais confiável: exploração bem-sucedida causa reload do dispositivo com geração de um core file. A presença desse core file, correlacionada com reload inesperado em um switch com CIP habilitado, é o indicador prático de tentativa de exploração — a Cisco recomenda contatar o TAC para analisar o core file e confirmar se houve exploração.

Em nível de rede, tráfego UDP anômalo ou malformado destinado às portas 2222 ou 44818 do próprio dispositivo (não em trânsito) é o que deve ser monitorado; não há assinatura pública de payload divulgada pela Cisco ou por pesquisadores nas fontes consultadas, então detecção por conteúdo de pacote fica limitada a heurísticas de anomalia de protocolo.