Założenia

1. Przeskanowanie sieci i wyszukania aktywnych hostów
2. Przeskanowanie portów i identyfikacji działających usług
3. Namierzenie usługi Redis i złamapnie loginu oraz hasła
4. Odczytanie danych znajdujących się w Redisie

Instalacja Redis Server

Na Ubuntu Server zainstalowałem Redis Server z repozytoriów systemowych:

sudo apt install redis-server -y
sudo systemctl status redis-server

Redis domyślnie powinien nasłuchiwać lokalnie, zwykle na adresie:

127.0.0.1:6379

Do ćwiczeń potrzebowałem jednak, aby Redis był widoczny również z drugiej maszyny wirtualnej w tej samej sieci labowej.

Konfiguracja usługi Redis Server

Plik konfiguracyjny Redis znajduje się w:

/etc/redis/redis.conf

W konfiguracji ustawiłem dyrektywę bind tak, aby Redis nasłuchiwał lokalnie oraz na adresie IP maszyny:

bind 127.0.0.1 192.168.202.131

Dodatkowo zostawiłem włączony tryb ochronny:

protected-mode yes

Po zmianach zrestartowałem usługę:

sudo systemctl restart redis-server

Następnie sprawdziłem, czy Redis nasłuchuje na porcie 6379:

sudo ss -lntp | grep 6379

Oczekiwany efekt to nasłuchiwanie na localhost oraz adresie interfejsu sieciowego:

Ustawienie loginu i hasła w Redis Server

Redis w nowszych wersjach obsługuje mechanizm ACL (Access Control List), który pozwala tworzyć użytkowników z osobnym loginem, hasłem i zestawem uprawnień. To lepsze rozwiązanie niż samo requirepass, ponieważ umożliwia bardziej precyzyjną kontrolę dostępu.

W moim labie użyłem Redis Server w wersji 8, więc mogłem skonfigurować dostęp w formie:

login: admin
hasło: admin

Najpierw edytowałem plik konfiguracyjny Redis-a:

sudo nano /etc/redis/redis.conf

Następnie dodałem konfigurację użytkownika ACL:

user default off <- wyłączenie domyślnego użytkownika Redis-a - nie można się zalogować bez podania danych uwierzytelanijących
user admin on >admin ~* +@all <- utworzenie użytkownika admin z dostępem do wszystkich kluczy

Poprawne logowanie z użyciem użytkownika i hasła wygląda tak:

redis-cli --user admin -a 'admin' PING

Identyfikacja aktywnych hostów w sieci

Z pomocą narzędzia nmap wyszukałem wszystkie aktywne hosty w sieci

nmap -sn 192.168.202.131/24

Parametr -sn skanuje aktywne hosty bez skanowania portów.

Narzędzie wykrywa kilka aktywnych hostów

Następnie przeskanowałem aktywne hosty:

nmap -Pn -sV -p- 192.168.202.131

Parametr -Pn pomija sprawdzanie, czy host jest aktywny Parametr -sV wykrywa wersję usługi dostępną na skanowanych portach Parametr -p- skanuje wszystkie porty od 1 do 65535

Do prostego testu połączenia można użyć klienta Redis:

redis-cli -h 192.168.202.131 -p 6379 PING

Jednak w tym przypadku serwer Redis-a jest zabezpieczony i nie można się do niego zalogować bez autoryzacji.

(error) NOAUTH Authentication required.

Eksploitacja hasła Redis Server

Kali Linux posiada wiele narzędzie do łamania haseł, jednym z popularnych narzędzi jest hydra. Niestety, w przypadku gdy Redis Server zabezpieczony jest loginem i hasłem (a nie samym hasłem) - hydra nie wystarczy.

W celu wykrycia hasła napisałem prosty skrypt w Python, który z użyciem redis cli sprawdza możliwe kombinacje haseł z dostarczonej word-listy.

python3 exploit-redis.py -H 192.168.202.131 -p 6379 -u admin -w /usr/share/wordlists/fasttrack.txt

Wynik polecenia po kilku chwilach to

Jak widać, słabe hasło możliwe jest do złamania bardzo szybko.

Całość została uruchomiona w VMware Fusion. Ponieważ host działa na procesorze Apple M3, do instalacji systemów wybrałem obrazy w architekturze ARM64, a nie klasyczne obrazy Intel/AMD 64-bit.

Założenia

Środowisko składa się z dwóch maszyn:

VM 1: Attacker
- system: Kali
- rola: maszyna do testów i skanowania

VM 2: Victim
- system: Ubuntu
- rola: maszyna testowa

Do ćwiczeń wystarczyły następujące zasoby:

Attacker:
- CPU: 2–4 rdzenie
- RAM: 4–8 GB
- Dysk: 40–60 GB

Victim:
- CPU: 1–2 rdzenie
- RAM: 2 GB
- Dysk: 20 GB

Konfiguracja sieci w VMware Fusion

Obie maszyny zostały podłączone do tej samej sieci wirtualnej w VMware Fusion. Do labu najlepiej sprawdza się tryb izolowany, np.:

Private to my Mac / Host-only

Dzięki temu maszyny wirtualne widzą się nawzajem, ale usługi uruchamiane w labie nie są przypadkowo wystawione do fizycznej sieci domowej.

Po uruchomieniu maszyny ofiary sprawdziłem jej konfigurację sieciową:

ip addr

Interfejs sieciowy ofiary otrzymał adres:

192.168.202.131/24

Oznacza to, że sama maszyna ofiary ma adres:

192.168.202.131

a sieć labowa to:

192.168.202.0/24

Podsumowanie

Taki prosty HomeLab pozwala bezpiecznie ćwiczyć podstawy testów bezpieczeństwa usług sieciowych. Najważniejsze elementy konfiguracji to:

• użycie obrazów ARM64 na Macu z Apple Silicon,
• uruchomienie obu maszyn w tej samej izolowanej sieci VMware,
• sprawdzenie adresów IP przez ip addr,
• unikanie wystawiania podatnych usług w trybie Bridged,

Na dalszym etapie będę rozbudowywał HomeLab o dodatkowe usługi w celu ich eksploitowania i testowania bezpieczeństwa.

Zadania są bardzo przyjemne, w interaktywnej formie, szybko się je robi i dają sporo frajdy :)