CVE-2020-3952

Falha de controle de acesso no vmdir, o serviço de diretório (LDAP) que sustenta o Single Sign-On do VMware vCenter Server via Platform Services Controller (PSC). Um atacante sem nenhuma credencial e com acesso de rede à porta 389 consegue fazer bind LDAP anônimo e extrair dados do diretório que deveriam exigir autenticação. O CISA classifica como information disclosure, mas o CVSS 9.8 (C:H/I:H/A:H) reflete o fato de que os dados expostos podem viabilizar comprometimento total do vCenter — está no catálogo KEV da CISA, confirmando exploração ativa.

CWE-306 (Missing Authentication for Critical Function). O vmdir implementa listas de controle de acesso (ACLs) sobre os objetos do diretório LDAP que armazenam configuração e segredos do domínio SSO do vCenter. A falha está nessas ACLs: sob certas condições elas não bloqueiam corretamente requisições LDAP não autenticadas, permitindo leitura de objetos que deveriam estar restritos a usuários autenticados.

A própria VMware descreve a falha como dependente de 'certas condições' — a documentação pública amplamente associada a esta CVE indica que o problema afeta principalmente instâncias de vCenter que foram atualizadas (upgrade) a partir de versões anteriores à 6.7, mantendo ACLs legadas menos restritivas mesmo após a atualização do software. Instalações totalmente novas (fresh install) tendem a não carregar essas ACLs antigas. Essa é a pré-condição mais relevante da falha e frequentemente omitida quando se lê só o CVSS.

O atacante controla apenas a conexão de rede TCP/389 ao PSC (embedded ou external) — nenhuma credencial, nenhuma interação de usuário, nenhum campo de aplicação manipulado. O vetor é puramente protocolo LDAP contra um serviço de infraestrutura que normalmente não deveria estar exposto fora da rede de gerenciamento.

Vetor: LDAP anônimo contra a porta 389/tcp do vmdir, tipicamente hospedado no mesmo host do vCenter Server (embedded PSC) ou em um PSC externo dedicado. Pré-requisito real de exploração: alcance de rede a essa porta — em ambientes onde o PSC está isolado numa VLAN de gerenciamento sem rota de fora, a exposição prática é baixa; em ambientes onde a porta está acessível a partir de segmentos de usuário ou da internet, o risco é direto. A segunda pré-condição, conforme descrito acima, é a instância ter ACLs vulneráveis (histórico de upgrade).

Complexidade de exploração é baixa: não exige nenhuma interação da vítima, autenticação ou engenharia social — apenas ferramentas padrão de consulta LDAP. Existe PoC pública, módulo Metasploit e template Nuclei documentados, o que reduz a barreira técnica a praticamente zero para quem já tem acesso de rede ao serviço.

O resultado da exploração é extração de dados sensíveis do diretório do SSO. Historicamente, esse tipo de exposição em vmdir tem sido associado à obtenção de material que permite autenticação subsequente como usuário privilegiado do vCenter, o que explica por que o CVSS atribui impacto alto em confidencialidade, integridade e disponibilidade apesar da CISA rotular a falha como 'information disclosure'. O registro no catálogo KEV da CISA confirma exploração ativa documentada, sem detalhar campanha específica nas fontes consultadas.

A correção definitiva é aplicar a atualização do vCenter Server indicada pelo advisory oficial da VMware (VMSA-2020-0006). Não temos no material consultado o texto completo do advisory com os números de build corrigidos; para não arriscar informar uma versão incorreta, o leitor deve confirmar a versão-alvo exata (branch 6.5 e 6.7) diretamente no advisory antes de planejar o upgrade — a ação recomendada pela própria CISA no KEV é genérica: 'aplicar atualizações conforme instruções do fornecedor'.

Como paliativo enquanto o patch não é aplicado, restringir o acesso de rede à porta 389/tcp (e demais portas LDAP do vmdir) apenas a hosts de gerenciamento estritamente necessários, via firewall/segmentação, reduz drasticamente a superfície de ataque — já que a exploração depende inteiramente de alcance direto a essa porta. Esse controle não corrige a falha de ACL, apenas limita quem pode tentar explorá-la, e tem custo operacional baixo em ambientes onde o PSC já deveria estar isolado por boas práticas de arquitetura.

Não há mitigação via WAF, já que o protocolo explorado é LDAP, não HTTP — qualquer expectativa de proteção nesse nível é equivocada. Também não há indicação de que uma configuração de aplicação (sem tocar em rede ou patch) resolva o problema nas fontes consultadas.

Sinal mais direto: registros de bind LDAP anônimo (sem credenciais) seguidos de operações de busca (search) na porta 389 do vmdir, visíveis em logs do próprio serviço (diretório de logs do vmdird) ou em captura/inspeção de tráfego de firewall que normalize conexões LDAP à instância do PSC. A existência de módulo Metasploit e template Nuclei sugere que varreduras automatizadas gerariam esse padrão de bind anônimo seguido de query, mas não há, no material consultado, uma assinatura de rede oficial e específica publicada — na ausência dela, a defesa prática é monitorar qualquer conexão não autenticada à porta 389 do PSC como evento suspeito por si só, já que esse serviço não deveria receber tráfego anônimo em operação normal.