Il nuovo Ransomware ESXiArgs prende di mira i server VMware ESXi. Sfrutta la vulnerabilità CVE-2021-21974, corretta due anni fa. Cosa sappiamo per adesso
Gli alert dello CSIRT francese e dell’ACN Italiana: la CVE-2021-21974 sfruttata attivamente
I primi giorni di Febbraio sia il CERT francese che l’ACN hanno diramato alert avvisando le aziende di una massiccia campagna di scansione su server VMware ESXi esposti. IL CERT Francese, in dettaglio, ha avvisato che attaccanti sconosciuti stanno attivamente attaccando server VMware ESXi non patchati per distribuire un ransomware. La vulnerabilità in uso ha circa 2 anni e consente l’esecuzione di codice da remoto.
⚠️Alerte CERT-FR⚠️
— CERT-FR (@CERT_FR) February 3, 2023
CERTFR-2023-ALE-015 : Campagne d’exploitation d’une vulnérabilité affectant VMware ESXi (03 février 2023). https://t.co/KN6GDUdXcL
Dello stesso tenore l’alert dell’ACN, che ha avvisato come tramite Shodan, fosse in corso questa scansione massiva di server vulnerabili alla CVE-2021-21974. Questa vulnerabilità è una falla di sicurezza di OpenSLP che consente ad un utente non autenticato di ottenere la possibilità di eseguire codice dannoso da remoto tramite un attacco di scarso livello di complessità.
La conferma da parte di VMware è arrivata il 6 Febbraio: il vendor ha confermato la vulnerbailità sfruttata e ha sottolineato come non si tratti di una 0-day. La CVE-2021-21974 infatti è già stata risolta nel Febbraio 2021. In questa campagna la falla è stata sfruttata attraverso la porta OpenSLP(427) per distribuire un nuovo ransowmare, ESXiArgs.
Per saperne di più > Server VMWare ESXi sotto attacco: la patch è già disponibile
Le versioni affette sono:
- VMware ESXi 6.5
- VMware ESXi 6.7
- VMware ESXi 7.0
- VMware Cloud Foundation (ESXi) 3.x
- VMware Cloud Foundation (ESXi) 4.x
Il vendor ha invitato gli utenti ad installare i più recenti aggiornamenti di ESXi e di disabilitare il servizio OpenSLP, che è stato comunque disabilitato di default a partire dal 2021.
Vedi qui l’avviso di sicurezza di VMware > https://www.vmware.com/security/advisories/VMSA-2021-0002.html
La nuova operazione ransomware che ha colpito l’Europa (e non solo): ESXiArgs
Questa ondata di scansioni è stata seguita, come detto, da attacchi diretti verso quei server vulnerabili risultati esposti in Internet. Il provider cloud francese OVHcloud, che purtroppo ha subito l’infezione di alcuni server, ha per primo collegato questa ondata di attacchi contro i server VMware ESXi al ransomware Nevada. Col trascorrere dei giorni si è fatto chiaro che, invece, l’Europa si è trovata a fronteggiare una minaccia nuova, un nuovo ransomware. Nuova minaccia che, già al primo giorno di operazioni, ha criptato 120 server ESXi arrivando a 2.400 server infettati nel primo fine settimana.
A fronte di un buon numero di server criptati, risultano invece pochissimi riscatti pagati: la richiesta ammonta a circa 42.000 euro. Probabilmente ciò è stato influenzato dal fatto che un ricercatore di sicurezza, Eners Sonmez, ha pubblicato una guida che consente gli amministratori di ricostruire le proprie virtual machine e recuperare i dati in chiaro (la guida è disponibile qui. Non garantiamo l’efficacia di questa soluzione, la menzioniamo per dovere di completezza delle informazioni N.d.r).
Ransomware ESXiArgs: cosa sappiamo per adesso
Il ransomware EXSiArgs cripta i file con estensioni .vmxf, .vmx, .vmdk, .vmsd e .nvram, quindi crea un file .args con i metadata per ogni file criptato. La nota di riscatto è un file HTML chiamato “ransom.html” e “How to Restore Your Files.html“, ma alcune vittime hanno dichiarato di aver ritrovato sui sistemi colpiti una nota di riscatto in formato testuale
I tecnici della redazione di Bleeping Computer hanno potuto analiuzzare l’encryptor del ransomware. Sono così riusciti a ricostruire come sono condotti questi attacchi. Una volta ottenuto l’accesso al server, sono salvati nella cartella temp i file
- ecrypt – l’eseguibile ELF dell’encryptor;
- encrypt.sh – uno script shell che esegue una serie di azionji prima di eseguire l’ecryptor;
- public.pem – la chiave pubblica RSA usata per criptate la chiave per criptare un file;
- motd – la nota di riscatto in forma testuale sarà copiata in /etc/motd, così sarà mostrata al login. Il file originale del server sarà copiato in /etc/motd1;
- index.html – è la nota di riscatto in formato HTML, che serve a sostituire la home page di VMware ESXi.
Ransomware ESXiArgs: qualche info tecnica
La bad news è che l’encryptor non mostra falle sfruttabili per violare l’algoritmo di criptazione. Interessante però è l’uso di Sosemanuk, un cifrario a flusso usato per generare le chiavi di criptazione. La chiave di criptazione privata non viene salvata, così gli attaccanti si assicurano che, senza chiave privata, la vittima non potrà ripristinare i file. Sosemanuk è usato molto raramente nel mondo ransomware e rimanda ad una precisa famiglia, quella di Babuk, il cui codice sorgente è trapelato online.
“L’uso dell’algoritmo Sosemanuk è piuttosto raro e di solito viene usato solo dai ransomware il cui codice deriva da Babuk (nella variante per ESXi). Potrebbe essere questo il caso, ma l’hanno modificato per usare RSA invece dell’implementazione Curve25519 di Babuk”.
L’encryptor è lanciato usando lo shell script encrypt.sh. Quando lanciato, lo script eseguirà i seguenti comandi per motidifcare il file di configurazione (.vmx) della macchina virtuale ESXi,così che le stringe ‘.vmdk’ e ‘.vswp’ sono modificate in ‘1.vmdk’ e ‘1.vswp’.
Lo script termina quindi tutte le virtual machine in esecuzione semplicemente forzando all’arresto tutti i processi che contengonmo la stinga wmx o simili. Quindi lo script userà il comando
esxcli storage filesystem list | grep "/vmfs/volumes/" | awk -F' ' '{print $2}per ottenere la lista dei volumi EXSi (in dettaglio cerchherà match con le seguenti estensioni .vmdk, .vmx, .vmxf, .vmsd, .vmsn, .vswp, .vmss, .nvram, .vmem. Quindi, per ogni file, lo script creerà un file “nomefile.args” nella stessa cartella. Quindi viene avviata la criptazione. Nella foto sotto la routine per creare i file .args e criptare i file
Infine lo script “ripulisce”il campo di battaglia. Cancellerà i log, una serie di linee da alcuni file come
/var/spool/cron/crontabs/root e /bin/hostd-probe.sh (ecc…), quindi rimuoverà una bacldoor Python precedentemente installata in /store/packages/vmtools.py.
Per una trattazione più estesa, rimandiamo alla fonte originale dell’analisi di Bleeping Computer.
