CVE-2018-0159
Prioritize patching. It under exploitation confirmed by CISA.
Apply updates per vendor instructions.
Summary
Falha de validação de entrada (CWE-20) no processamento de pacotes IKEv1 em Cisco IOS e IOS XE que permite a um atacante remoto não autenticado forçar o reload do dispositivo, causando DoS. Afeta qualquer equipamento com ISAKMP habilitado — não só quem usa IKEv1 explicitamente, já que dispositivos configurados com IKEv2 também processam o pacote malformado e caem. Está no catálogo KEV da CISA desde março de 2022, quatro anos após a publicação original, sinal de exploração continuada em campo.
Technical detail
O bug está na lógica de validação de pacotes IKEv1 durante a negociação IKE (fase de estabelecimento de associação de segurança ISAKMP). O parser aceita pacotes IKEv1 malformados sem rejeitá-los corretamente, e o processamento subsequente desse pacote crafted leva a uma condição que derruba o processo e força o reload do dispositivo. A Cisco classifica como CWE-20 (Improper Input Validation) e identifica internamente como bug CSCuj73916.
O ponto crítico é que a superfície de ataque não se limita a quem roda VPN com IKEv1 puro. Qualquer dispositivo Cisco IOS/IOS XE com ISAKMP ativo processa esse tipo de pacote, então uma configuração feita para IKEv2 (FlexVPN, por exemplo) também fica exposta, porque a pilha aceita e tenta interpretar o pacote IKEv1 antes de decidir o que fazer com ele. Isso inclui LAN-to-LAN VPN, VPN de acesso remoto (exceto SSL VPN), DMVPN, FlexVPN e GET VPN — qualquer feature que dependa de IKE.
A superfície de rede é UDP 500 (ISAKMP), UDP 4500 (NAT-T), e também UDP 848 e 4848 (GDOI, usado em GET VPN), em IPv4 ou IPv6. O atacante não precisa completar uma negociação IKE legítima nem possuir credenciais — só precisa conseguir enviar o pacote crafted para uma dessas portas durante o processo de negociação.
Cisco IOS XR e NX-OS foram confirmados como não afetados pelo fornecedor; a falha é específica da pilha ISAKMP usada em IOS e IOS XE clássicos.
How it’s exploited
O vetor é de rede pura: um pacote IKEv1 malformado enviado para uma das portas UDP de IKE (500, 848, 4500 ou 4848) durante uma tentativa de negociação. Não há necessidade de autenticação, de sessão prévia válida, nem de conhecimento de segredos compartilhados/PSK — o atacante só precisa alcançar a porta na rede, o que normalmente significa exposição direta da interface WAN ou de trânsito onde o IKE está habilitado. Isso torna a complexidade de exploração baixa (AC:L no vetor CVSS) e explica o EPSS relativamente moderado, mas persistente ao longo dos anos.
O impacto final é reload do equipamento — interrupção total do plano de dados e controle enquanto o dispositivo reinicia, sem indicação de comprometimento de confidencialidade ou integridade (C:N/I:N no vetor). Em ambientes com VPN site-to-site ou concentradores de acesso remoto, isso derruba túneis ativos e pode ser repetido continuamente para negação de serviço sustentada.
A entrada no catálogo KEV da CISA (adicionada em março de 2022) confirma exploração ativa observada, embora a CISA não detalhe campanhas específicas nem associação a ransomware ("Known To Be Used in Ransomware Campaigns: Unknown"). O prazo de correção definido pela CISA para agências federais foi 17/03/2022 — referência útil de urgência mesmo para quem não é órgão federal americano.
Versions
How to protect
O advisory da Cisco afirma explicitamente que não existe workaround para esta vulnerabilidade — a única remediação é atualizar o software para uma versão corrigida. A seção 'Fixed Software' do advisory da Cisco (cisco-sa-20180328-ike-dos) lista as versões específicas por linha de IOS/IOS XE via o Cisco Software Checker; como essa tabela não constava no material consultado aqui, não reproduzimos números de versão — confira o advisory diretamente antes de decidir que uma versão está corrigida.
Como não há mitigação de configuração, o controle compensatório realista para quem não pode atualizar imediatamente é reduzir a exposição da porta IKE: restringir origem de tráfego UDP 500/848/4500/4848 via ACL a peers VPN conhecidos, e não expor essas portas a qualquer origem na Internet. Isso reduz superfície de ataque mas não elimina o risco de um peer autorizado (ou de alguém que spoofe o IP de um peer, dependendo do desenho) enviar o pacote malformado.
Desabilitar ISAKMP em interfaces onde IKE não é necessário elimina a exposição naquele ponto, mas obviamente derruba qualquer VPN dependente de IKE ali — não é mitigação gratuita, é troca de funcionalidade por segurança. Não existe flag ou comando pontual documentado pela Cisco que neutralize o bug sem atualizar o software.
How to detect
Um exploit bem-sucedido causa o reload do dispositivo e gera um arquivo crashinfo local. A Cisco recomenda contatar o TAC para analisar esse crashinfo e determinar se o reload foi causado por exploração desta falha — não há assinatura de tráfego pública documentada pela Cisco para detectar as tentativas antes do crash. Na prática, o sinal mais acessível para SOC é reload inesperado e não programado de roteador/switch com ISAKMP ativo, correlacionado com tráfego UDP anômalo nas portas 500/848/4500/4848 pouco antes do evento — mas sem uma assinatura IDS oficial publicada, a confirmação depende de análise do crashinfo com suporte do fornecedor.