CVE-2016-6415

Falha de disclosure de informação (CWE-200) na implementação server-side do IKEv1 em Cisco IOS, IOS XE, IOS XR e PIX: um pacote de negociação de SA malformado faz o dispositivo devolver trechos de memória do processo, sem autenticação. É a vulnerabilidade por trás do BENIGNCERTAIN, ferramenta vazada em 2016 pelos Shadow Brokers e associada a arsenal de exploração de firewalls Cisco PIX. Está no catálogo KEV da CISA com exploração confirmada, apesar de a CVE ter oito anos — o que reflete o uso continuado de PIX e versões antigas de IOS em produção, não uma técnica nova.

O bug está no código de processamento de pacotes IKEv1 que trata requisições de negociação de Security Association (fase 1 do IKE). O parser não valida corretamente certas condições ao montar a resposta a um pacote de negociação, e o conteúdo devolvido ao remetente inclui bytes adjacentes de memória do processo em vez de apenas os dados esperados do protocolo — um vazamento de memória clássico, não um buffer overflow com corrupção. A Cisco descreve como 'insufficient condition checks' na parte do código que lida com pacotes de negociação IKEv1 (Bug IDs CSCvb29204 e CSCvb36055).

O atacante controla o conteúdo do pacote IKEv1 enviado ao serviço, mas não controla diretamente qual região de memória é exposta na resposta — o vazamento depende do estado interno do processo no momento da negociação. Isso é consistente com o padrão de exploits tipo 'heartbleed', onde repetição da requisição ao longo do tempo permite raspar diferentes janelas de memória e, em cenários favoráveis, reconstruir material sensível como chaves pré-compartilhadas (PSK) ou fragmentos de configuração.

Um detalhe crítico da superfície de ataque: em Cisco IOS e IOS XE, configurar IKEv2 habilita automaticamente o IKEv1 no dispositivo, mesmo que o administrador só pretenda usar IKEv2. Isso significa que ambientes que acreditam ter migrado para IKEv2 e desligado IKEv1 continuam expostos, porque o subsistema IKEv1 permanece ativo e capaz de processar o pacote malicioso.

Vetor é rede: um único pacote UDP IKEv1 malformado enviado à porta de negociação (tipicamente 500 ou 4500, dependendo de NAT-T; IOS/IOS XR também usam 848/4848 para outras variantes de IKE) contra um dispositivo com IKE habilitado. Não exige autenticação, credenciais ou sessão prévia — o único pré-requisito real é que o dispositivo esteja configurado para aceitar negociações IKEv1 (VPN LAN-to-LAN, VPN de acesso remoto não-SSL, DMVPN ou GDOI, conforme a Cisco lista no advisory).

O resultado da exploração é vazamento de memória do processo IKE, que pode conter fragmentos de configuração, material criptográfico ou outros dados residentes na região exposta — não há confirmação nem do fornecedor nem de pesquisas públicas de que o atacante controle precisamente qual segredo é extraído a cada tentativa; a técnica é de raspagem incremental, não de leitura arbitrária dirigida.

A entrada no catálogo KEV da CISA (adicionada em 2023, com prazo de correção em 2023-06-09, bem depois da publicação original em 2016) indica exploração ativa confirmada anos após a divulgação — reforçando que o risco prático hoje está concentrado em dispositivos legados (PIX fora de suporte desde 2009, IOS/IOS XR antigos) que nunca foram atualizados.

A Cisco declara explicitamente no advisory que não há workaround: 'No workarounds available'. A única correção real é atualizar para uma versão corrigida do IOS, IOS XE ou IOS XR — a Cisco recomenda usar o Cisco IOS Software Checker para identificar, a partir da release atual, a versão 'First Fixed' aplicável, já que os fixes foram distribuídos por trem de release e não há um único número de versão universal. Para IOS XR, releases 5.3.x e posteriores não são afetados. Para PIX, apenas a versão 7.0+ é confirmada como não vulnerável — mas como o PIX está fora de suporte desde 2009, não existe patch a aplicar; a única mitigação real nesse caso é substituição do equipamento.

Como controle compensatório quando a atualização não é imediata, restringir por ACL o acesso às portas UDP 500, 4500, 848 e 4848 a apenas os peers VPN legítimos reduz a superfície de exposição, mas não elimina o risco de um peer autorizado (ou de alguém que spoofa o endereço de um peer autorizado, em cenários sem proteção anti-spoofing) enviar o pacote malformado. Não conte com desabilitar apenas IKEv2 como mitigação: configurar IKEv2 liga o IKEv1 automaticamente, então é preciso confirmar que o IKEv1 está de fato desativado ou removido da configuração, não apenas que IKEv2 é o protocolo 'principal'.

Verificar se o dispositivo tem as portas UDP 500, 4500, 848 ou 4848 abertas (via 'show ip sockets' ou 'show udp' no IOS) indica que o subsistema IKE está ativo e processando pacotes — logo, potencialmente exposto, independente de o administrador acreditar que só usa IKEv2. As fontes consultadas não descrevem uma assinatura de tráfego ou padrão de log confiável para distinguir uma tentativa de exploração de uma negociação IKEv1 legítima malformada por erro; não há indicador público de comprometimento específico para essa CVE além da presença de ferramentas como BENIGNCERTAIN em tráfego capturado, o que exige inspeção profunda de pacote IKE e não é trivial de sinalizar com regras genéricas de IDS.