CVE-2021-21985

Falha crítica de execução remota de código no plugin Virtual SAN Health Check do vSphere Client (HTML5), habilitado por padrão em toda instalação do vCenter Server, independentemente de o ambiente usar vSAN ou não. Qualquer atacante com acesso de rede à porta 443 do vCenter, sem precisar de autenticação, pode executar comandos com privilégios irrestritos no sistema operacional que hospeda o vCenter. É uma das CVEs mais exploradas do catálogo KEV da CISA, com PoC pública, módulo Metasploit e exploração confirmada em campo.

A causa raiz é falta de validação de entrada (CWE-20) no plugin vSAN Health Check, que roda dentro do vSphere Client. O CISA KEV também associa a falha a CWE-470 (Unsafe Reflection) e CWE-918 (SSRF), indicando que o vetor de exploração envolve o servidor instanciando classes ou fazendo requisições a partir de dados controlados pelo atacante, sem restringir quais classes ou destinos são permitidos. Esse padrão é comum em plugins Java do vSphere Client que expõem endpoints internos usados para comunicação entre serviços do próprio vCenter.

O ponto crítico é que esse plugin fica ativo em toda instalação de vCenter Server por padrão — não é um componente opcional que só existe se o administrador configurou vSAN. Isso elimina uma pré-condição que normalmente reduziria a superfície de exposição: não importa se o cliente usa storage definido por software da VMware, o plugin está lá e acessível.

A VMware publicou junto, no mesmo advisory (VMSA-2021-0010), a CVE-2021-21986, uma falha de mecanismo de autenticação nos plugins vSAN Health Check, Site Recovery, vSphere Lifecycle Manager e VMware Cloud Director Availability (CVSS 6.5). As duas vulnerabilidades afetam a mesma superfície — plugins do vSphere Client acessíveis via porta 443 — e é razoável que, em cenários reais de exploração, falhas de autenticação em endpoints de plugin sejam usadas para alcançar a rota de entrada que dispara a validação de entrada falha do CVE-2021-21985.

O vetor é rede: acesso TCP à porta 443 do vCenter Server é suficiente, sem exigir credenciais válidas (PR:N, UI:N no vetor CVSS). Não há pré-condição de configuração — o plugin vulnerável está habilitado por padrão em qualquer deployment de vCenter Server, mesmo sem vSAN. Isso torna a superfície de ataque igual à de qualquer instância de vCenter exposta, o que explica o CVSS 9.8 e a ampla exploração observada.

Existe PoC pública, módulo Metasploit e template Nuclei para detecção/exploração, o que baixa drasticamente a barreira técnica — a exploração deixou de exigir pesquisa própria e passou a ser trivial para qualquer operador de scanner automatizado. A CISA incluiu a CVE no catálogo KEV com confirmação de exploração ativa em campo (data de inclusão 2021-11-03, prazo de correção 2021-11-17 para agências federais dos EUA), o que indica campanhas de varredura em massa contra instâncias de vCenter expostas à internet ou alcançáveis lateralmente após comprometimento inicial de rede.

O resultado final da exploração é execução de comandos no sistema operacional subjacente ao vCenter Server com privilégios irrestritos — ou seja, controle total do host, não apenas da aplicação vSphere. Dado que o vCenter é o plano de controle central da infraestrutura de virtualização, comprometê-lo normalmente abre caminho para controle de todas as VMs e hosts ESXi gerenciados.

A correção definitiva é atualizar para vCenter Server 7.0 U2b, 6.7 U3n ou 6.5 U3p, conforme a linha em uso, ou para VMware Cloud Foundation 4.2.1 (vCenter 4.x) / 3.10.2.1 (vCenter 3.x). Não há patch parcial — a atualização completa do vCenter Server é o único caminho que resolve a causa raiz.

Quando a atualização imediata não é viável, a VMware publicou um workaround documentado na KB83829 (referenciada no advisory VMSA-2021-0010), que deve ser aplicado como paliativo temporário até a atualização. O advisório não detalha o conteúdo exato do workaround no texto disponível aqui — consulte a KB diretamente antes de aplicar, pois workarounds de plugin costumam desabilitar funcionalidade (no caso, provavelmente o próprio plugin vSAN Health Check ou o mecanismo de extensão afetado), o que pode impactar monitoramento de saúde de storage em ambientes que usam vSAN.

Restringir acesso de rede à porta 443 do vCenter apenas a hosts de gerência confiáveis reduz a exposição mas não é mitigação equivalente à correção — o vCenter tipicamente precisa estar acessível para administradores e integrações, e um atacante que já tenha pé na rede de gerência (via outro comprometimento) ainda explora a falha livremente. Segmentação de rede é controle compensatório, não substituto do patch.

Não há indicador de comprometimento específico detalhado nas fontes consultadas além da existência de módulo Metasploit, PoC pública e template Nuclei — o que sugere buscar em logs do vCenter (vsphere-client, logs do serviço de plugin) por requisições HTTP anômalas à porta 443 direcionadas a endpoints do plugin Virtual SAN Health Check, especialmente originadas de IPs não administrativos ou sem sessão autenticada válida. A presença de templates Nuclei públicos indica que scanners de reconhecimento em massa provavelmente geram um padrão de requisição identificável nos logs de acesso do vCenter; validar contra IOCs de exploração publicados por pesquisadores é mais confiável do que inferir sem eles.

Como a falha permite execução de comando no SO subjacente, sinais pós-exploração incluem processos filhos inesperados gerados pelo serviço do vCenter (vpxd, vsphere-ui) e conexões de saída não usuais originadas do host do vCenter — consistentes com quedas de shell reversa ou implantação de webshell.