Attacco a VMware ESXi: perché quello che è successo è un film già visto

Un film già visto: realtà aziendali che non aggiornano un componente cruciale utilizzato all’interno della loro infrastruttura e gruppi di criminali che sfruttano le vulnerabilità irrisolte per lanciare un attacco informatico.
Nel corso del fine settimana che ci siamo appena posti alle spalle, tante testate si sono affrettate a parlare di “guerra cibernetica” per descrivere quanto accaduto.
In realtà ciò che è successo non è un “unicum” ed anzi è qualcosa che avviene ogni giorno a qualsiasi livello.

VMware ESXi è un hypervisor (bare-metal) che viene utilizzato per la creazione e la gestione di macchine virtuali in ambito business. Come altre soluzioni per la virtualizzazione, VMware ESXi consente di eseguire più sistemi operativi su un unico host fisico isolando le macchine virtuali l’una dall’altra e condividendo le risorse hardware messe a disposizione dal “sistema ospitante”.
Si tratta di un approccio che ottimizza l’utilizzo dell’hardware e migliora la flessibilità dell’infrastruttura IT poiché le macchine virtuali e i sistemi operativi installati su ciascuna di esse possono essere facilmente spostati o modificati senza influire sugli altri.

Questa volta è successo che alcuni aggressori informatici hanno sviluppato e distribuito in rete ESXiArgs, un ransomware che sfrutta una vulnerabilità insita nelle versioni non aggiornate di VMware ESXi per crittografare i dati delle vittime.
Nello specifico il componente malevolo prende di mira i file con estensioni .vmxf, .vmx, .vmdk, .vmsd e .nvram sui server ESXi compromessi e crea un file .args per ogni documento crittografato insieme con una serie di metadati, probabilmente necessari per l’eventuale decodifica a riscatto pagato.
I formati di file bersagliati sono proprio quelli che hanno strettamente a che fare con il funzionamento delle macchine virtuali.

Il fatto è che la vulnerabilità sfruttata dal ransomware ESXiArgs(CVE-2021-21974) è stata risolta da VMware già a febbraio 2021: per ben due anni, quindi, le imprese che sono state oggi aggredite si sono astenute dall’installare patch critiche per una piattaforma e un servizio cruciali.
Il problema di sicurezza era stato descritto come critico proprio da VMware che esortava i clienti a installare le patch correttive nel più breve tempo possibile. Certo, l’installazione degli aggiornamenti avrebbe comunque provocato una breve interruzione dei servizi forniti attraverso le macchine virtuali ma programmando gli interventi fuori dagli orari di ufficio, ad esempio in notturna, si sarebbero potuti evitare i danni più gravi.

Inoltre, se in questo caso la lacuna riguarda l’implementazione di SLP, protocollo (Service Location Protocol) che consente di trovare servizi sulla rete come database, server di stampa senza conoscere l’indirizzo IP o il nome dell’host, ed è molto semplice da sfruttare, sappiamo già che esistono diverse vulnerabilità aggiuntive che VMware ha corretto nel 2022 e che tante realtà potrebbero avere a questo punto dimenticato di correggere: falle come CVE-2022-31696, CVE-2022-31697, CVE-2022-31698 e CVE-2022-31699 possono portare all’esecuzione di codice in modalità remota (RCE, Remote Code Execution).

Secondo una ricerca Censys, circa 3.200 server VMware ESXi in tutto il mondo sono stati compromessi nella campagna ransomware ESXiArgs.
Barracuda Networks fa genericamente riferimento, in una nota diramata quest’oggi, a “diverse migliaia di server (in più di 300 organizzazioni) in tutta Europa e nel mondo“.

Ad essere utilizzata per l’attacco è la porta 427, impiegata dal protocollo SLP: tale porta non dovrebbe essere esposta sulla WAN e come ricordavano sia IBM che, per esempio, Speedguide l’aggressione tipicamente ha origine dallo stesso segmento di rete sulla quale si affaccia la porta 427 di VMware ESXi. Al solito, quindi, è verosimile che l’aggressione ransomware sia cominciata molto prima, ad esempio da un sistema gestito da un dipendente aziendale.

D’altra parte Stefan van der Wal, Consulting Solutions Engineer, EMEA, Application Security di Barracuda Networks aggiunge: “ecco perché è particolarmente importante far sì che l’accesso alla console di gestione di un sistema virtuale sia protetto e non possa essere facilmente raggiungibile attraverso, ad esempio, un account compromesso sulla rete aziendale“.

Per questo sono necessarie soluzioni per proteggere server e workstation dagli attacchi informatici utilizzando un pannello che dia visibilità sui problemi rilevati e sugli aspetti che necessitano di interventi urgenti.

Soltanto l’utilizzo di un solido meccanismo di patch management avrebbe permesso di individuare per tempo il problema dei sistemi VMware ESXi non aggiornati ponendovi soluzione in tempo utile.
Inoltre, poiché gli attacchi si sono verosimilmente originati sulle workstation di utenti e collaboratori, i malintenzionati hanno potuto avere gioco facile laddove non venivano utilizzate soluzioni UTM (Unified Threat Management) o non risultavano adeguate per fornire un livello minimo di protezione.

L’incidente che ha interessato alcune migliaia di macchine basate su VMware ESXi si sarebbe potuto semplicemente evitare con l’adozione di un’adeguata policy per l’installazione delle patch di sicurezza. Nessuna “guerra cibernetica”, quindi, come in tanti purtroppo hanno fatto presente, ma una gestione di alcune infrastrutture IT assolutamente inadeguata: “è importante aggiornare i principali sistemi di infrastruttura software il più rapidamente possibile, sebbene non si tratti di un’operazione facile per le organizzazioni“, osserva ancora van der Wal (Barracuda Networks). “Nel caso di questa patch, ad esempio, le aziende devono disattivare temporaneamente parti essenziali della loro infrastruttura IT. Tuttavia, è preferibile affrontare questo tipo di inconveniente piuttosto che essere colpiti da un attacco potenzialmente distruttivo“.

Gli sviluppatori software, diciamo noi, dovrebbero dal canto loro puntare sempre più anche sul patching in-memory per consentire la risoluzione delle vulnerabilità di sicurezza, almeno nelle situazioni emergenziali, senza bisogno di riavviare le macchine.

Nel frattempo CISA (Cybersecurity and Infrastructure Security Agency) ha rilasciato e pubblicato su GitHub lo script ESXiArgs-Recover che aiuta le vittime del ransomware ad automatizzare il processo di ripristino delle macchine virtuali.
In breve, lo script rimuove i file crittografati dal ransomware quindi tenta di ricostruire il file .vmdk della macchina virtuale utilizzando il file flat non crittografato. Al termine dell’operazione, in caso di successo, è possibile registrare nuovamente la macchina virtuale in VMware ESXi per ottenere nuovamente l’accesso alla stessa.