VPN na mira: falhas no Cisco ASA/FTD e no IKE do Windows

Duas falhas, uma semana

Cisco ASA e FTD: a VPN SSL derruba o firewall

Segundo a Cisco, a falha está no tratamento de erros quando o serviço de VPN SSL de acesso remoto processa requisições HTTP. Um atacante sem autenticação envia uma requisição forjada e o equipamento reinicia. Só são afetados equipamentos com configurações específicas de VPN de acesso remoto, como VPN SSL e acesso remoto IKEv2 com serviços de cliente. O FMC não é afetado.

A Cisco publicou o aviso em 11 de agosto de 2026, informou que soube de exploração em agosto e que não há contorno. A recomendação é atualizar para uma versão corrigida, listada no aviso para cada ramo.

Um reinício de firewall parece "só" uma queda. Mas o firewall é também a borda da rede: durante o reinício caem a VPN, a navegação e os serviços publicados. Um atacante que repete a requisição mantém o equipamento num ciclo de reinícios. E, num par em alta disponibilidade, o membro que assume depois do reinício passa a responder no mesmo endereço e pode ser derrubado do mesmo jeito.

Windows: o IKE que responde na porta UDP 500

A falha da Microsoft é um double free (memória liberada duas vezes) no serviço IKEEXT, que negocia as chaves do IPsec. Segundo a Microsoft, ela é alcançável pela porta UDP 500 em máquinas configuradas como respondedoras IKEv2, como servidores RRAS de VPN, DirectAccess e infraestrutura de Always On VPN. O serviço roda com a conta LocalSystem, o que dá privilégio alto a quem explora. Máquinas sem política de respondedor IKEv2 não são vulneráveis, mesmo com o serviço iniciado.

A correção saiu nas atualizações de segurança de 14 de abril de 2026. A entrada no catálogo da CISA em 18 de agosto de 2026 mostra que, 126 dias depois, ainda havia servidores sem a correção sendo atacados.

Reduzir quem fala com o serviço de VPN

Uma VPN de acesso remoto precisa aceitar conexões de qualquer lugar, porque o usuário pode estar em qualquer rede. Mas muitas VPNs não são de acesso remoto: são túneis entre a empresa e parceiros, filiais ou provedores de nuvem, com IPs de origem conhecidos. Nesses casos, filtrar a origem tira o serviço do alcance do resto da internet.

Exemplo: um parceiro informou que os túneis dele saem da faixa 198.51.100.20 a 198.51.100.59 (40 endereços, num bloco de documentação). Uma faixa assim não vira um único bloco CIDR, mas vira poucos blocos alinhados:

São 5 linhas de ACL que liberam UDP 500 e UDP 4500 (IKE e NAT-T) só para essa origem, e um bloqueio para o resto. A ferramenta faixa de IP para CIDR faz essa decomposição para a faixa que o seu parceiro informar.

Para o acesso remoto de usuários, onde não dá para filtrar a origem, as medidas são outras:

• separe os serviços: não use o mesmo equipamento para VPN de acesso remoto e para publicar outros serviços, quando puder;
• desligue no firewall os serviços de VPN que não usa (por exemplo, a VPN SSL, se todos os clientes usam IPsec);
• monitore reinícios inesperados e picos de requisições na porta TCP 443 do concentrador;
• mantenha um caminho de gerência fora de banda, para não perder o acesso ao firewall se ele entrar em ciclo de reinício.

A conta do atraso

O intervalo entre a correção e a exploração confirmada é o que a equipe tinha para agir. No caso do Windows:

Para servidores que respondem a IKEv2 na internet, um ciclo de atualização mensal teria aplicado a correção em maio. Se esses servidores ficaram fora do ciclo (é comum em servidores de VPN "que ninguém quer reiniciar"), é aí que mora o risco.

Roteiro rápido

1. Liste todos os pontos de VPN: firewalls com VPN SSL, servidores Windows com RRAS, DirectAccess ou Always On VPN.
2. Atualize ASA e FTD para a versão corrigida do seu ramo.
3. Confirme que os servidores Windows com IKEv2 têm as atualizações de abril de 2026 ou posteriores.
4. Filtre a origem dos túneis com parceiros e filiais.
5. Desligue serviços de VPN que não estão em uso.

Perguntas frequentes

Meu ASA não usa VPN SSL. Estou exposto?

Segundo a Cisco, só configurações específicas de VPN de acesso remoto são afetadas. Confira a lista do aviso. Se não houver VPN de acesso remoto, a exposição a esta falha específica não se aplica, mas mantenha o equipamento atualizado.

O IKE do Windows é usado por túneis site a site?

Pode ser, quando o Windows faz papel de respondedor IKEv2. A Microsoft cita RRAS, DirectAccess e Always On VPN como exemplos. Confira as políticas IPsec dos seus servidores.

Bloquear a porta UDP 500 resolve no Windows?

Para máquinas que não precisam aceitar IKE da internet, sim, o bloqueio tira o serviço do alcance de quem está fora. Para servidores de VPN, a porta precisa ficar aberta, e a saída é a atualização.

Por que o Radar junta as duas?

Porque a defesa é a mesma: o serviço de VPN é exposto por natureza e precisa de correção rápida, de filtro de origem onde der e de monitoramento.