CVE-2017-12237

Falha de negação de serviço no módulo IKEv2 do Cisco IOS e IOS XE: um atacante não autenticado envia pacotes IKEv2 malformados a um dispositivo com ISAKMP habilitado e provoca alto consumo de CPU, mensagens de traceback ou reload. Importa porque a condição de exposição é banal — não é preciso ter VPN configurada, basta ISAKMP estar ativo, o que ocorre por padrão em muitos roteadores e switches Cisco que suportam qualquer recurso baseado em IKE (LAN-to-LAN, acesso remoto, DMVPN, FlexVPN).

A vulnerabilidade é classificada pela Cisco como CWE-399 (gerenciamento inadequado de recursos). O IKEv2 é usado pelo IPsec para negociar atributos criptográficos (algoritmo, modo, chaves) antes de estabelecer uma sessão. O advisory afirma que o problema está em 'como um dispositivo afetado processa determinados pacotes IKEv2' — a Cisco não detalha publicamente o parser ou a estrutura de campo exata que causa o esgotamento de recursos, apenas que pacotes IKEv2 específicos, ao serem processados, geram consumo excessivo de CPU ou condições de erro que levam a traceback ou reload.

O ponto crítico da superfície de exposição: qualquer dispositivo Cisco IOS ou IOS XE com ISAKMP habilitado processa pacotes IKEv2 nas portas UDP 500, 848 (GDOI) e 4500 (NAT-T), independentemente de o administrador ter configurado algum recurso específico de IKEv2. Isso significa que dispositivos que só usam IKEv1 para uma VPN legada, por exemplo, ainda podem estar processando (e sendo vulneráveis a) pacotes IKEv2 recebidos por essas mesmas portas.

O CVSS informado na entrada (7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) difere do publicado pela própria Cisco no advisory original (8.6, com S:C — Scope Changed), o que reflete uma reavaliação de escopo entre versões do CVSS 3.0/3.1 usadas por fornecedor e NVD. Em ambos os casos o impacto é exclusivamente em disponibilidade (A:H), sem comprometimento de confidencialidade ou integridade.

O vetor é rede, sem autenticação e sem interação do usuário: o atacante envia pacotes IKEv2 especialmente formados para a porta UDP correspondente (500, 848 ou 4500) de um dispositivo exposto. Não há pré-requisito de configuração de VPN — a única condição é que o ISAKMP esteja habilitado no dispositivo, o que a própria Cisco descreve como habilitado por padrão em qualquer plataforma que suporte os protocolos que dependem de IKE.

O resultado bem-sucedido é DoS: alta utilização de CPU, mensagens de traceback no console/log, ou reload completo do equipamento. Não há elevação de privilégio nem exfiltração de dados — o dano é interrupção de serviço, que em equipamentos de borda ou concentradores de VPN pode significar queda de conectividade para múltiplos sites ou usuários remotos.

A CVE está no catálogo KEV da CISA desde 03/03/2022 (prazo de correção definido para 24/03/2022), confirmando exploração ativa observada, embora a CISA não classifique a falha como associada a campanhas de ransomware conhecidas ('Unknown' no campo correspondente). Não há detalhes públicos sobre a ferramenta ou ator específico usado para exploração massiva.

A correção definitiva é atualizar para uma versão de Cisco IOS ou IOS XE Software corrigida. O advisory da Cisco (cisco-sa-20170927-ike) contém a lista completa de versões corrigidas por trem de release na seção 'Fixed Software', que deve ser consultada diretamente — o Cisco Software Checker permite informar a versão em uso e a lista de recursos/features configurados para obter a versão-alvo exata; não há um número único de versão 'segura' porque isso varia por trem (15.x, 3.x, 16.x, etc.) e o conteúdo lido não trouxe essa tabela completa.

A Cisco indica que existe um workaround, mas o mecanismo específico não está descrito no material disponível aqui — antes de aplicá-lo, consultar o advisory oficial diretamente. Como controle compensatório imediato, em dispositivos onde IKE não é necessário, desabilitar ISAKMP remove a superfície de ataque; onde IKE é necessário, restringir origem dos pacotes UDP 500/848/4500 via ACL para os peers legítimos reduz drasticamente a exposição a atacantes não autenticados na internet.

Não funciona como mitigação: acreditar que 'não uso IKEv2, só IKEv1' protege o dispositivo — a própria Cisco esclarece que o simples fato de ISAKMP estar ativo processa pacotes IKEv2 e expõe o equipamento, independentemente de qual versão do protocolo está configurada para uso operacional.

Para saber se um dispositivo está exposto (não se foi atacado), verificar com 'show ip sockets' ou 'show udp' se as portas UDP 500, 848 ou 4500 estão em estado de escuta — isso indica processamento de pacotes IKE e, portanto, superfície vulnerável, mesmo sem configuração explícita de recursos IKEv2. Para indícios de tentativa de exploração, monitorar logs e console para mensagens de traceback, picos anômalos de CPU coincidindo com tráfego UDP nessas portas, e reloads inesperados do dispositivo; não há assinatura de pacote ou payload documentada publicamente pela Cisco, então não existe regra de detecção de rede confiável e específica para esta CVE além de monitorar volume/anomalias de tráfego IKEv2 dirigido ao dispositivo.