Virusanalytikere og it-sikkerhedsforskere stræber efter at indsamle så mange prøver af nye botnets som muligt. I deres mål bruger de honeypots.… Men hvad hvis man ønsker at observere skaden i virkelige forhold? At sætte sin egen server eller router på spil? Hvad hvis der ikke er nogen passende enheder? Netop disse spørgsmål fik mig til at skabe bhunter — et værktøj til at få adgang til noder i botnetværk.

Den grundlæggende idé

Der findes mange måder at sprede malware på for at udvide botnetværk: fra phishing til udnyttelse af 0-dags sårbarheder. Men den mest almindelige metode forbliver stadig brute-force angreb på SSH-adgangskoder.

Idéen er meget simpel. Hvis der fra en botnet-node udføres brute-force angreb på din server, er det sandsynligt, at denne node selv blev overtaget via brute-force angreb med enkle adgangskoder. Det betyder, at for at få adgang til den, skal man blot give "gensvar".

Og det er præcist, hvordan bhunter fungerer. Den lytter på port 22 (SSH-tjenesten) og indsamler alle loginoplysninger og adgangskoder, som prøver at oprette forbindelse. Derefter, ved hjælp af de indsamlede adgangskoder, forsøger den at oprette forbindelse til de angribende noder.

Arbejdsmåde

Programmet kan groft opdeles i 2 hoveddele, der kører i separate tråde. Den første er honeypot. Den behandler login-forsøg, indsamler unikke loginoplysninger og adgangskoder (i dette tilfælde betragtes parret login+adgangskode som en helhed) og tilføjer IP-adresser, som har forsøgt at forbinde, til en kø til fremtidige angreb.

Den anden del er direkte ansvarlig for angrebene. Angreb udføres i to tilstande: BurstAttack (angreb i en kø) — brute-force angreb på loginoplysninger og adgangskoder fra en generel liste, og SingleShotAttack (enkeltstående angreb) — brute-force angreb på adgangskoder, der er blevet brugt af den angrebne node, men som endnu ikke er blevet tilføjet til den generelle liste.

For at have en vis basis af loginoplysninger og adgangskoder straks efter opstart, initialiseres bhunter med en liste fra filen /etc/bhunter/defaultLoginPairs.

Interface

Der er flere måder at starte bhunter på:

Bare med kommandoen

sudo bhunter

Ved denne opstart er der mulighed for at styre bhunter gennem dens tekstmenu: tilføje loginoplysninger og adgangskoder til angreb, eksportere databasen af loginoplysninger og adgangskoder, angive mål for angreb. Alle kompromitterede noder kan ses i filen /var/log/bhunter/hacked.log

Ved at bruge tmux

sudo bhunter-ts # start command for bhunter via tmux  
sudo tmux attach -t bhunter # connect to the session where bhunter is running

Tmux er en terminalmultiplexer og et meget nyttigt værktøj. Det tillader dig at oprette flere vinduer inden for én terminal og opdele vinduerne i paneler. Ved at bruge det kan du forlade terminalen og derefter logge ind igen uden at afbryde de kørende processer.

Scriptet bhunter-ts opretter en tmux-session og opdeler vinduet i tre paneler. I det største panel er der en tekstmenu. Det øverste højre panel indeholder logfiler fra honeypot’et, hvor du kan se meddelelser om Login-forsøg på honeypot. I det nederste højre panel vises information om angrebsforløbet på botnet-noder og succesfulde brud.

Fordelen ved denne metode sammenlignet med den første er, at vi trygt kan lukke terminalen og vende tilbage til den senere, mens bhunter ikke stopper arbejdet. For dem der ikke er så bekendt med tmux anbefaler jeg denne huskeseddel.

Som en service

systemctl enable bhunter
systemctl start bhunter

I dette tilfælde aktiverer vi automatisk opstart af bhunter ved systemopstart. I denne metode er der ikke interaktion med bhunter, og listen over kompromitterede noder kan fås fra /var/log/bhunter/hacked.log

Effektivitet

I løbet af mit arbejde med bhunter har jeg været i stand til at finde og få adgang til en række forskellige enheder: raspberry pi, routere (især mikrotik), webservere, og én gang en mining farm (desværre var adgangen til den kun i løbet af en dag, så der blev ikke nogen spændende historie). Her er et screenshot af programmet, hvor listen over kompromitterede noder ses efter flere dages arbejde:

Desværre nåede effektiviteten af dette værktøj ikke mine forventninger: bhunter kan gætte adgangskoder til noder i flere dage uden resultater, men kan også bryde ind i flere mål på et par timer. Men for en regelmæssig tilstrømning af nye prøver af botnet er det tilstrækkeligt.

Effektiviteten påvirkes af parametre som: landet hvor serveren med bhunter befinder sig, hosting, og det interval som ip-adressen er tildelt fra. I mine erfaringer har der været tilfælde, hvor jeg har lejet to virtuelle servere fra samme host, og den ene blev ramt af angreb fra botnet to gange så ofte.

Bugs jeg endnu ikke har rettet

Ved angreb på inficerede noder er det i nogle situationer ikke muligt entydigt at bestemme, om adgangskoden var korrekt eller ej. Logning af sådanne tilfælde føres i filen /var/log/debug.log.

Paramiko-modulet, der bruges til at arbejde med SSH, opfører sig nogle gange inkorrekt: det går i en uendelig venteposition på svar fra noden, når det forsøger at oprette forbindelse til den. Jeg har eksperimenteret med timere, men har ikke opnået det ønskede resultat.

Hvad skal der arbejdes på videre?

Servicenavn

Ifølge RFC-4253 udveksler klienten og serveren tjenester, der implementerer SSH-protokollen, før forbindelsen oprettes. Dette navn findes i feltet "SERVICE NAME", som findes i både klientens anmodning og serverens svar. Feltet består af en streng, og dens værdi kan findes ved hjælp af wireshark eller nmap. Her er et eksempel for OpenSSH:

$ nmap -p 22 ***.**.***.** -sV
Starter Nmap ...
PORT   STATUS SERVICE VERSION
22/tcp åben  ssh     <b>OpenSSH 7.9p1 Debian 10+deb10u2</b> (protokol 2.0)
Nmap færdig: 1 IP-adresse (1 vært op) scannet på 0,47 sekunder

Men i tilfælde af Paramiko indeholder dette felt en streng som "Paramiko Python sshd 2.4.2", som kan skræmme botnet, der er programmeret til at "undgå" fælder. Jeg mener derfor, at det er nødvendigt at ændre denne streng til noget mere neutralt.