In questi giorni tutti, esperti di settore ma anche e soprattutto media generalisti, parlano (o, in certi casi, straparlano) di questo attacco ai danni dei sistemi VMware ESXi. Ma quanto il nuovo ransomware ESXiArgs è effettivamente distruttivo, e qual è il pericolo reale per le aziende italiane allo stato attuale?
Fotografia della situazione
Nel momento in cui scriviamo, i casi totali rilevabili attraverso un’analisi condotta con Shodan (qui approfondiamo il funzionamento della piattaforma) sono poco più di 1000; i paesi più colpiti risultano gli Stati Uniti (277 casi) e la Francia (261), con una significativa diffusione anche in Germania e Canada.
Al contrario, l’Italia risulta solo minimamente toccata dalla portata dell’attacco, con soli 5 casi registrati.
Secondo invece la piattaforma Censys, i server francesi coinvolti sarebbero molti di più, con un coinvolgimento delle infrastrutture italiane (17 invece che 5) solo leggermente maggiore rispetto ai dati rilevati con Shodan.
Analisi tecnica
Gli amministratori, i provider di hosting e il Computer Emergency Response Team francese (CERT-FR) avvertono che gli aggressori prendono attivamente di mira i server VMware ESXi senza patch contro una vulnerabilità di due anni fa per l’esecuzione di codice remoto per diffondere un nuovo ransomware ESXiArgs.
Identificata come CVE-2021-21974, la falla di sicurezza è causata da un problema di heap overflow nel servizio OpenSLP, che può essere sfruttato da attori non autenticati in attacchi a bassa complessità.
“Secondo le indagini in corso, queste campagne di attacco sembrano sfruttare la vulnerabilità CVE-2021-21974, per la quale è disponibile una patch dal 23 febbraio 2021”, ha dichiarato il CERT-FR. “I sistemi attualmente presi di mira sono gli hypervisor ESXi nella versione 6.x e precedente alla 6.7”.
Per bloccare gli attacchi in arrivo, gli amministratori devono disabilitare il servizio vulnerabile Service Location Protocol (SLP) sugli hypervisor ESXi che non sono ancora stati aggiornati.
Il CERT-FR raccomanda vivamente di applicare la patch il prima possibile, ma aggiunge che anche i sistemi che non hanno ancora installato la patch dovrebbero essere scansionati per cercare indicatori di compromissione.
CVE-2021-21974 riguarda i seguenti sistemi:
- Versioni ESXi 7.x precedenti a ESXi70U1c-17325551
- Versioni ESXi 6.7.x precedenti a ESXi670-202102401-SG
- Versioni ESXi 6.5.x precedenti a ESXi650-202102101-SG
Anche il cloud provider francese OVHcloud ha pubblicato oggi un rapporto che ipotizza un collegamento tra questa massiccia ondata di attacchi ai server VMware ESXi e il gruppo Nevada Ransomware.
“Secondo gli esperti di settore e le autorità, potrebbero sussistere collegamenti con Nevada Ransomware e si sta utilizzando CVE-2021-21974 come vettore di compromissione. Le indagini sono ancora in corso per confermare queste ipotesi”, ha dichiarato Julien Levrard, CISO di OVHcloud. “L’attacco sta colpendo principalmente i server ESXi in versione precedente alla 7.0 U3i, apparentemente attraverso la porta OpenSLP (427)”.
Secondo una ricerca Censys, circa 3.200 server VMware ESXi in tutto il mondo sono stati compromessi dalla campagna ransomware ESXiArgs.
Ransomware ESXiArgs: caratteristiche e peculiarità
Tuttavia, dalle note di riscatto riscontrate in questo attacco, non sembrano essere evidenti le correlazioni con Nevada Ransomware: ESXiArgs sembra piuttosto appartenere a una nuova famiglia di ransomware.
Il ransomware cripta i file con estensione .vmxf, .vmx, .vmdk, .vmsd e .nvram sui server ESXi compromessi e crea un file .args per ogni documento crittografato con i metadati (probabilmente necessari per la decodifica).
Mentre gli attaccanti dietro questo attacco sostengono di esfiltrare i dati cifrati dal malware, non ci sono conferme al momento che questa affermazione corrisponda a realtà.
“La nostra indagine ha determinato che i dati non sono stati violati. Nel nostro caso, il computer attaccato aveva oltre 500 GB di dati ma un utilizzo giornaliero tipico di soli 2 Mbps. Abbiamo esaminato le statistiche del traffico degli ultimi 90 giorni e non abbiamo trovato alcuna prova di trasferimento di dati in uscita”, ha dichiarato un amministratore di sistema.
Le vittime hanno anche trovato una nota di riscatto in file denominati “ransom.html” e “How to Restore Your Files.html”, presenti sui sistemi bloccati. Altri hanno detto che le loro note sono costituite da file di testo invece che .html.
Dettagli tecnici di ESXiArgs
L’analisi dello script e dell’encryptor effettuata da BleepingComputer consente di capire meglio come sono stati condotti questi attacchi.
Quando il server viene violato, i seguenti file vengono memorizzati nella cartella /tmp:
- encrypt – L’eseguibile ELF dell’encryptor.
- encrypt.sh – Uno shell script che funge da base logica per l’attacco, eseguendo varie operazioni prima dell’esecuzione dell’encryptor, come descritto di seguito.
- public.pem – Una chiave RSA pubblica utilizzata per cifrare la chiave che cripta un file.
- motd – La nota di riscatto in forma di testo che verrà copiata in /etc/motd in modo da essere visualizzata all’accesso. Il file originale del server sarà copiato in /etc/motd1.
- index.html – La nota di riscatto in formato HTML che sostituirà la pagina iniziale di VMware ESXi. Il file originale del server verrà copiato in index1.html nella stessa cartella.
Michael Gillespie di ID Ransomware ha analizzato l’encryptor e ha dichiarato che la cifratura è, purtroppo, sicura, il che significa che nessun bug nella crittografia ne può consentire la decrittazione.
“Il file public.pem rilevato è una chiave pubblica RSA (la mia ipotesi è RSA-2048 in base all’esame dei file crittografati, ma il codice tecnicamente accetta qualsiasi PEM valido)”, ha scritto Gillespie. “Per il file da crittografare, [il ransomware] genera 32 byte utilizzando il CPRNG sicuro RAND_pseudo_bytes di OpenSSL, e questa chiave viene poi utilizzata per crittografare il file utilizzando Sosemanuk, un cifrario a flusso sicuro. La chiave del file viene crittografata con RSA (RSA_public_encrypt di OpenSSL) e aggiunta alla fine del file”.
Similitudini con malware preesistente
“L’uso dell’algoritmo Sosemanuk è piuttosto singolare e di solito viene utilizzato solo nei ransomware derivati dal codice sorgente di Babuk (variante ESXi). Forse è proprio questo il caso, ma è stato modificato per utilizzare RSA invece dell’implementazione Curve25519 di Babuk”.
Questa analisi indica che ESXiArgs è probabilmente basato sul codice sorgente di Babuk trapelato, che è stato precedentemente utilizzato da altre campagne di ransomware ESXi, come CheersCrypt e l’encryptor PrideLocker del gruppo Quantum/Dagon.
Mentre la nota di riscatto per ESXiArgs e Cheerscrypt sono molto simili, il metodo di crittografia è diverso, il che rende poco chiaro se si tratta di una nuova variante o solo di una base di codice Babuk condivisa.
Inoltre, non sembra essere collegato a Nevada Ransomware, come precedentemente indicato da OVHcloud.
Processo di injecting
L’encryptor viene eseguito da un file di shell script che lo lancia con vari argomenti a riga di comando, tra cui:
- il file della chiave pubblica RSA,
- il file da crittografare,
- i pezzi di dati che non verranno crittografati,
- la dimensione di un encryption block,
- la dimensione del file.
Uso:
encrypt <chiave_pubblica> <file_da_criptare> [<enc_step>] [<enc_size>] [<dimensione_file>]
# enc_step - numero di MB da saltare durante la cifratura
# enc_size - numero di MB nell'encryption block
# file_size - dimensione del file in byte (per file sparsi)
Questo encryptor viene lanciato tramite lo shell script encrypt.sh che agisce come base logica dell’attacco, che descriveremo brevemente di seguito.
Quando viene lanciato, lo script esegue il seguente comando per modificare i file di configurazione della macchina virtuale ESXi (.vmx) in modo che le stringhe ‘.vmdk’ e ‘.vswp’ vengano cambiate in ‘1.vmdk’ e ‘1.vswp’.
Lo script termina quindi tutte le macchine virtuali in esecuzione forzando la terminazione (kill -9) di tutti i processi contenenti la stringa ‘vmx’ in modo simile a questo articolo di supporto VMware.
Successivamente, lo script usa il comando “esxcli storage filesystem list | grep "/vmfs/volumes/" | awk -F' ' '{print $2}” per avere una lista dei volumi ESXi.
Lo script cerca poi nei volumi per trovare file che corrispondano alle seguenti estensioni:
.vmdk
.vmx
.vmxf
.vmsd
.vmsn
.vswp
.vmss
.nvram
.vmemPer ogni file trovato, lo script creerà un file [nome_file].args nella stessa cartella, che contiene il “size step” calcolato (come mostrato in figura), ‘1’ e la dimensione del file.
Ad esempio, server.vmx avrà un file server.vmx.args associato.
Lo script utilizzerà quindi l’eseguibile “encrypt” per crittografare i file in base ai parametri calcolati, come mostrato nella schermata seguente.
Dopo la cifratura, lo script sostituisce il file ESXi index.html e il file motd[1] del server con le note di riscatto, come descritto in precedenza.
Deception del malware installato
Infine, lo script esegue alcune operazioni di pulizia, rimuovendo quella che sembra essere una backdoor installata in /store/packages/vmtools.py [VirusTotal] ed eliminando varie righe dai seguenti file:
/var/spool/cron/crontabs/root
/bin/hostd-probe.sh
/etc/vmware/rhttpproxy/endpoints.conf
/etc/rc.local.d/local.sh
Questa pulizia e la presenza di /store/packages/vmtools.py sono indizi plausibili di una potenziale backdoor Python personalizzata per il server ESXi, come quella individuata da Juniper nel dicembre 2022.
Tutti gli amministratori di sistema dovrebbero verificare l’esistenza di questo file vmtools.py per assicurarsi che sia stato rimosso. Se viene trovato, il file andrebbe rimosso immediatamente.
Infine, lo script esegue /sbin/auto-backup.sh per aggiornare la configurazione salvata nel file /bootbank/state.tgz e avvia SSH.
Riferimenti
| ↑1 | Message Of The Day, ossia il file visualizzato in homepage al momento del collegamento col server |
|---|
