Gli analisti di virus e i ricercatori della sicurezza informatica si sforzano di raccogliere quanti più campioni possibile di nuovi botnet. A tal fine, utilizzano honeypot. Ma cosa fare se si desidera osservare il malware in condizioni reali? Esporre il proprio server o router al rischio? E se non si dispone del dispositivo giusto? Proprio queste domande mi hanno spinto a creare bhunter — uno strumento per accedere ai nodi delle reti bot.

L'idea principale

Esistono molti modi per diffondere malware e ampliare le botnet: a partire dal phishing fino all'esploitazione di vulnerabilità 0-day. Tuttavia, il metodo più comune rimane ancora l'attacco a forza bruta delle password SSH.

L'idea è molto semplice. Se da un certo nodo della botnet viene effettuato un attacco a forza bruta delle password al tuo server, è probabile che quel nodo sia stato a sua volta compromesso tramite la stessa tecnica. Pertanto, per accedervi, è sufficiente rispondere con la "reciprocità".

Questo è precisamente come funziona bhunter. Ascolta la porta 22 (servizio SSH) e raccoglie tutti i login e le password con cui si tenta di connettersi. Successivamente, utilizzando le password raccolte, cerca di connettersi ai nodi degli attaccanti.

Algoritmo operativo

Il programma può essere suddiviso condizionatamente in due parti principali, che operano in thread separati. La prima è honeypot. Gestisce i tentativi di accesso, raccoglie login e password unici (in questo caso, la coppia login+password è considerata come un'unica entità), e aggiunge nella coda per ulteriori attacchi gli indirizzi IP che hanno tentato di connettersi.

La seconda parte è direttamente responsabile dell'attacco. L'attacco viene eseguito in due modalità: BurstAttack (attacco in coda) - testando login e password da un elenco generale, e SingleShotAttack (attacco a colpi singoli) - testando le password che sono state utilizzate dal nodo attaccato, ma che non sono ancora state aggiunte all'elenco generale.

Per avere almeno una base di login e password subito dopo l'avvio, bhunter si inizializza con un elenco da un file /etc/bhunter/defaultLoginPairs.

Interfaccia

Sono previsti diversi modi per avviare bhunter:

Semplicemente con il comando

sudo bhunter

Con questo avvio, è possibile gestire bhunter tramite il suo menu testuale: aggiungere login e password per l'attacco, esportare il database di login e password, specificare un obiettivo per l'attacco. Tutti i nodi compromessi possono essere visualizzati nel file /var/log/bhunter/hacked.log

Usando tmux

sudo bhunter-ts # comando per avviare bhunter tramite tmux  
sudo tmux attach -t bhunter # ci colleghiamo alla sessione in cui è avviato bhunter

Tmux è un multiplexore terminale, uno strumento molto utile. Permette di creare più finestre all'interno di un unico terminale e di suddividere le finestre in pannelli. Usandolo, possiamo uscire dal terminale e rientrare senza interrompere i processi in esecuzione.

Lo script bhunter-ts crea una sessione tmux e divide la finestra in tre pannelli. Nel primo - il più grande, si trova il menu testuale. La parte superiore destra contiene i log del honeypot, dove è possibile vedere i messaggi sui tentativi di accesso al honeypot. Nel pannello in basso a destra viene visualizzata l'informazione sull'andamento dell'attacco ai nodi delle botnet e sui successi degli hack.

Il vantaggio di questo metodo rispetto al primo è che possiamo chiudere tranquillamente il terminale e tornare ad esso in seguito, senza interrompere il lavoro di bhunter. A chi è poco familiare con tmux consiglio questo promemoria.

Come servizio

systemctl enable bhunter
systemctl start bhunter

In questo caso, abilitiamo l'avvio automatico di bhunter all'avvio del sistema. In questo metodo non è prevista l'interazione con bhunter e l'elenco dei nodi compromessi può essere ottenuto da /var/log/bhunter/hacked.log

Efficienza

Durante il mio lavoro con bhunter sono riuscito a trovare e accedere a diversi dispositivi: raspberry pi, router (soprattutto mikrotik), server web, e una volta a una fattoria di mining (purtroppo l'accesso è durato solo un giorno, quindi non ci sono storie interessanti). Ecco uno screenshot del programma, in cui si vede l'elenco dei nodi compromessi dopo alcuni giorni di lavoro:

Purtroppo, l'efficacia di questo strumento non ha soddisfatto le mie aspettative: bhunter può tentare di indovinare le password dei nodi per diversi giorni senza risultati, mentre può compromettere diversi obiettivi in poche ore. Ma per un afflusso regolare di nuovi campioni di botnet, è sufficiente.

L'efficacia è influenzata da parametri come il paese in cui si trova il server con bhunter, l'hosting e l'intervallo da cui è stato assegnato l'indirizzo IP. Dalla mia esperienza, ho avuto un caso in cui ho affittato due server virtuali da un unico provider, e uno di essi era soggetto ad attacchi da parte di botnet due volte più frequentemente.

Bug che non ho ancora corretto

Durante un attacco a nodi compromessi, in alcune situazioni non è possibile determinare con certezza se la password sia corretta o meno. La registrazione di tali eventi è effettuata nel file /var/log/debug.log.

Il modulo Paramiko, che viene utilizzato per lavorare con SSH, a volte si comporta in modo errato: va in attesa infinita di una risposta dal nodo quando tenta di connettersi. Ho sperimentato con i timer, ma non ho ottenuto il risultato desiderato.

Su cosa devo ancora lavorare?

Nome del servizio

Secondo l'RFC-4253, il client e il server scambiano i nomi dei servizi che implementano il protocollo SSH prima di stabilire la connessione. Questo nome è contenuto nel campo "SERVICE NAME", presente sia nella richiesta del client che nella risposta del server. Il campo è una stringa, e il suo valore può essere scoperto utilizzando wireshark o nmap. Ecco un esempio per OpenSSH:

$ nmap -p 22 ***.**.***.** -sV
Avvio Nmap ...
PORT   STATO SERVIZIO VERSIONE
22/tcp aperto  ssh     <b>OpenSSH 7.9p1 Debian 10+deb10u2</b> (protocollo 2.0)
Nmap completato: 1 indirizzo IP (1 host attivo) scansionato in 0.47 secondi

Tuttavia, nel caso di Paramiko, questo campo contiene una stringa del tipo «Paramiko Python sshd 2.4.2», che potrebbe spaventare i botnet programmati per «evitare» trappole. Pertanto, ritengo necessario sostituire questa stringa con qualcosa di più neutro.