VMware Tools Authentication Bypass Vulnerability
Priorize a correção. Ela está sob exploração confirmada pelo CISA e 1 grupo(s) de ameaça a utilizam.
Grupos conhecidos por explorar esta vulnerabilidade (atribuição MITRE ATT&CK).
Apply updates per vendor instructions.
Resumo
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.
Detalhamento técnico
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.
Como é explorada
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.
Versões
Como se proteger
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.
Como detectar
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.