Hydra w praktyce: brute force na SSH i FTP

Pisałam już o tym, jak puścić Hydrę na panel logowania strony www (jeśli przegapiłeś: poprzedni artykuł o Hydrze). Dziś zostawiamy webówkę i schodzimy poziom niżej, do dwóch klasyków, które wciąż wiszą otwarte na milionach serwerów: SSH i FTP. Pokażę Ci, jak wygląda audyt słabych haseł na tych usługach od strony testera. Friendly reminder: robimy to wyłącznie na własnych systemach albo z pisemną zgodą właściciela. Materiał jest edukacyjny, kodeks karny nie ;)

Hydra w pigułce

W skrócie, dla porządku: Hydra (a właściwie THC Hydra) to równoległy łamacz loginów od grupy The Hackers Choice. Obsługuje grubo ponad 50 protokołów, od SSH, FTP i Telnetu, przez HTTP/HTTPS, SMB, RDP, po bazy danych. Cała jej siła to wątki, czyli mnóstwo prób logowania jednocześnie. Jeśli chcesz teorii i podziału na brute force kontra atak słownikowy, masz to w moim poprzednim artykule. Tu jedziemy z praktyką.

Instalacja

Na Kali, Parrocie czy BlackArchu Hydra jest preinstalowana, więc nie masz nic do roboty. Na czystym Debianie/Ubuntu wystarczy:

sudo apt install hydra

Jest też wersja w Dockerze, jeśli wolisz mieć ją w kontenerze:

docker pull vanhauser/hydra

A jak ktoś nie lubi terminala (wybaczam, ale tylko trochę), jest GUI o nazwie xHydra, gdzie wszystko wyklikujesz z okienka.

Przygotowanie: słowniki to połowa sukcesu

Brute force jest tak dobry, jak Twoja lista haseł. Na Kali punktem wyjścia jest klasyk, czyli rockyou.txt z /usr/share/wordlists/, domyślnie spakowany, więc raz trzeba go rozpakować:

sudo gunzip /usr/share/wordlists/rockyou.txt.gz

Jak potrzebujesz czegoś szytego na miarę (np. pod konkretną firmę), generujesz własną listę narzędziami typu crunch albo cupp. A teraz mój ulubiony, niedoceniany trik: jeśli znasz politykę haseł celu, przytnij słownik do tej polityki narzędziem pw-inspector (jedzie w komplecie z Hydrą). Nie ma sensu testować kot, skoro polityka wymaga 8 znaków i trzech klas znaków:

cat /usr/share/wordlists/rockyou.txt | pw-inspector -m 8 -c 3 -l -u -n -s > passlist.txt

Co tu się dzieje: -m 8 to minimalna długość, -l -u -n -s deklaruje cztery klasy znaków (małe, duże, cyfry, znaki specjalne), a -c 3 mówi „wymagaj co najmniej trzech z nich". Z wielomilionowego rockyou robi się przefiltrowana lista pod konkretny target, czyli mniej prób i krótszy atak.

Brute force na SSH

Scenariusz: jesteś testerem i masz sprawdzić, czy serwer SSH pod 192.168.1.100 nie ma kont ze słabymi hasłami.

Najpierw upewnij się, że port 22 w ogóle żyje:

nmap -p 22 192.168.1.100

Teraz lista loginów. Plik usernames.txt, jedna nazwa na linię:

root
admin
user
johndoe

I odpalamy atak, kierując hasła z passlist.txt na każdego usera:

hydra -t 4 -f -L usernames.txt -P passlist.txt ssh://192.168.1.100

Rozbicie: -L to lista loginów, -P to lista haseł, -f zatrzymuje atak po pierwszym trafieniu, a -t 4 ustawia cztery równoległe zadania. I tu uwaga, której nie znajdziesz w połowie tutoriali: przy SSH nie pchaj wysokiego -t. Biblioteka SSH nie lubi wielu równoległych sesji, serwer zaczyna zrywać połączenia i Hydra wypluwa fałszywe negatywy, czyli mówi „nie znalazłam", choć hasło tam siedzi. Cztery zadania to rozsądny punkt startu.

Jak coś padnie, zobaczysz mniej więcej to:

[22][ssh] host: 192.168.1.100   login: user   password: user123

Jak nic nie padnie, Hydra grzecznie poinformuje, że 0 of 1 target completed. I dobra wiadomość dla bezpieczeństwa, zła dla atakującego ;)

Bonus, który warto znać: zanim odpalisz wielki słownik, sprawdź trzy najczęstsze grzechy flagą -e nsr. To każe Hydrze przetestować puste hasło (n), login jako hasło (s) i login wspak (r). Zaskakująco często wystarcza.

Brute force na FTP

FTP to ten sam schemat, zmienia się tylko moduł na końcu:

hydra -t 4 -f -L usernames.txt -P passlist.txt ftp://192.168.1.100

Wynik analogiczny, np. login: ftpuser password: ftpuser oznacza, że konto FTP stoi na haśle, które złamie pierwszy lepszy słownik. W przypadku FTP możesz podbić -t wyżej niż przy SSH, bo protokół znosi więcej połączeń, ale i tak obserwuj, czy serwer nie zaczyna Cię rozłączać.

Optymalizacja i niewpadanie w blokady

Kilka flag, które robią robotę:

• -o /home/karolancx/hydra/ssh_results.txt zapisuje trafienia do pliku, żebyś nie zgubił ich w scrollu terminala.
• -V to tryb gadatliwy, pokazuje każdą testowaną parę login/hasło (świetne do debugowania, męczące przy dużych listach).
• -w 2 ustawia odstęp między próbami, co bywa kluczowe, gdy cel ma rate limiting albo blokady kont.

I tu wraca wątek z poprzedniego artykułu o omijaniu blokad: liczba wątków to miecz obosieczny. Owszem, więcej zadań skraca atak, ale tylko do pewnego momentu, bo zysk szybko się wypłaszcza, a przy okazji robisz dużo hałasu i ładujesz się prosto pod IDS, fail2ban albo blokadę konta. W realnym audycie częściej wygrywa wolniejszy, cichszy atak z sensownym słownikiem niż 128 wątków waląących na oślep.

Bo cała ta zabawa nie polega na tym, kto puści większy słownik, tylko na tym, że konto admin z hasłem admin istnieje na produkcji do dziś. I dopóki istnieje, ktoś je w końcu znajdzie. Lepiej żebyś to był Ty, z upoważnieniem w ręku ;)