VMware Tools Authentication Bypass Vulnerability

Falha de bypass de autenticação no módulo vgauth do VMware Tools/open-vm-tools, que trata a autenticação das operações host-to-guest. A pré-condição é brutal: só é explorável se o host ESXi já estiver totalmente comprometido — ou seja, não é um vetor de entrada, é algo que um atacante já dentro do hipervisor pode usar. Está no catálogo KEV da CISA por evidência de exploração ativa, o que soa contraditório com o CVSS 3.9 (baixo), mas faz sentido em cenários de espionagem onde o objetivo é interagir com a VM guest sem deixar rastro de autenticação legítima, ou onde tecnologias de confidential computing tentam isolar o guest mesmo de um host comprometido.

O vgauth (VMware Guest Authentication) é o componente do VMware Tools responsável por validar operações que o host envia ao guest — parte da Guest Operations API (executar programas, transferir arquivos, etc.). A falha permite que esse processo de autenticação falhe silenciosamente quando o comando vem de um ESXi comprometido, deixando a checagem host-to-guest inoperante. O padrão CWE mais aderente é ausência/quebra de autenticação em função crítica (próximo de CWE-287/CWE-306).

A VMware e a comunidade open-vm-tools não publicaram detalhes de linha de código, mas os patches de correção distribuídos foram literalmente nomeados '2023-20867-Remove-some-dead-code[...].patch' para cada faixa de versão afetada. Isso indica que a correção foi a remoção de um caminho de código morto/residual dentro do vgauth que, sob determinada condição, permitia contornar a validação normal de autenticação — não uma reescrita de protocolo criptográfico.

O que o atacante controla é o canal host-to-guest do hipervisor: como ele já tem controle total do ESXi (PR:H no vetor CVSS), ele pode forçar o vgauth a aceitar operações como se tivessem sido autenticadas legitimamente, mesmo sem possuir credenciais válidas dentro do guest.

O pré-requisito real é o mais importante desta CVE: comprometimento completo e prévio do host ESXi (acesso local ao hipervisor, AV:L, com privilégios altos, PR:H). Isso não é uma vulnerabilidade de entrada — é uma capacidade que um atacante já dentro do ESXi pode usar. A partir dessa posição, ele consegue fazer o VMware Tools dentro da VM guest falhar a autenticação de comandos host-to-guest, contornando o controle que normalmente garante que apenas operações legítimas e autenticadas cheguem ao guest via Guest Operations API.

Um participante da lista oss-security (Demi Marie Obenour) questionou publicamente o valor prático dessa falha: um ESXi totalmente comprometido já pode comprometer o guest por outras vias (dump de memória, manipulação direta de disco virtual, etc.), a menos que a VM use tecnologias de confidential computing (ex.: memória de guest criptografada e isolada do hipervisor). Nesses casos, a bypass de autenticação do vgauth passa a ser um vetor relevante, porque o host não consegue acessar o guest por outros meios — só pode manipular o canal de gerenciamento do VMware Tools.

A presença no catálogo KEV da CISA indica exploração confirmada em ambientes reais, tipicamente como etapa de pós-comprometimento em campanhas que já obtiveram controle do hipervisor por outra via (por exemplo, falhas em vCenter/ESXi usadas para acesso inicial) e usam essa bypass para operar dentro dos guests evitando a trilha normal de autenticação — não como vulnerabilidade isolada de acesso inicial.

Atualize o open-vm-tools para 12.2.5 ou versão superior (lançada em 13 de junho de 2023), que remove o código vulnerável no vgauth. Para quem não pode migrar para o branch mais novo, a VMware distribuiu patches de backport específicos para as séries 12.2.0/12.1.5/12.1.0/12.0.5/12.0.0/11.3.5/11.3.0; 11.2.5/11.2.0/11.1.5/11.1.0; 11.0.5/11.0.0; e 10.3.10/10.3.5/10.3.0 — aplicáveis via git am ou patch -p2 sobre o código-fonte correspondente. Debian corrigiu no buster LTS na versão 2:10.3.10-1+deb10u4 (DLA-3531-1); Fedora corrigiu via rebase para open-vm-tools 12.3.0 (que também resolve a CVE-2023-20900).

O que não funciona como mitigação real: qualquer controle aplicado somente dentro do guest, porque a falha atua no canal host-to-guest controlado pelo hipervisor — se o ESXi já está comprometido, a superfície de ataque relevante é o próprio host, não a VM. A mitigação de fundo é impedir o comprometimento do ESXi (patch de vCenter/ESXi, isolamento da rede de gerenciamento, MFA para acesso administrativo ao hipervisor) — atualizar o VMware Tools apenas fecha essa técnica específica de bypass, não neutraliza um atacante que já tem root no host.

Para cargas de trabalho sensíveis, tecnologias de confidential computing reduzem o valor prático dessa falha para o atacante, já que mantêm a memória do guest opaca ao hipervisor independentemente do estado de autenticação do vgauth.

Não há indicador de comprometimento publicado pelo fornecedor para tentativas de exploração desta CVE especificamente. Como o pré-requisito é controle total do host ESXi, a detecção eficaz não está no guest ou na autenticação do vgauth — está em identificar o evento anterior que deu ao atacante esse controle (logs de acesso administrativo ao ESXi/vCenter, alterações de configuração do hipervisor fora de janela de manutenção, exploração de outras CVEs de acesso inicial). Nos logs do vmtoolsd/vgauthd é possível observar chamadas da Guest Operations API sem correspondência a ferramentas de gerência esperadas, mas essa observação só tem valor se o guest ainda conseguir gerar logs confiáveis — o que não é garantido quando o hipervisor que hospeda a VM já está sob controle do atacante.