CVE-2022-22948

Falha de permissões incorretas em arquivos padrão (CWE-276) no vCenter Server, que expõe informações sensíveis a um usuário já autenticado com privilégios não administrativos. Não é uma falha de acesso remoto anônimo: exige uma conta válida de baixo privilégio dentro do ambiente vCenter, o que reduz bastante a superfície de exposição real em relação ao que a manchete sugere. Entrou no catálogo KEV da CISA em julho de 2024, mais de dois anos depois da publicação original, indicando exploração ativa tardia, provavelmente por atores que já tinham pé dentro da rede.

A vulnerabilidade está em permissões de arquivo incorretas por padrão em componentes do vCenter Server (CWE-276: Incorrect Default Permissions). O fornecedor não detalhou publicamente qual arquivo ou diretório específico tem a permissão errada, nem qual tipo de dado sensível é exposto — a VMware apenas confirma que a causa raiz é permissionamento inadequado que permite leitura por contas de baixo privilégio.

Há divergência relevante entre as duas avaliações de severidade publicadas. A VMware calcula CVSSv3 5.5 com vetor AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N — ou seja, vetor de ataque local, exigindo que o atacante já tenha acesso a um shell ou sessão no host/appliance do vCenter. O NVD (e o CVSS informado neste registro) usa AV:N, resultando em 6.5, tratando o vetor como explorável remotamente. Essa diferença de AV:L vs AV:N muda o modelo de ameaça: se a leitura do vendor estiver correta, a exploração não é 'via rede' no sentido de acesso a uma API HTTP exposta, mas sim de dentro de uma sessão/console já estabelecida.

Em ambos os cálculos, PR:L é constante: o atacante precisa de uma conta não administrativa já existente e válida no vCenter — não é uma falha de bypass de autenticação. O impacto é unicamente de confidencialidade (C:H/I:N/A:N): não há alteração de dados nem negação de serviço, apenas leitura de informação que deveria estar restrita a contas privilegiadas.

O pré-requisito real para exploração é ter uma conta com acesso não administrativo ao vCenter Server — seja uma conta de usuário do vSphere com permissões limitadas, seja acesso a um shell/console do appliance. A partir daí, o atacante aproveita a permissão de arquivo incorreta para ler conteúdo que deveria estar restrito a contas com privilégio elevado, obtendo informação sensível que pode servir para movimentação lateral ou escalada de privilégio subsequente dentro do ambiente de virtualização.

Os dados de threat intel indicam existência de PoC pública e módulo Metasploit, e a CVE está no catálogo KEV da CISA como exploração confirmada em campo — mas a inclusão só ocorreu em julho de 2024, mais de dois anos após a divulgação original (março de 2022), sugerindo que a exploração ativa detectada é recente e provavelmente ligada a campanhas que já tinham comprometido credenciais de baixo privilégio em ambientes vCenter não corrigidos, e não a um ataque de dia zero contra a internet exposta.

A complexidade de exploração é baixa (AC:L) uma vez satisfeito o pré-requisito de acesso — não há interação do usuário nem condições de corrida envolvidas. O ponto crítico para avaliar risco real em um ambiente específico é: existe alguma conta de baixo privilégio (de usuário legítimo, integração, ou serviço) com acesso ao vCenter que não deveria poder ler dados sensíveis? Se sim, o vetor está presente independente de exposição à internet.

Atualizar é a única mitigação real — a própria VMware afirma explicitamente que não há workaround. As versões corrigidas, por linha: vCenter Server 7.0 (appliance ou Windows) para 7.0 U3d; vCenter Server 6.7 Virtual Appliance para 6.7 U3p (a instalação Windows na linha 6.7 não é afetada); vCenter Server 6.5 Virtual Appliance para 6.5 U3r (Windows na linha 6.5 também não é afetado). Para VMware Cloud Foundation, que empacota o vCenter Server como componente: linha 4.x corrigida na versão 4.4.1; linha 3.x corrigida na versão 3.11.

Como não existe workaround de configuração, o controle compensatório até a atualização é reduzir o número de contas com acesso não administrativo ao vCenter e revisar quais contas de serviço/integração têm sessões ativas — isso não fecha a falha, apenas reduz quem pode explorá-la. Restringir acesso de rede à interface de gerenciamento não neutraliza o vetor se a avaliação de vetor local (AV:L) do vendor estiver correta, já que o requisito é ter uma sessão/conta já dentro do ambiente, não acesso de rede externo.

Não há mitigação via WAF ou filtro de tráfego, porque a falha não está em uma requisição HTTP manipulável — está em permissão de arquivo no lado do servidor. Considerando que a CVE está no KEV da CISA com prazo de correção vencido (due date 2024-08-07), qualquer instância ainda nas versões vulneráveis deve ser tratada como prioridade de patch imediata, independente de exposição à internet.

Não há, nas fontes oficiais, indicadores de comprometimento ou padrões de log publicados pela VMware para esta CVE especificamente — o advisory não lista assinaturas de detecção. Na ausência de sinal oficial, o caminho prático é auditar logs de acesso/leitura a arquivos do sistema no appliance do vCenter (auditd, logs do vCenter Server) buscando leitura de arquivos por contas que não deveriam ter esse acesso, e revisar logs de autenticação para identificar contas de baixo privilégio com atividade fora do padrão esperado antes e depois da suspeita de exploração.