Guardicore explica vulnerabilidade nível 10.0 da VMware

20/04/2020 mindsecblog Notícias 3

Guardicore explica vulnerabilidade nível 10.0 da VMware. O invasor pode controlar remotamente infraestrutura implementada em vSphere

Em pesquisa publicada em 15 de abril, no site da empresa, o Guardicore Labs fornece uma análise técnica completa e detalhada da vulnerabilidade recentemente anunciada pela VMware (CVE-2020-3952) mostrando como o invasor pode controlar uma implementação vSphere, com todas as suas máquinas e servidores.

Você pode ver aqui a pesquisa do Guardicore Labs

Histórico

Na quinta-feira passada, dia 09 de abril, a VMware publicou o comunicado CVE (Common Vulnerabilities and Exposures) identificado como 2020-3952, descrevendo uma “vulnerabilidade de divulgação de informações confidenciais no VMware Directory Service (vmdir)“. É um aviso conciso, sem maiores detalhes além de afirmar que qualquer vCenter Server v6.7 atualizado a partir de uma versão anterior é vulnerável.

O que chama atenção neste comunicado é que a vulnerabilidade tem pontuação 10,0 – a mais alta possível no padrão CVSS (Common Vulnerability Scoring System). Apesar do volume de notícias sobre esse comunicado, os profissionais de segurança da Guardicore não encontraram maiores informações técnicas sobre essa vulnerabilidade. E para melhor entender os riscos e como um invasor poderia explorá-los, o Guardicore Labs começou por investigar as alterações no patch VMware – vCenter Appliance 6.7 Atualização 3f.

Examinando as alterações feitas no serviço de diretório do vCenter, foi reconstruído o fluxo de código com falha que levou a essa vulnerabilidade. A análise mostrou que, com três comandos LDAP (protocolo de acesso a banco de dados Lightweight Directory Access Protocol) simples e não autenticados, um invasor com acesso à rede no vCenter Directory Service pode adicionar uma conta de administrador ao vCenter Directory. O Guardicore Labs implementou prova de conceito para essa exploração, verificando que consegue obter remotamente todas as informações contidas no vSphere.

A vulnerabilidade é ativada por dois problemas críticos no código de manipulação LDAP herdado do vmdir :

Um bug em uma função chamada VmDirLegacyAccessCheck que faz com que retorne “acesso concedido” quando as verificações de permissões falham.
Uma falha no design de segurança que concede privilégios de root a uma sessão LDAP sem token, supondo que seja uma operação interna.

Como a VMware lança suas novas versões como imagens de disco inteiras, em vez de patches incrementais, a Guardicore teve que diferir entre a versão anterior – Atualização 3e – e a nova. A montagem das imagens de disco revelou que essas versões são compostas por uma longa lista de RPMs, na maior parte. Depois de extrair o conteúdo de todos esses pacotes, os especialistas puderam ver quais arquivos haviam realmente mudado comparando os hashes lado a lado.

Infelizmente, quase 1500 arquivos foram alterados desde o último lançamento – muito mais do que podería ser verificado manualmente, assim os especialistas imaginam que culpado provavelmente teria “vmdir” em algum lugar em seu nome.

Mitigação – patch ou update

A medida mais eficaz para mitigar o risco demonstrado pelos pesquisadores da Guardicore é instalar o patch mais recente para a versão vulnerável do vCenter Server. Como alternativa, a instalação da versão mais recente (7.0) também resultará em uma implantação segura do vSphere.

É altamente recomendável limitar o acesso à interface LDAP do vCenter. Na prática, isso significa bloquear qualquer acesso pela porta LDAP (389), exceto para uso administrativo.

Isso era uma toca de coelho. Apesar da relativa clareza do código da VMware, parece que houve alguns erros que foram cometidos na vulnerabilidade. Os desenvolvedores também estavam pelo menos parcialmente conscientes deles, como os especalistas viram nos comentários do código e confirmaram nas mensagens. A correção para o VmDirLegacyAccessCheck não é mais do que o band-aid – se a VMware analisasse esse bug detalhadamente, teria encontrado uma série de problemas que precisam ser resolvidos: a estranha semântica do bIsAnonymousBind , o tratamento desastroso do pAccessToken e , é claro, o bug do qual os especialistas da Guardicore começaram, no VmDirLegacyAccessCheck .

Segundo a Guardicore, talvez a coisa mais angustiante, no entanto, seja o fato de que a correção de bug do VmDirLegacyAccessCheck foi escrita há quase três anos e só está sendo lançada agora. Três anos é muito tempo para que algo tão crítico quanto uma escalação de privilégios LDAP não conste no cronograma de lançamento – especialmente quando se mostra muito mais do que uma escalação de privilégios.