Virusanalytikere og forskere inden for computersikkerhed stræber efter at samle så mange prøver af nye botnets som muligt. De bruger honeypots til deres formål… Men hvad hvis man ønsker at observere skadelig software under reelle betingelser? Sætte sin server eller router i fare? Hvad hvis der ikke er nogen passende enhed? Netop disse spørgsmål førte til oprettelsen af bhunter — et værktøj til at få adgang til botnet-noder.

Grunnleggende idé

Der findes mange måder at sprede skadelig software for at udvide botnets: fra phishing til udnyttelse af 0-day sårbarheder. Men den mest udbredte metode er stadig at brute force SSH-adgangskoder.

Ideen er meget enkel. Hvis der fra en node i botnettet foretages brute force angreb på din server, er det sandsynligt, at denne node selv er blevet overtaget ved brute force angreb på enkle adgangskoder. Derfor, for at få adgang til den, skal man bare svare med "det samme".

Sådan fungerer bhunter. Det lytter på port 22 (SSH-tjenesten) og indsamler alle login og adgangskoder, som der forsøges at oprette forbindelse med. Derefter, ved hjælp af de indsamlede adgangskoder, forsøger det at oprette forbindelse til de angribende noder.

Algoritmen for arbejdsgang

Programmet kan groft opdeles i to hoveddele, som arbejder i separate tråde. Den første — honeypot. Den behandler loginforsøg, indsamler unikke login og adgangskoder (i dette tilfælde betragtes login+adgangskode som en enhed), samt tilføjer IP-adresser, der har forsøgt at oprette forbindelse, til en kø til videre angreb.

Den anden del er direkte ansvarlig for angrebet. Angrebet udføres i to tilstande: BurstAttack (angreb med kø) — brute force af login og adgangskoder fra en samlet liste og SingleShotAttack (angreb med enkelt skud) — brute force af adgangskoder, som blev brugt af den angrebne node, men som endnu ikke er blevet tilføjet til den samlede liste.

For at have en nogenlunde database af login og adgangskoder lige efter opstarten, initialiseres bhunter med en liste fra filen /etc/bhunter/defaultLoginPairs.

Grensesnittet

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

Bare ved hjælp af kommandoen

sudo bhunter

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

Bruke tmux

sudo bhunter-ts # kommando for å starte bhunter gjennom tmux  
sudo tmux attach -t bhunter # kobler til sesjonen der bhunter kjører

Tmux er en terminalmultiplexer og et veldig nyttig verktøy. Den lar deg opprette flere vinduer innen ett terminalvindu, og vinduer kan deles opp i paneler. Med det kan du logge ut av terminalen og deretter logge inn igjen uten å stoppe kjørende prosesser.

Skriptet bhunter-ts oppretter en tmux-økt og deler vinduet i tre paneler. I det største panelet finnes menyen. Det øverste høyre panelet viser loggene fra honeypoten; her kan du se meldinger om innloggingsforsøk på honeypoten. I det nederste høyre panelet vises informasjon om angrep på botnettets noder og om vellykkede brudd.

Fordelen med denne metoden fremfor den første er at vi trygt kan lukke terminalen og gå tilbake til den senere, samtidig som bhunter vil fortsette å kjøre. For de som er lite kjent med tmux, foreslår jeg denne huskelappen.

Som en tjeneste

systemctl enable bhunter
systemctl start bhunter

I dette tilfellet aktiverer vi automatisk oppstart av bhunter ved systemstart. I denne metoden er det ikke noe samspill med bhunter, og listen over kompromitterte noder kan hentes fra /var/log/bhunter/hacked.log

Effektivitet

I løpet av arbeidet med bhunter har jeg klart å finne og få tilgang til helt forskjellige enheter: raspberry pi, rutere (spesielt mikrotik), web-servere, og en gang en miningfarm (dessverre var tilgangen til den bare i løpet av en dag, så det ble ikke en interessant historie). Her er et skjermbilde av programmet, hvor du kan se listen over kompromitterte noder etter flere dager med drift:

Dessverre nådde effektiviteten til dette verktøyet ikke mine forventninger: bhunter kan bruke flere dager på å kjøre gjennom passord til noder uten resultat, men kan også bryte seg inn på flere mål på bare noen timer. Men for regelmessig tilstrømning av nye botnet-typer er dette tilstrekkelig.

Effektiviteten påvirkes av faktorer som: landet hvor serveren med bhunter befinner seg, hosting og området fra hvilket IP-adressen tildeles. I min erfaring var det et tilfelle der jeg leide to virtuelle servere fra en leverandør, og den ene ble utsatt for angrep fra botnett to ganger oftere.

Bugs jeg ikke har fikset ennå

Ved angrep på infiserte noder er det i noen situasjoner vanskelig å avgjøre om passordet var korrekt eller ikke. Logging av slike tilfeller skjer i filen /var/log/debug.log.

Paramiko-modulen, som brukes til å jobbe med SSH, oppfører seg noen ganger unormalt: den går i en uendelig ventetilstand på svar fra noden når den prøver å koble seg til. Jeg har eksperimentert med tidtakere, men har ikke oppnådd ønsket resultat.

Hva annet må vi jobbe med?

Tjenestenavn

I henhold til RFC-4253 utveksler klient og server tjenestenavnene som implementerer SSH-protokollen før oppsett. Dette navnet finnes i feltet «SERVICE NAME», som finnes både i forespørselen fra klienten og i svaret fra serveren. Feltet er en streng, og verdien kan findes ved å bruke Wireshark eller Nmap. Her er et eksempel for 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 tilfelle av Paramiko inneholder dette feltet en streng av typen «Paramiko Python sshd 2.4.2», noe som kan skremme botnett som er programmert til å «unngå» feller. Derfor mener jeg det er nødvendig å erstatte denne strengen med noe mer nøytralt.