CVE-2025-0282

Buffer overflow baseado em pilha no binário /home/bin/web dos appliances Ivanti Connect Secure, Policy Secure e Neurons for ZTA, explorável sem autenticação para execução remota de código. Foi usada como zero-day por um ator ligado à China (UNC5221, segundo Mandiant) desde meados de dezembro de 2024, semanas antes da divulgação oficial em 8 de janeiro de 2025 — não é uma falha teórica, é a base de uma campanha de comprometimento em massa de VPNs corporativas.

A falha está no processamento do protocolo IF-T sobre TLS, especificamente na função que trata o parâmetro clientCapabilities enviado pelo cliente VPN. O código copia esse valor para um buffer de pilha de 256 bytes usando strncpy — mas passa como limite o tamanho da string de origem (calculado com strlen sobre o próprio input do atacante), e não o tamanho do buffer de destino. Isso anula qualquer proteção que o strncpy deveria oferecer sobre o strcpy: o atacante controla completamente quantos bytes são escritos. É um CWE-121 (stack-based buffer overflow) clássico, sem sofisticação de trigger — pesquisadores da watchTowr notaram publicamente que a classe de vulnerabilidade é de 1990 e seria pega por fuzzing básico.

O binário não usa stack canaries, o que simplifica sobrescrever o endereço de retorno. Mas a exploração não é trivial: entre o overflow e o uso do endereço de retorno corrompido, o código executa destrutores de objetos (EPMessage e DSUtilMemPool) que residem na pilha logo após o buffer dest. Como o ponteiro object_to_be_freed também é sobrescrito pelo overflow, o destrutor tenta liberar um endereço inválido e lança excelência antes que o fluxo chegue ao ret — a watchTowr documentou isso como o obstáculo central para transformar o overflow em RCE confiável.

A exploração bem-sucedida (via PoC pública da Rapid7) usa uma ROP chain construída especificamente para uma versão de binário — o mapeamento de offsets muda entre builds, então um exploit para 22.7R2.4 não funciona contra outra revisão sem reconstruir a cadeia. Isso explica por que atacantes foram observados fazendo fingerprinting de versão antes de disparar o exploit.

O vetor é a interface HTTPS/IF-T-TLS do appliance, sem necessidade de credenciais (AV:N, PR:N, UI:N) — mas a complexidade de ataque é alta (AC:H) porque a ROP chain depende da versão exata do binário /home/bin/web em execução. Antes de disparar o exploit, atacantes fizeram reconhecimento de versão solicitando arquivos como /dana-cached/hc/hc_launcher..jar em sequência, muitas vezes de VPS ou Tor — um padrão que a Mandiant documentou como sinal de pré-exploração.

A PoC pública (sfewer-r7/Rapid7) ilustra a fragilidade prática do exploit: contra Ivanti Connect Secure 22.7r2.4, foram necessárias 191 tentativas e cerca de 34 minutos até obter execução de comando confiável, com código rodando sob o usuário não-root nr. Ou seja, exploração é factível remotamente e sem autenticação, mas não é 'one-shot' — exige repetição, tolerância a crashes do serviço, e uma ROP chain específica por versão/branch.

A campanha real documentada pela Mandiant (atribuída a UNC5221) foi muito além de PoC: após RCE inicial, o ator desabilita SELinux, bloqueia forwarding de syslog via iptables, remonta o root como read-write e implanta o dropper PHASEJAM, que injeta web shells Perl nos arquivos getComponent.cgi e restAuth.cgi, bloqueia atualizações simulando-as, e sobrescreve o binário remotedebug para execução arbitrária de comandos. Malware adicional da família SPAWN (SPAWNANT, SPAWNMOLE, SPAWNSNAIL) e, posteriormente, o malware RESURGE (identificado pela CISA em março de 2025) foram associados a essa exploração, inclusive com capacidade de sobreviver a resets/atualizações padrão.

O fornecedor liberou correção nas versões: Ivanti Connect Secure 22.7R2.5, Ivanti Policy Secure 22.7R1.2 e Ivanti Neurons for ZTA gateways 22.7R2.3. Atualizar é a única mitigação real — não há flag de configuração ou WAF que neutralize o overflow, já que o parâmetro vulnerável faz parte do handshake do protocolo VPN nativo (IF-T sobre TLS), não de uma rota HTTP filtrável de forma seletiva.

A CISA publicou instruções de mitigação específicas atualizadas em 28 de março de 2025, justamente porque identificou que o malware RESURGE conseguia comprometer a eficácia das mitigações anteriores. A orientação central: antes de simplesmente aplicar o patch, é preciso rodar a Integrity Checker Tool (ICT) externa da Ivanti e investigar indícios de comprometimento prévio — se houver evidência de compromisso, patchear sem fazer reset de fábrica não remove backdoors já instalados (web shells em getComponent.cgi/restAuth.cgi, binário remotedebug adulterado). Nesse cenário, a CISA recomenda reset de fábrica (ou reimagem a partir de imagem limpa em ambientes cloud/virtuais), reemissão de certificados, chaves de API e senhas locais, e revogação de tokens/Kerberos em ambientes híbridos comprometidos.

O mito a descartar: aplicar o patch sozinho, sem investigação prévia de comprometimento, não é suficiente se o appliance já foi explorado como zero-day entre dezembro de 2024 e o patch — o atacante pode ter persistência que sobrevive à atualização normal, daí a insistência da CISA em ICT e reset de fábrica antes de recolocar o sistema em produção.

Requisições HTTP a URLs de fingerprinting de versão como /dana-cached/hc/hc_launcher..jar, especialmente vindas de provedores de VPS ou da rede Tor e em sequência ordenada por versão, indicam reconhecimento pré-exploração segundo a Mandiant. Pós-exploração, procure por modificações nos arquivos getComponent.cgi e restAuth.cgi (inserção de função AccessAllow), alterações no binário remotedebug, entradas de log removidas via sed nos logs de debug e da aplicação, regras iptables bloqueando saída para portas 514/6514 (syslog) e SELinux desabilitado (setenforce 0) sem justificativa administrativa.

A Ivanti recomenda o uso da Integrity Checker Tool (ICT) externa como principal mecanismo de detecção de comprometimento, já que verificação interna do próprio appliance pode ser insuficiente contra malware como RESURGE, desenhado para subverter as mitigações. Não existe assinatura de rede única confiável para o exploit em si, dada a variação da ROP chain por versão — a detecção prática depende mais de artefatos pós-exploração do que de uma assinatura do payload de overflow.