Virusanalytiker och datasäkerhetsforskare tävlar om att samla in så många prover av nya botnät som möjligt. De använder honungskrukor för sina egna syften... Men vad händer om du vill observera skadlig programvara i verkliga förhållanden? Utsätta din server eller router i fara? Vad händer om det inte finns någon lämplig enhet? Det var dessa frågor som fick mig att skapa bhunter, ett verktyg för att få tillgång till botnätsnoder.
central idé
Det finns många sätt att sprida skadlig programvara för att utöka botnät: från nätfiske till att utnyttja 0-dagars sårbarheter. Men den vanligaste metoden är fortfarande brute-forcing SSH-lösenord.
Tanken är väldigt enkel. Om någon botnätsnod försöker brute-force lösenord för din server, är det troligtvis denna nod själv fångad av brute-force enkla lösenord. Det betyder att för att få tillgång till det, behöver du bara återgälda.
Det är precis så här bhunter fungerar. Lyssnar på port 22 (SSH-tjänst) och samlar in alla inloggningar och lösenord som de försöker ansluta till den med. Sedan, med hjälp av de insamlade lösenorden, försöker den ansluta till attackerande noder.
Arbetsalgoritm
Programmet kan delas upp i 2 huvuddelar, som fungerar i separata trådar. Den första är honungskruka. Bearbetar inloggningsförsök, samlar in unika inloggningar och lösenord (i det här fallet betraktas paret inloggning + lösenord som en enda helhet), och lägger även till IP-adresser som försökte ansluta till kön för ytterligare attack.
Den andra delen är direkt ansvarig för attacken. Dessutom utförs attacken i två lägen: BurstAttack (burst attack) - brute force-inloggningar och lösenord från den allmänna listan och SingleShotAttack (single shot attack) - brute force-lösenord som användes av den attackerade noden, men som ännu inte har blivit läggs till i den allmänna listan.
För att ha åtminstone en viss databas med inloggningar och lösenord direkt efter lanseringen, initieras bhunter med en lista från filen /etc/bhunter/defaultLoginPairs.
gränssnitt
Det finns flera sätt att starta bhunter:
Bara som ett team
sudo bhunterMed denna lansering är det möjligt att styra bhunter genom dess textmeny: lägg till inloggningar och lösenord för en attack, exportera en databas med inloggningar och lösenord, ange ett mål för en attack. Alla hackade noder kan ses i filen /var/log/bhunter/hacked.log
Använder tmux
sudo bhunter-ts # команда запуска bhunter через tmux
sudo tmux attach -t bhunter # подключаемся к сессии, в которой запущен bhunter
Tmux är en terminal multiplexer, ett mycket bekvämt verktyg. Låter dig skapa flera fönster inom en terminal och dela upp fönstren i paneler. Med den kan du avsluta terminalen och sedan logga in utan att avbryta pågående processer.
bhunter-ts-skriptet skapar en tmux-session och delar upp fönstret i tre paneler. Den första, största, innehåller en textmeny. Den övre högra delen innehåller honeypot-loggar, här kan du se meddelanden om försök att logga in i honeypot. Den nedre högra panelen visar information om framstegen för attacken på botnätsnoder och om framgångsrika hack.
Fördelen med den här metoden framför den första är att vi säkert kan stänga terminalen och återvända till den senare, utan att bhunter stoppar dess arbete. För de som är lite bekanta med tmux, föreslår jag .
Som en tjänst
systemctl enable bhunter
systemctl start bhunterI det här fallet aktiverar vi bhunter autostart vid systemstart. I den här metoden tillhandahålls inte interaktion med bhunter, och listan över hackade noder kan hämtas från /var/log/bhunter/hacked.log
effektivitet
När jag arbetade på bhunter lyckades jag hitta och få tillgång till helt andra enheter: raspberry pi, routrar (särskilt mikrotik), webbservrar och en gång en gruvfarm (tyvärr var tillgång till den under dagen, så det fanns inget intressant berättelse). Här är en skärmdump av programmet, som visar en lista över hackade noder efter flera dagars arbete:
Tyvärr nådde inte effektiviteten av detta verktyg mina förväntningar: bhunter kan prova lösenord till noder i flera dagar utan framgång och kan hacka flera mål på ett par timmar. Men detta räcker för ett regelbundet inflöde av nya botnätprover.
Effektiviteten påverkas av sådana parametrar som: landet där servern med bhunter är belägen, värd och intervallet från vilket IP-adressen tilldelas. Enligt min erfarenhet var det ett fall när jag hyrde två virtuella servrar från en värd, och en av dem attackerades av botnät två gånger oftare.
Buggar som jag inte har fixat än
När man attackerar infekterade värdar är det i vissa situationer inte möjligt att entydigt avgöra om lösenordet är korrekt eller inte. Sådana fall loggas i filen /var/log/debug.log.
Paramiko-modulen, som används för att arbeta med SSH, beter sig ibland felaktigt: den väntar oändligt på ett svar från värden när den försöker ansluta till den. Jag experimenterade med timers, men fick inte det önskade resultatet
Vad mer behöver jobbas på?
Service namn
Enligt RFC-4253 utbyter klienten och servern namn på tjänster som implementerar SSH-protokollet före installationen. Detta namn finns i fältet "SERVICE NAME", som finns både i begäran från klientsidan och i svaret från serversidan. Fältet är en sträng och dess värde kan hittas med wireshark eller nmap. Här är ett exempel för 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
Men i fallet med Paramiko innehåller detta fält en sträng som "Paramiko Python sshd 2.4.2", som kan skrämma bort botnät som är designade för att "undvika" fällor. Därför tror jag att det är nödvändigt att ersätta denna linje med något mer neutralt.
Andra vektorer
SSH är inte det enda sättet för fjärrhantering. Det finns även telnet, rdp. Det är värt att titta närmare på dem.
förlängning
Det skulle vara bra att ha flera fällor i olika länder och centralt samla inloggningar, lösenord och hackade noder från dem till en gemensam databas
Var kan jag ladda ner?
I skrivande stund är endast en testversion klar, som kan laddas ner från .
Källa: will.com