Administradores, provedores de hospedagem e a equipe francesa de resposta a emergências de computadores (CERT-FR) alertam que os invasores visam ativamente os servidores VMware ESXi sem correção contra uma vulnerabilidade de execução remota de código de dois anos para implantar um novo ransomware ESXiArgs.
Rastreada como CVE-2021-21974 , a falha de segurança é causada por um problema de estouro de heap no serviço OpenSLP que pode ser explorado por agentes de ameaças não autenticados em ataques de baixa complexidade.
“Conforme as investigações atuais, essas campanhas de ataque parecem estar explorando a vulnerabilidade CVE-2021-21974, para a qual um patch está disponível desde 23 de fevereiro de 2021”, disse o CERT-FR.
“Os sistemas visados atualmente seriam hipervisores ESXi na versão 6.xe anteriores à 6.7.”
Para bloquear ataques recebidos, os administradores precisam desabilitar o serviço vulnerável Service Location Protocol (SLP) em hipervisores ESXi que ainda não foram atualizados.
O CERT-FR recomenda enfaticamente a aplicação do patch o mais rápido possível, mas acrescenta que os sistemas não corrigidos também devem ser verificados para procurar sinais de comprometimento.
CVE-2021-21974 afeta os seguintes sistemas:
- Versões ESXi 7.x anteriores a ESXi70U1c-17325551
- Versões ESXi 6.7.x anteriores a ESXi670-202102401-SG
- Versões ESXi 6.5.x anteriores a ESXi650-202102101-SG
O provedor de nuvem francês OVHcloud publicou pela primeira vez um relatório vinculando essa onda massiva de ataques direcionados a servidores VMware ESXi com a operação de ransomware Nevada.
“De acordo com especialistas do ecossistema e autoridades, eles podem estar relacionados ao ransomware de Nevada e estão usando o CVE-2021-21974 como vetor de comprometimento. A investigação ainda está em andamento para confirmar essas suposições”, disse Julien Levrard, CISO da OVHcloud .
No entanto, a empresa voltou atrás logo depois que nossa história foi divulgada, dizendo que a atribuíram à operação errada de ransomware.
Ao final do primeiro dia de ataques, aproximadamente 120 servidores ESXi foram criptografados.
No entanto, os números cresceram rapidamente no fim de semana, com 2.400 dispositivos VMware ESXi em todo o mundo atualmente detectados como comprometidos na campanha de ransomware, de acordo com uma pesquisa do Censys .
Em um comunicado publicado em 6 de fevereiro, a VMware confirmou que este ataque explora falhas mais antigas do ESXi e não uma vulnerabilidade de dia zero.
A empresa aconselha os administradores a instalar as atualizações mais recentes dos servidores ESXi e desabilitar o serviço OpenSLP , que está desabilitado por padrão desde 2021.
No geral, a campanha de ransomware não teve muito sucesso considerando o grande número de dispositivos criptografados, com o serviço de rastreamento de pagamento de resgate Ransomwhere relatando apenas quatro pagamentos de resgate para um total de $ 88.000.
A falta de pagamentos de resgate provavelmente se deve a um guia de recuperação VMware ESXi criado pelo pesquisador de segurança Enes Sonmez, permitindo que muitos administradores reconstruam suas máquinas virtuais e recuperem seus dados gratuitamente.
Novo ransomware ESXiArgs
No entanto, pelas notas de resgate vistas neste ataque, elas não parecem estar relacionadas ao Nevada Ransomware e parecem ser de uma nova família de ransomware.
Começando há cerca de quatro horas, as vítimas afetadas por esta campanha também começaram a relatar os ataques no fórum do BleepingComputer , pedindo ajuda e mais informações sobre como recuperar seus dados.
O ransomware criptografa arquivos com as extensões .vmxf, .vmx, .vmdk, .vmsd e .nvram em servidores ESXi comprometidos e cria um arquivo .args para cada documento criptografado com metadados (provavelmente necessários para descriptografia).
Embora os agentes de ameaças por trás desse ataque afirmem ter roubado dados, uma vítima relatou nos fóruns do BleepingComputer que não era o caso em seu incidente.
“Nossa investigação determinou que os dados não foram infiltrados. Em nosso caso, a máquina atacada tinha mais de 500 GB de dados, mas uso diário típico de apenas 2 Mbps. Analisamos as estatísticas de tráfego dos últimos 90 dias e não encontramos evidências de dados de saída transferência”, disse o administrador.
As vítimas também encontraram notas de resgate chamadas “ransom.html” e “How to Restore Your Files.html” em sistemas bloqueados. Outros disseram que suas notas são arquivos de texto simples.
Michael Gillespie , daID Ransomware , está atualmente rastreando o ransomware sob o nome ‘ ESXiArgs ‘, mas disse ao BleepingComputer que, até que possamos encontrar uma amostra, não há como determinar se há algum ponto fraco na criptografia.
BleepingComputer tem um tópico de suporte ESXiArgs dedicado onde as pessoas estão relatando suas experiências com este ataque e recebendo ajuda para recuperar máquinas.
Detalhes técnicos do ESXiArgs
Ontem à noite, um administrador recuperou uma cópia do criptografador ESXiArgs e do shell script associado e o compartilhou no tópico de suporte do BleepingComputer .
Analisar o script e o criptografador nos permitiu entender melhor como esses ataques foram conduzidos.
Quando o servidor é violado, os seguintes arquivos são armazenados na pasta /tmp:
- encrypt – O executável ELF do criptografador.
- encrypt.sh – Um script de shell que atua como a lógica do ataque, executando várias tarefas antes de executar o criptografador, conforme descrito abaixo.
- public.pem – Uma chave RSA pública usada para criptografar a chave que criptografa um arquivo.
- motd – A nota de resgate em forma de texto que será copiada para /etc/motd para que seja mostrada no login. O arquivo original do servidor será copiado para /etc/motd1.
- index.html – A nota de resgate em formato HTML que substituirá a página inicial do VMware ESXi. O arquivo original do servidor será copiado para index1.html na mesma pasta.
Michael Gillespie, do ID Ransomware, analisou o criptografador e disse ao BleepingComputer que a criptografia é, infelizmente, segura, o que significa que nenhum bug de criptografia permite a descriptografia.
“O public.pem que ele espera é uma chave RSA pública (meu palpite é RSA-2048 com base na observação de arquivos criptografados, mas o código tecnicamente aceita qualquer PEM válido)”, Gillespie postou no tópico de suporte do fórum .
“Para que o arquivo seja criptografado, ele gera 32 bytes usando o CPRNG RAND_pseudo_bytes seguro do OpenSSL , e essa chave é usada para criptografar o arquivo usando Sosemanuk, uma cifra de fluxo seguro. A chave do arquivo é criptografada com RSA ( RSA_public_encrypt do OpenSSL ) e anexada a final do arquivo.”
“O uso do algoritmo Sosemanuk é único e geralmente é usado apenas em ransomware derivado do código-fonte Babuk (variante ESXi). Talvez seja esse o caso, mas eles o modificaram para usar RSA em vez da implementação Curve25519 de Babuk.”
Esta análise indica que o ESXiArgs provavelmente se baseia no código-fonte vazado do Babuk , que foi usado anteriormente por outras campanhas de ransomware ESXi, como CheersCrypt e o criptografador PrideLocker do grupo Quantum/Dagon.
Embora a nota de resgate para ESXiArgs e Cheerscrypt seja muito semelhante, o método de criptografia é diferente, deixando claro se esta é uma nova variante ou apenas uma base de código Babuk compartilhada.
Além disso, isso não parece estar relacionado ao ransomware Nevada, conforme mencionado anteriormente pela OVHcloud.
O criptografador é executado por um arquivo shell script que o inicia com vários argumentos de linha de comando, incluindo o arquivo de chave pública RSA, o arquivo a criptografar, os blocos de dados que não serão criptografados, o tamanho de um bloco de criptografia e o arquivo tamanho.
usage: encrypt <public_key> <file_to_encrypt> [<enc_step>] [<enc_size>] [<file_size>]
enc_step - number of MB to skip while encryption
enc_size - number of MB in encryption block
file_size - file size in bytes (for sparse files)
Esse criptografador é iniciado usando o script de shell encrypt.sh que atua como a lógica por trás do ataque, que descreveremos brevemente a seguir.
Quando iniciado, o script executará o seguinte comando para modificar os arquivos de configuração da máquina virtual ESXi (.vmx) para que as strings ‘ .vmdk’ e ‘ .vswp’ sejam alteradas para ‘ 1.vmdk’ e ‘ 1.vswp ‘.
Fonte: BleepingComputer
Em seguida, o script encerra todas as máquinas virtuais em execução encerrando à força (kill -9) todos os processos que contêm a string ‘ vmx ‘ de maneira semelhante a este artigo de suporte da VMware .
O script usará o esxcli storage filesystem list | grep "/vmfs/volumes/" | awk -F' ' '{print $2}comando ‘ ” para obter uma lista de volumes ESXi.
O script procurará nesses volumes os arquivos correspondentes às seguintes extensões:
.vmdk
.vmx
.vmxf
.vmsd
.vmsn
.vswp
.vmss
.nvram
.vmemPara cada arquivo encontrado, o script criará um arquivo [nome_do_arquivo].args na mesma pasta, que contém o passo de tamanho calculado (mostrado abaixo), ‘1’ e o tamanho do arquivo.
Por exemplo, server.vmx terá um arquivo server.vmx.args associado.
O script usará o executável ‘encrypt’ para criptografar os arquivos com base nos parâmetros calculados, conforme mostrado na captura de tela abaixo.
Fonte: BleepingComputer
Após a criptografia, o script substituirá o arquivo ESXi index.html e o arquivo motd do servidor pelas notas de resgate, conforme descrito acima.
Por fim, o script executa alguma limpeza excluindo logs, removendo um backdoor do Python instalado em /store/packages/vmtools.py [ VirusTotal ] e excluindo várias linhas dos seguintes arquivos:
/var/spool/cron/crontabs/root
/bin/hostd-probe.sh
/etc/vmware/rhttpproxy/endpoints.conf
/etc/rc.local.d/local.sh
Fonte: BleepingComputer
O arquivo /store/packages/vmtools.py é o mesmo backdoor Python personalizado para o servidor VMware ESXi descoberto pela Juniper em dezembro de 2022, permitindo que os agentes de ameaças acessem remotamente o dispositivo.
Todos os administradores devem verificar a existência desse arquivo vmtools.py para garantir que ele foi removido. Se encontrado, o arquivo deve ser removido imediatamente.
Por fim, o script executa o /sbin/auto-backup.sh para atualizar a configuração salva no arquivo /bootbank/state.tgz e inicia o SSH.
Esta é uma história em desenvolvimento e será atualizada com novas informações assim que estiverem disponíveis…
Atualização 2/4/23: Adicionados detalhes técnicos sobre o ataque. – Lawrence Abrams
Update 2/5/23: Atualizado com novo número de servidores ESXi criptografados e método para recuperar máquinas virtuais.
Atualização 2/6/23: Adicionadas informações da VMware e pagamentos de resgate conhecidos.
