Gli analisti dei virus e i ricercatori di sicurezza informatica cercano di raccogliere il maggior numero possibile di campioni di nuovi botnet. Per i loro scopi, utilizzano honeypot... Ma cosa succede se si desidera osservare il malware in condizioni reali? Esporre il proprio server o router? E se non c'è un dispositivo adatto? Proprio queste domande mi hanno spinto a creare bhunter, uno strumento per accedere ai nodi delle botnet.

L'idea principale

Esistono molti modi per diffondere malware e ampliare le botnet: dal phishing all'utilizzo di vulnerabilità 0-day. Ma il metodo più comune rimane ancora oggi l'attacco brute force alle password SSH.

L'idea è molto semplice. Se da qualche nodo della botnet viene effettuato un brute force contro il tuo server, è probabile che quel nodo sia stato stesso compromesso da un attacco brute force su password semplici. Pertanto, per ottenerne l'accesso, è sufficiente rispondere con "una cortesia".

È proprio così che funziona bhunter. Ascolta sulla porta 22 (servizio SSH) e raccoglie tutti i login e le password con cui si prova a connettersi. Poi, utilizzando le password raccolte, tenta di collegarsi ai nodi degli aggressori.

Algoritmo di funzionamento

Il programma può essere fondamentalmente diviso in 2 parti principali, che funzionano in thread separati. La prima è honeypot. Gestisce i tentativi di accesso, raccoglie login e password unici (in questo caso, una coppia login+password è considerata come un'unità), e aggiunge all'elenco per ulteriori attacchi gli indirizzi IP che hanno tentato di connettersi.

La seconda parte è responsabile dell'attacco stesso. Inoltre, l'attacco avviene in due modalità: BurstAttack (attacco a coda) — attacco con brute force su login e password da un elenco comune e SingleShotAttack (attacco a singoli colpi) — brute force sulle password utilizzate dal nodo attaccato, ma che non sono ancora state aggiunte all'elenco comune.

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

Document

Sono previste diverse modalità di avvio di bhunter:

Semplicemente con il comando

sudo bhunter

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

Utilizzando tmux

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

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

Lo script bhunter-ts crea una sessione tmux e suddivide la finestra in tre pannelli. Nella prima, la più grande, si trova un 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 la situazione degli attacchi ai nodi delle botnet e le violazioni riuscite.

Il vantaggio di questo metodo rispetto al primo è che possiamo tranquillamente chiudere il terminale e tornare in un secondo momento, con bhunter che continua a funzionare. A chi è poco familiare con tmux consiglio questa guida.

As a service

systemctl enable bhunter
systemctl start bhunter

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

Efficienza

Durante il mio lavoro su bhunter sono riuscito a trovare e accedere a dispositivi molto diversi: raspberry pi, router (soprattutto mikrotik), server web, e una volta anche a una farm di mining (sfortunatamente l'accesso è durato solo un giorno, quindi non ho potuto raccogliere storie interessanti). Ecco uno screenshot del programma, dove si vede l'elenco dei nodi violati dopo alcuni giorni di lavoro:

Sfortunatamente, l'efficacia di questo strumento non ha soddisfatto le mie aspettative: bhunter può provare a indovinare le password dei nodi per diversi giorni senza successo, o può violare più obiettivi in poche ore. Ma per un afflusso regolare di nuovi campioni di botnet, questo è sufficiente.

L'efficacia è influenzata da parametri come: il paese in cui si trova il server con bhunter, l'hosting, e l'intervallo da cui è assegnato l'indirizzo IP. Nella mia esperienza, c'è stato un caso in cui ho affittato due server virtuali dallo stesso provider, e uno di essi era attaccato da botnet il doppio delle volte.

Bug che non ho ancora corretto

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

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

Su cosa altro bisogna lavorare?

Nome del servizio

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

$ nmap -p 22 ***.**.***.** -sV
Avvio di 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, che sono programmati per "evitare" trappole. Pertanto, ritengo necessario sostituire questa stringa con qualcosa di più neutro.

Altri vettori

SSH non è il solo strumento di gestione remota. Ci sono anche telnet, rdp. Vale la pena darci un'occhiata.

Estensione

Sarebbe interessante avere alcune trappole in diverse nazioni e raccogliere centralmente login, password e nodi compromessi in un'unica base dati.

Dove scaricare?

Al momento della scrittura dell'articolo, è disponibile solo una versione di prova, che può essere scaricata da repository su Github.

Fonte: habr.com