Analytici virů a výzkumníci počítačové bezpečnosti se předhánějí v tom, kdo shromáždí co nejvíce vzorků nových botnetů. Používají honeypoty pro své vlastní účely... Ale co když chcete pozorovat malware v reálných podmínkách? Vystavit svůj server nebo router riziku? Co když vhodné zařízení neexistuje? Právě tyto otázky mě přivedly k vytvoření bhunteru, nástroje pro získání přístupu k uzlům botnetu.
ústřední myšlenkou
Existuje mnoho způsobů, jak šířit malware za účelem rozšíření botnetů: od phishingu až po zneužívání nulových zranitelností. Ale nejběžnější metodou je stále hrubé vynucení SSH hesel.
Myšlenka je velmi jednoduchá. Pokud se nějaký uzel botnetu pokouší brutálně vynutit hesla pro váš server, pak byl s největší pravděpodobností tento uzel samotný zachycen jednoduchými hesly brutálního vynucení. To znamená, že k tomu, abyste k ní získali přístup, vám stačí oplácet.
Přesně tak funguje bhunter. Poslouchá port 22 (služba SSH) a shromažďuje všechna přihlašovací jména a hesla, pomocí kterých se k němu pokouší připojit. Poté se pomocí shromážděných hesel pokusí připojit k útočícím uzlům.
Algoritmus práce
Program lze rozdělit na 2 hlavní části, které pracují v samostatných vláknech. První je honeypot. Zpracovává pokusy o přihlášení, shromažďuje jedinečná přihlašovací jména a hesla (v tomto případě je dvojice login + heslo považována za jeden celek) a také přidává IP adresy, které se pokusily připojit do fronty pro další útok.
Druhá část je přímo zodpovědná za útok. Útok je navíc veden ve dvou režimech: BurstAttack (burst attack) – brutální přihlašovací jména a hesla z obecného seznamu a SingleShotAttack (single shot attack) – hrubá síla, která byla použita napadeným uzlem, ale dosud nebyla použita. přidán do obecného seznamu.
Aby bylo možné mít hned po spuštění alespoň nějakou databázi loginů a hesel, inicializuje se bhunter seznamem ze souboru /etc/bhunter/defaultLoginPairs.
rozhraní
Existuje několik způsobů, jak spustit bhunter:
Prostě jako tým
sudo bhunterS tímto spuštěním je možné ovládat bhunter prostřednictvím jeho textového menu: přidat přihlašovací jména a hesla pro útok, exportovat databázi přihlašovacích údajů a hesel, určit cíl pro útok. Všechny hacknuté uzly lze vidět v souboru /var/log/bhunter/hacked.log
Pomocí tmux
sudo bhunter-ts # команда запуска bhunter через tmux
sudo tmux attach -t bhunter # подключаемся к сессии, в которой запущен bhunter
Tmux je terminálový multiplexer, velmi pohodlný nástroj. Umožňuje vytvořit několik oken v rámci jednoho terminálu a rozdělit okna do panelů. Pomocí něj můžete opustit terminál a poté se přihlásit bez přerušení běžících procesů.
Skript bhunter-ts vytvoří relaci tmux a rozdělí okno na tři panely. První, největší, obsahuje textové menu. Vpravo nahoře jsou záznamy o honeypotu, zde vidíte zprávy o pokusech o přihlášení do honeypotu. V pravém dolním panelu se zobrazují informace o průběhu útoku na uzly botnetu a o úspěšných hackech.
Výhodou této metody oproti první je, že můžeme terminál bezpečně zavřít a vrátit se k němu později, aniž by bhunter zastavil jeho práci. Pro ty, kteří jsou málo obeznámeni s tmux, doporučuji .
Jako služba
systemctl enable bhunter
systemctl start bhunterV tomto případě povolíme automatické spouštění bhunter při startu systému. V této metodě není poskytována interakce s bhunter a seznam hacknutých uzlů lze získat z /var/log/bhunter/hacked.log
Účinnost
Při práci na bhunteru se mi podařilo najít a získat přístup k úplně jiným zařízením: raspberry pi, routerům (zejména mikrotik), webovým serverům a kdysi těžební farmě (bohužel přístup k ní byl přes den, takže žádné zajímavé příběh). Zde je snímek obrazovky programu, který zobrazuje seznam hacknutých uzlů po několika dnech práce:
Bohužel efektivita tohoto nástroje nedosáhla mých očekávání: bhunter může zkoušet hesla do uzlů několik dní bez úspěchu a dokáže hacknout několik cílů za pár hodin. Na pravidelný příliv nových vzorků botnetů to ale stačí.
Efektivitu ovlivňují parametry jako: země, ve které se server s bhunter nachází, hosting a rozsah, ze kterého je IP adresa přidělována. Z mé zkušenosti se stal případ, kdy jsem si pronajal dva virtuální servery od jednoho hostitele a jeden z nich byl napaden botnety 2x častěji.
Chyby, které jsem ještě neopravil
Při napadení infikovaných hostitelů není v některých situacích možné jednoznačně určit, zda je heslo správné či nikoliv. Takové případy jsou zaznamenány v souboru /var/log/debug.log.
Modul Paramiko, který se používá pro práci s SSH, se někdy chová nesprávně: nekonečně čeká na odpověď od hostitele, když se k němu pokouší připojit. Experimentoval jsem s časovači, ale nedosáhl jsem požadovaného výsledku
Na čem je ještě potřeba zapracovat?
Název služby
Podle RFC-4253 si klient a server před instalací vyměňují názvy služeb, které implementují protokol SSH. Tento název je obsažen v poli „NÁZEV SLUŽBY“ obsaženém v požadavku ze strany klienta i v odpovědi ze strany serveru. Pole je řetězec a jeho hodnotu lze zjistit pomocí wireshark nebo nmap. Zde je příklad pro OpenSSH:
$ nmap -p 22 ***.**.***.** -sV
Starting Nmap ...
PORT STATE SERVICE VERSION
22/tcp open ssh <b>OpenSSH 7.9p1 Debian 10+deb10u2</b> (protocol 2.0)
Nmap done: 1 IP address (1 host up) scanned in 0.47 seconds
V případě Paramiko však toto pole obsahuje řetězec jako „Paramiko Python sshd 2.4.2“, který může zastrašit botnety, které jsou navrženy tak, aby se „vyhýbaly“ pastím. Proto si myslím, že je potřeba tuto řadu nahradit něčím neutrálnějším.
Jiné vektory
SSH není jediným prostředkem vzdálené správy. Existuje také telnet, rdp. Stojí za to se na ně podívat blíže.
prodloužení
Bylo by skvělé mít několik pastí v různých zemích a centrálně z nich shromažďovat přihlašovací jména, hesla a hacknuté uzly do společné databáze
Kde stáhnout?
V době psaní tohoto článku je připravena pouze testovací verze, kterou lze stáhnout .
Zdroj: www.habr.com