Analytici a výzkumníci v oblasti kybernetické bezpečnosti se snaží shromáždit co nejvíce vzorků nových botnetů. K tomu využívají honeypoty.… Ale co když chceme sledovat škodlivý kód v reálných podmínkách? Postavit do risku svůj server, router? A co když vhodné zařízení není k dispozici? Právě tyto otázky mě přivedly k vytvoření bhunter — nástroje pro získání přístupu k uzlům botnetů.

Hlavní myšlenka

Existuje mnoho způsobů, jak šířit škodlivý software pro rozšiřování botnetů: od phishingu až po využívání 0-day zranitelností. Ale nejběžnějším metodou zůstává stále hádání hesel pro SSH.

Myšlenka je velmi jednoduchá. Pokud se z nějakého uzlu botnetu pokoušíte o hádání hesel k vašemu serveru, pravděpodobně tento uzel také padl do pasti při hádání jednoduchých hesel. A to znamená, že abyste získali přístup, musíte mu prostě vrátit "dvěma rukama".

Přesně tak funguje bhunter. Naslouchá na portu 22 (SSH služba) a shromažďuje všechny pokusy o připojení a hesla. Poté se pokouší připojit k útočným uzlům s použitím shromážděných hesel.

Algoritmus práce

Program lze zjednodušeně rozdělit na dvě hlavní části, které běží v samostatných vláknech. První část — honeypot. Zpracovává pokusy o přihlášení, shromažďuje unikátní loginy a hesla (v tomto případě je pár login+heslo považován za celek) a také přidává do fronty IP adresy, které se pokoušely připojit, pro další útok.

Druhá část je přímo zodpovědná za útok. Útok se provádí ve dvou režimech: BurstAttack (útok frontou) — hádání loginů a hesel ze společného seznamu a SingleShotAttack (útok jednotlivými výstřely) — hádání hesel, které byly použity útočícím uzlem, ale ještě nebyly přidány do společného seznamu.

Aby měl bhunter nějakou základnu loginů a hesel ihned po spuštění, inicializuje se pomocí seznamu z souboru /etc/bhunter/defaultLoginPairs.

Rozhraní

Existuje několik způsobů, jak spustit bhunter:

Jednoduše příkazem

sudo bhunter

Při tomto spuštění je možné ovládat bhuntera přes jeho textové menu: přidávat přihlašovací údaje pro útok, exportovat databázi přihlašovacích údajů, určit cíl útoku. Všechny napadené uzly lze vidět v souboru /var/log/bhunter/hacked.log

Použití tmux

sudo bhunter-ts # příkaz pro spuštění bhuntera přes tmux  
sudo tmux attach -t bhunter # připojíme se k relaci, ve které je spuštěn bhunter

Tmux je terminálový multiplexor, velmi užitečný nástroj. Umožňuje v rámci jednoho terminálu vytvářet více oken a okna rozdělovat na panely. Jeho použitím lze opustit terminál a poté se vrátit, aniž by došlo k přerušení běžících procesů.

Skript bhunter-ts vytvoří tmux relaci a rozděluje okno na tři panely. V prvním — největším, se nachází textové menu. V pravém horním panelu jsou logy honeypotu, zde lze vidět zprávy o pokusech o přihlášení na honeypot. V dolním pravém panelu se zobrazují informace o průběhu útoku na uzly botnetů a o úspěšných prolomeních.

Výhoda tohoto způsobu oproti prvnímu spočívá v tom, že můžeme klidně zavřít terminál a vrátit se k němu později, přičemž bhunter nezastaví svou činnost. Těm, kteří se s tmuxem moc nesetkali, nabízím tuto příručku.

Jako služba

systemctl enable bhunter
systemctl start bhunter

V tomto případě zapínáme autostart bhuntera při spuštění systému. V tomto způsobu není s bhunterem předpokládáno žádné interakce, ale seznam napadených uzlů lze získat z /var/log/bhunter/hacked.log

Efektivita

Během práce na bhunterovi se mi podařilo najít a získat přístup k různým zařízení: raspberry pi, routery (zejména mikrotik), webové servery, a jednou i na farmu na těžbu (bohužel přístup k ní byl pouze na jeden den, takže z toho nevznikla žádná zajímavá historka). Zde je screenshot programu, na kterém je vidět seznam napadených uzlů po několika dnech práce:

Bohužel účinnost tohoto nástroje nedosáhla mých očekávání: bhunter může zkoušet hesla na uzlech několik dní bez výsledku, ale také může prolomit několik cílů za pár hodin. Ale pro pravidelný přísun nových vzorků botnetů je to dostatečné.

Na účinnost mají vliv parametry jako: země, ve které se nachází server s bhunter, hosting a rozsah, ze kterého je přidělená IP adresa. Z mé zkušenosti byl případ, kdy jsem si pronajal dva virtuální servery od jednoho poskytovatele a jeden z nich byl vystaven útokům ze strany botnetů dvakrát častěji.

Chyby, které zatím nemám opravené

Při útoku na nakažené uzly v některých situacích nelze jednoznačně určit, zda byl zvolený heslo správné. Zaznamenávání takových případů probíhá v souboru /var/log/debug.log.

Modul Paramiko, který se používá pro práci s SSH, se někdy chová nesprávně: dochází k nekonečnému čekání na odpověď od uzlu, když se pokouší připojit. Experimentoval jsem s časovači, ale nedosáhl jsem požadovaného výsledku.

Na čem je ještě třeba pracovat?

Název služby

Podle RFC-4253 si klient a server před následnou implementací vyměňují názvy služeb, které realizují protokol SSH. Tento název se nachází v poli „SERVICE NAME“, které je obsaženo jak v žádosti ze strany klienta, tak v odpovědi ze strany serveru. Pole představuje řetězec a jeho hodnotu lze zjistit pomocí wiresharku nebo nmapu. Zde je příklad pro OpenSSH:

$ nmap -p 22 ***.**.***.** -sV
Zahájení Nmap ...
PORT   STAV SLUŽBA VERZE
22/tcp otevřen  ssh     <b>OpenSSH 7.9p1 Debian 10+deb10u2</b> (protokol 2.0)
Nmap dokončeno: 1 IP adresa (1 host aktivní) proskenována za 0.47 sekund

V případě Paramiko ale toto pole obsahuje řetězec ve tvaru „Paramiko Python sshd 2.4.2“, což může odradit botnety, které mají v sobě zabudováno „vyhýbání se“ pastem. Proto považuji za nezbytné nahradit tento řetězec něčím neutrálnějším.