Privilege escalation vulnerability

Falha de escalação de privilégios no vCenter Server que permite a um atacante já autenticado com privilégios baixos, com acesso de rede ao serviço, elevar-se a root enviando um pacote de rede especialmente criado. A Broadcom confirmou exploração ativa in the wild e a CISA incluiu a falha no catálogo KEV; costuma ser encadeada com CVE-2024-38812 (heap-overflow no DCERPC, RCE) do mesmo advisory para comprometimento completo do vCenter.

A CISA classifica a falha como CWE-250 (Execution with Unnecessary Privileges) e CWE-273 (Improper Check for Dropped Privileges). O padrão típico dessa classe de bug é um processo ou serviço do vCenter que executa uma operação privilegiada e depois tenta reduzir (drop) seus privilégios antes de processar entrada de rede não confiável, mas falha em verificar se essa redução foi de fato aplicada — deixando uma janela em que o código continua rodando com privilégios de root ao tratar o pacote malicioso. Nenhuma das fontes detalha o serviço, porta ou protocolo específico afetado; a Broadcom só afirma que o disparo ocorre via 'pacote de rede especialmente criado' enviado a componente não identificado do vCenter Server.

O vetor CVSS 3.1 (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) é a informação mais reveladora do advisory: PR:L indica que o atacante precisa de privilégios baixos previamente concedidos no vCenter — não é uma falha explorável por qualquer host com acesso de rede sem autenticação, como a frase da descrição oficial pode sugerir isoladamente. AC:H (complexidade de ataque alta) sinaliza que há condições fora do controle direto do atacante, coerentes com uma race condition ou dependência de estado específico do serviço no momento do drop de privilégios.

A vulnerabilidade foi reportada pela dupla zbl & srs, da equipe TZL, no contexto do concurso Matrix Cup 2024, o mesmo grupo que reportou o CVE-2024-38812 (heap-overflow no DCERPC) tratado no mesmo boletim VMSA-2024-0019. O impacto reportado é C:H/I:H/A:H — comprometimento total de confidencialidade, integridade e disponibilidade, consistente com execução como root.

Pré-requisito real: acesso de rede ao vCenter Server e privilégios baixos (PR:L) já concedidos — ou seja, o atacante precisa de alguma conta ou sessão autenticada com permissões mínimas no vCenter, não é uma exploração pré-autenticação isolada. Isso reduz drasticamente a superfície comparada a um RCE anônimo, mas ainda é crítico em ambientes onde contas de baixo privilégio são amplamente distribuídas (equipes de operação, service accounts, integrações) ou onde outro vetor (ex.: credenciais vazadas, phishing, ou o próprio CVE-2024-38812) já deu esse acesso inicial.

A Broadcom confirmou, na atualização de 18 de novembro de 2024 do VMSA-2024-0019, que exploração já ocorreu in the wild tanto para CVE-2024-38813 quanto para CVE-2024-38812. A CISA adicionou a falha ao catálogo KEV em 20/11/2024 com prazo de correção até 11/12/2024, o que reforça que há atividade real de exploração documentada pelo fornecedor, não apenas risco teórico. Nenhuma das fontes detalha se a exploração observada usou CVE-2024-38813 isoladamente ou encadeada com CVE-2024-38812 para obter o acesso inicial de baixo privilégio antes de escalar a root — cenário plausível dado que ambas as falhas foram corrigidas no mesmo conjunto de patches e reportadas pelo mesmo pesquisador.

Resultado final da exploração: execução com privilégios de root no appliance vCenter, o que dá controle total sobre a gestão do ambiente vSphere — hosts ESXi, VMs, credenciais armazenadas e configuração de todo o datacenter virtualizado gerenciado por aquele vCenter.

Não existe workaround. A própria Broadcom declara explicitamente 'Workarounds: None' no VMSA-2024-0019 — a única remediação é aplicar o patch. Atualizar vCenter Server 8.0 para 8.0 U3d, ou para 8.0 U2e nos ambientes que seguem esse ramo; vCenter Server 7.0 para 7.0 U3t. Para VMware Cloud Foundation, aplicar patch assíncrono conforme a KB88287: ramos 5.x para o equivalente de 8.0 U3d, 5.1.x para 8.0 U2e, e 4.x para 7.0 U3t.

Atenção a uma pegadinha documentada no próprio advisory: os patches de vCenter liberados em 17 de setembro de 2024 não corrigiram completamente a falha companheira CVE-2024-38812 (heap-overflow), exigindo uma segunda rodada de patches liberada em 21 de outubro de 2024. Ambientes que aplicaram apenas o patch de setembro devem confirmar que estão na versão final listada (8.0 U3d, 8.0 U2e, 7.0 U3t) e não em uma build intermediária. A Broadcom também alertou, em change log de 20/09/2024, que os updates de vCenter 8.0 U3b mencionados na matriz original podem introduzir um problema funcional — vale checar a KB referenciada antes de aplicar em produção.

Não existe mitigação compensatória via segmentação de rede que elimine o risco por completo, já que o vetor exige apenas acesso de rede e privilégio baixo já concedido — mas restringir o acesso administrativo/API do vCenter a redes de gerência isoladas e revisar quem detém contas com privilégios mínimos reduz a superfície enquanto o patch não é aplicado. Isso é redução de risco, não correção da falha.

As fontes consultadas não trazem indicadores de comprometimento, assinaturas de rede ou padrões de log específicos publicados pela Broadcom ou pela CISA para esta CVE — apenas a confirmação de que exploração ocorreu in the wild, sem detalhar o mecanismo observado. Na ausência de IOCs oficiais, a recomendação prática é monitorar logs de autenticação e auditoria do vCenter (vpxd, eventos de escalonamento de privilégio) em busca de atividade anômala em contas de baixo privilégio seguida por ações que normalmente exigiriam privilégios administrativos, e tratar qualquer tráfego incomum direcionado às interfaces de gerência do vCenter como suspeito até confirmação de patch aplicado.