Premessa
Nel marasma delle (dis)informazioni mediatiche sull’argomento ho notato come spesso si parla del problema e meno spesso di come questo funziona. Con questo articolo andrò, nella maniera più sintetica possibile, ad elencare come questo bug ad oggi viene sfruttato, calandoci il più possibile nelle fasi dell’attacco e quali sono le azioni di remediation che si possono mettere in campo per evitare di essere affetti da questa vulnerabilità (qua la POC).
Da quanto si può apprendere leggendo la cronaca di settore, esistono almeno un paio di varianti del ransomware le quali hanno modus operandi diversi: ovviamente descriverò quella sulla quale sono riuscito a mettere su le mani.
Come funziona
Gli attacchi prendono di mira le istanze prive di patch ed esposte su Internet sfruttando il bug descritto nella CVE-2021-21974: un “heap overflow” sulla componente OpenSLP di VMware ESXi che, se opportunamente sfruttata, porta all’esecuzione di codice arbitrario remoto da parte dell’attaccante.
Per dare un minimo di contesto, il Service Location Protocol (SLP) è un protocollo di monitoraggio degli standard IETF (Internet Engineering Task Force) che fornisce un framework per consentire alle applicazioni di rete di scoprire l’esistenza, la posizione e la configurazione dei servizi di rete.
Qua il link ufficiale se si vuole approfondire.
Reconnaissance
Inizialmente l’attaccante utilizza servizi online (a titolo di esempio: Shodan o Zoomeye) per cercare server ESXi esposti e se questi hanno la porta 427 – attiva di default su VMware – pubblicata. Altra modalità, l’attaccante scopre il servizio accessibile scansionano il perimetro esposto dell’azienda.
Accesso iniziale
L’attaccante utilizza un bug nel servizio SLP implementato su VMWare dovuto al fatto che questo analizza l’input senza autenticazione ed esegue il comando come root. Una volta eseguiti questi passaggi, un utente malintenzionato è in grado di eseguire codice arbitrario da remoto, una RCE appunto.
Esecuzione
Quando il server viene violato, i seguenti file vengono salvati nella cartella /tmp del server:
- encrypt – l’eseguibile ELF atto a criptare i file
- encrypt.sh – uno script che funge da logica per l’attacco, eseguendo varie attività prima di lanciare il cryptolocker
- public.pem – chiave RSA pubblica utilizzata per cifrare la chiave di crittografia dei file
- motd – la nota di riscatto in formato testo che verrà copiata in /etc/motd in modo che venga mostrata all’accesso via SSH. Il file originale del server verrà copiato in /etc/motd1
- index.html – La nota di riscatto in formato HTML che sostituirà la home page di VMware ESXi. Il file originale del server verrà copiato in index1.html nella stessa cartella
Persistenza
L’attaccante installa una backdoor (scritta in Python) nella directory /store/packages/vmtools.py
Lo script avvia un semplice server Web che accetta richieste POST protette da password e può essere utilizzato in due modi: può eseguire comandi remoti e visualizzare i risultati come una pagina web oppure può avviare una reverse shell sull’host colpito.
Impatto
Il ransomware viene avviato utilizzando il file di script precedentemente descritto, successivamente seguono queste azioni:
- lo script esegue un comando per modificare le stringhe “.vmdk” e “.vswp” nei file di configurazione della macchina virtuale (.vmx) in “1.vmdk” e “1.vswp”. Questa azione forza la terminazione di tutti i processi che contengono la stringa “vmx” con la conseguente terminazione tutte le macchine virtuali in esecuzione
- lo script elenca tutti i volumi presenti sul server
- per ogni file trovato (.vmxf, .vmx, .vmdk, .vmsd e .nvram) di ogni volume precedentemente ricavato, lo script creerà un file con estensione .args ed eseguirà l’eseguibile ELF il quale crittografa i file
- terminato il processo di crittografia lo script sostituirà le note di riscatto nei file index.html e motd
- Ultimo step, lo script rimuove la backdoor installata in /store/packages/vmtools.py ed elimina dai seguenti file le prove di accesso:
- /var/spool/cron/crontabs/root
- /bin/hostd-probe.sh
- /etc/vmware/rhttpproxy/endpoints.conf
- /etc/rc.local.d/local.sh
Identificazione della superficie esposta
- Sicuramente è bene controllare se le versioni ESXi precedenti alle versioni menzionate di seguito non sono esposte su Internet:
- ESXi70U1c-17325551
- ESXi670-202102401-SG
- ESXi650-202102101-SG
- Verificare che la porta 427/tcp non sia esposta su Internet (NB: il controllo è bene farlo direttamente tramite le configurazioni del firewall poiché la porta 427 non risponde direttamente)
- Eseguire una scansione sul proprio perimetro pubblico per identificare potenziali server ESXi esposti/vulnerabili
Remediation
Il consiglio più banale è quello di aggiornare gli host, se questo non fosse possibile allora VMWare propone di disabilitare il servizio SLP mediante questo workaround:
- collegarsi via SSH all’host
- fermare il servizio SLP col comando “/etc/init.d/slpd stop” (per controllare lo stato del demone usare “esxcli system slp stats ge“
- disabilitare il servizio all’avvio con “esxcli network firewall ruleset set -r CIMSLP -e 0“
Come al solito, per aumentare il perimetro di monitoraggio, si consiglia di inviare i log VMware al vostro SIEM: la procedura per l’inoltro dei syslog da WMWare è descritta a questo link e a quest’altro.
Se l’infrastruttura fosse già stata colpita dal ransomware si consiglia di leggere questo blog, potrebbe aiutare.
IoC / Indici di compromissione
- 104.152.52[.]55
- 193.163.125[.]138
- 43.130.10[.]173
- 143.42.0[.]74
- 110.21.25[.]36
- 162.243.140[.]14
- 198.199.97[.]19
Riferimenti
https://straightblast.medium.com/my-poc-walkthrough-for-cve-2021-21974-a266bcad14b9
https://www.vmware.com/security/advisories/VMSA-2021-0002.html
https://www.csa.gov.sg/singcert/Alerts/AL-2023-015
https://nvd.nist.gov/vuln/detail/CVE-2021-21974
https://www.csirt.gov.it/contenuti/vulnerabilita-su-prodotti-vmware-al03-210224-csirt-ita
EOF
Davvero molto chiaro, grazie 🙂
Grazie!