Virusanalytiker och forskare inom datasäkerhet strävar efter att samla så många prover av nya botnät som möjligt. I sina syften använder de honeypots... Men vad om man vill observera skadlig kod under verkliga förhållanden? Sätta sin server eller router i riskzonen? Och vad om det inte finns någon lämplig enhet? Just dessa frågor ledde mig till skapandet av bhunter — ett verktyg för att få tillgång till noder i botnät.

Huvudidén

Det finns många sätt att sprida skadlig programvara för att utöka botnät: från phishing till utnyttjande av 0-day-sårbarheter. Men den mest utbredda metoden är fortfarande brute force-attacker mot SSH-lösenord.

Idén är mycket enkel. Om något node från botnätet försöker göra en brute force-attack mot din server, är det troligt att den noden själv har blivit övertagen genom att utnyttja enkla lösenord. Det betyder att för att få tillgång till den, behöver man bara svara med "ömsesidighet".

Så här fungerar bhunter. Den lyssnar på port 22 (SSH-tjänst) och samlar alla inloggningar och lösenord som försöker ansluta. Därefter, med hjälp av de insamlade lösenorden, försöker den ansluta till angripande noder.

Arbetsalgoritm

Programmet kan grovt delas in i två huvuddelar som arbetar i separata trådar. Den första — honeypot. Den hanterar inloggningsförsök, samlar unika användarnamn och lösenord (i detta fall betraktas en inloggning+lösenord-kombination som en helhet) och lägger till IP-adresser i kön för vidare attacker som försökte ansluta.

Den andra delen ansvarar direkt för attacken. Attacken utförs i två lägen: BurstAttack (köattack) — brute force av användarnamn och lösenord från en gemensam lista och SingleShotAttack (enskilda skott) — brute force av lösenord som för användaren under attacken, men som ännu inte har lagts till i den gemensamma listan.

För att ha någon grund av användarnamn och lösenord direkt efter start, initieras bhunter med en lista från filen /etc/bhunter/defaultLoginPairs.

Gränssnitt

Flertalet sätt att starta bhunter är förutsedda:

Bara med kommandot

sudo bhunter

Vid sådan start finns det möjlighet att styra bhunter genom dess textmeny: lägga till användarnamn och lösenord för attack, exportera databasen med användarnamn och lösenord, ange målet för attacken. Alla hackade noder kan ses i filen /var/log/bhunter/hacked.log

Genom att använda tmux

sudo bhunter-ts # kommand för att starta bhunter via tmux  
sudo tmux attach -t bhunter # anslut till sessionen där bhunter körs

Tmux är en terminalmultiplexer, ett mycket användbart verktyg. Det gör det möjligt att skapa flera fönster inom en terminal och dela upp fönster i paneler. Genom att använda det kan man logga ut från terminalen och sedan logga in igen utan att avbryta pågående processer.

Skriptet bhunter-ts skapar en tmux-session och delar fönstret i tre paneler. I den första – den största – finns det textmeny. Den övre högra panelen innehåller loggar från honeypoten, där man kan se meddelanden om inloggningsförsök. I den nedre högra panelen visas information om attackens gång på botnets-noder och om lyckade intrång.

Fördelen med detta tillvägagångssätt jämfört med det första är att vi kan stänga terminalen och återvända senare, och bhunter kommer att fortsätta fungera. För dem som är obekanta med tmux föreslår jag denna snabbguide.

Som en tjänst

systemctl enable bhunter
systemctl start bhunter

I det här fallet aktiverar vi automatisk start av bhunter vid systemstart. I denna metod är interaktionen med bhunter inte möjlig, och listan över hackade noder kan fås från /var/log/bhunter/hacked.log

Effektivitet

Under min tid med bhunter har jag lyckats hitta och få tillgång till helt olika enheter: raspberry pi, routrar (särskilt mikrotik), webbservrar, och en gång en gruvgård (tyvärr var tillgången endast under en dag, så jag fick ingen intressant historia). Här är en skärmdump av programmet som visar listan över hackade noder efter några dagars arbete:

Tyvärr har effektiviteten hos detta verktyg inte uppfyllt mina förväntningar: bhunter kan pröva lösenord till noder i flera dagar utan resultat, men kan också hacka flera mål på några timmar. Men för en regelbunden tillströmning av nya exempel på botnät är detta tillräckligt.

Effektiviteten påverkas av faktorer såsom: landet där servern med bhunter är placerad, hostingtjänsten och intervallet från vilket IP-adressen tilldelas. Utifrån min erfarenhet har jag haft fall där jag hyrde två virtuella servrar från samma hostingleverantör, och en av dem utsattes för attacker från botnät dubbelt så ofta.

Buggar som jag fortfarande inte har fixat

Vid attacker mot infekterade noder går det ibland inte att tydligt avgöra om lösenordet var rätt eller ej. Loggning av sådana fall sker i filen /var/log/debug.log.

Paramiko-modulen, som används för att arbeta med SSH, beter sig ibland inkonsekvent: den hamnar i en oändlig väntan på svar från noden när den försöker ansluta. Jag har experimenterat med timers, men har inte fått det resultat jag önskat.

Vad mer återstår att arbeta med?

Tjänstnamn

Enligt RFC-4253 utbyter klienten och servern tjänstenamn som implementerar SSH-protokollet före etableringen. Detta namn finns i fältet "SERVICE NAME", som ingår både i begäran från klienten och i svaret från servern. Fältet är en sträng, och dess värde kan upptäckas med hjälp av Wireshark eller Nmap. Här är ett exempel för OpenSSH:

$ nmap -p 22 ***.**.***.** -sV
Startar Nmap ...
PORT   STATUS TJÄNST VERSION
22/tcp öppen  ssh     <b>OpenSSH 7.9p1 Debian 10+deb10u2</b> (protokoll 2.0)
Nmap klart: 1 IP-adress (1 värd uppe) skannad på 0.47 sekunder

Men när det gäller Paramiko innehåller detta fält en sträng som ser ut som "Paramiko Python sshd 2.4.2", vilket kan avskräcka botnät som har byggt in "undvikande" av fällor. Därför anser jag att det är nödvändigt att byta ut denna sträng till något mer neutralt.