Analitycy wirusów i badacze bezpieczeństwa komputerowego starają się zebrać jak najwięcej próbek nowych botnetów. W tym celu wykorzystują honeypot'y... Ale co jeśli chcesz obserwować złośliwe oprogramowanie w rzeczywistych warunkach? Narażać swój serwer, router? A co, jeśli nie masz odpowiedniego urządzenia? To właśnie te pytania skłoniły mnie do stworzenia bhuntera — narzędzia do uzyskiwania dostępu do węzłów botnetów.

Podstawowa idea

Istnieje wiele sposobów rozprzestrzeniania złośliwego oprogramowania w celu rozszerzenia botnetów: począwszy od phishingu, a skończywszy na wykorzystaniu podatności 0-day. Jednak najpowszechniejszą metodą nadal pozostaje łamanie haseł do SSH.

Pomysł jest bardzo prosty. Jeśli z jakiegoś węzła botnetu dochodzi do próby łamania haseł do twojego serwera, to najprawdopodobniej ten węzeł został sam zhakowany poprzez łamanie prostych haseł. A więc, aby uzyskać do niego dostęp, wystarczy odpowiedzieć mu «wzajemnością».

Dokładnie tak działa bhunter. Nasłuchuje na porcie 22 (usługa SSH) i zbiera wszystkie loginy oraz hasła, z którymi próbuje się połączyć. Następnie, wykorzystując zebrane hasła, próbuje połączyć się z atakującymi węzłami.

Algorytm działania

Program można zasadniczo podzielić na 2 główne części, które działają w oddzielnych wątkach. Pierwsza to honeypot. Obsługuje próby logowania, zbiera unikalne loginy i hasła (w tym przypadku para login+hasło jest traktowana jako całość), a także dodaje do kolejki do dalszej ataku IP adresy, które próbowały się połączyć.

Druga część odpowiada bezpośrednio za atak. Przy czym atak prowadzony jest w dwóch trybach: BurstAttack (atak w kolejce) — łamanie loginów i haseł z ogólnej listy oraz SingleShotAttack (atak pojedynczymi strzałami) — łamanie haseł, które były używane przez atakowany węzeł, ale jeszcze nie zostały dodane do ogólnej listy.

Aby mieć jakąś bazę loginów i haseł tuż po uruchomieniu, bhunter jest inicjowany listą z pliku /etc/bhunter/defaultLoginPairs.

Interfejs

Przewidziano kilka sposobów uruchamiania bhuntera:

Po prostu poleceniem

sudo bhunter

Przy takim uruchomieniu można zarządzać bhunterem za pomocą jego tekstowego menu: dodawać loginy i hasła do ataku, eksportować bazę loginów i haseł, wskazać cel ataku. Wszystkie zhakowane węzły można zobaczyć w pliku /var/log/bhunter/hacked.log

Używając tmux

sudo bhunter-ts # polecenie uruchamiające bhunter przez tmux  
sudo tmux attach -t bhunter # łączymy się z sesją, w której działa bhunter

Tmux to multiplexer terminali, bardzo wygodne narzędzie. Pozwala tworzyć wiele okien w ramach jednego terminala, a okna dzielić na panele. Używając go można wyjść z terminala, a potem wrócić, nie przerywając uruchomionych procesów.

Skrypt bhunter-ts tworzy sesję tmux i dzieli okno na trzy panele. W pierwszym — największym, znajduje się tekstowe menu. W górnym prawym panelu znajdują się logi honeypota, można tu zobaczyć wiadomości o próbach logowania się do honeypota. W dolnym prawym panelu wyświetlane są informacje o postępach ataków na węzły botnetów i o udanych włamaniach.

Zaletą tego sposobu nad pierwszym jest to, że możemy bez obaw zamknąć terminal i wrócić do niego później, przy tym bhunter nie zatrzyma pracy. Dla tych, którzy niewiele wiedzą o tmux, proponuję ten ściągawka.

Jako usługa

systemctl enable bhunter
systemctl start bhunter

W tym przypadku włączamy automatyczne uruchamianie bhuntera przy starcie systemu. W tej metodzie interakcja z bhunterem nie jest przewidziana, a lista zhakowanych węzłów można uzyskać z /var/log/bhunter/hacked.log

Efektywność

Pracując nad bhunterem udało mi się znaleźć i uzyskać dostęp do zupełnie różnych urządzeń: raspberry pi, routery (szczególnie mikrotik), serwery www, a pewnego razu farmy do wydobywania (niestety dostęp do niej był przez jeden dzień, więc nie wydarzyła się interesująca historia). Oto zrzut ekranu programu, na którym widoczna jest lista zhakowanych węzłów po kilku dniach pracy:

Niestety, skuteczność tego narzędzia nie spełniła moich oczekiwań: bhunter może sprawdzać hasła do węzłów przez kilka dni bez rezultatu, a może zhakować kilka celów w ciągu kilku godzin. Ale do regularnego pozyskiwania nowych próbek botnetów to wystarczy.

Na efektywność wpływają takie parametry jak: kraj, w którym znajduje się serwer z bhunter, hosting oraz zakres, z którego przydzielony jest adres IP. Z mojego doświadczenia miałem przypadek, gdy wynajmowałem dwa wirtualne serwery od jednego hostingu, a jeden z nich był atakowany przez botnety dwa razy częściej.

Błędy, których jeszcze nie naprawiłem

W przypadku ataku na zainfekowane węzły w niektórych sytuacjach trudno jednoznacznie określić, czy hasło jest poprawne, czy nie. Rejestrowanie takich przypadków odbywa się w pliku /var/log/debug.log.

Moduł Paramiko, używany do pracy z SSH, czasami działa niepoprawnie: wchodzi w nieskończone oczekiwanie na odpowiedź od węzła, gdy próbuje się do niego połączyć. Eksperymentowałem z timerami, ale nie uzyskałem pożądanego rezultatu.

Nad czym jeszcze trzeba popracować?

Nazwa usługi

Zgodnie z RFC-4253, klient i serwer wymieniają się nazwami usług przed nawiązaniem połączenia, które realizują protokół SSH. Ta nazwa zawiera się w polu „SERVICE NAME”, które znajduje się zarówno w żądaniu ze strony klienta, jak i w odpowiedzi ze strony serwera. Pole to jest ciągiem i jego wartość można poznać używając Wireshark lub nmap. Oto przykład dla OpenSSH:

$ nmap -p 22 ***.**.***.** -sV
Rozpoczynanie skanowania Nmap ...
PORT   STAN USŁUGA WERSJA
22/tcp otwarte  ssh     <b>OpenSSH 7.9p1 Debian 10+deb10u2</b> (protokół 2.0)
Skanowanie zakończone: 1 adres IP (1 host aktywny) zeskanowany w 0.47 sekundy

Jednakże w przypadku Paramiko, to pole zawiera ciąg o postaci „Paramiko Python sshd 2.4.2”, co może odstraszać botnety, które mają wbudowane „unikanie” pułapek. Dlatego uważam, że konieczne jest zastąpienie tego ciągu czymś bardziej neutralnym.