# Raport z testów bezpieczeństwa

## Metadane raportu

| Pole                     | Wartość                                   |
|---------------------------|--------------------------------------------|
| Nazwa projektu / systemu  | Test penetracyjny – środowisko laboratoryjne (maszyna Redeemer) |
| Adres IP hosta docelowego | 10.129.19.162                              |
| Typ testów                | Black-box, test penetracyjny infrastruktury sieciowej / usług bazodanowych |
| Zakres                    | Środowisko laboratoryjne platformy Hack The Box |
| Data przygotowania raportu | 2026-10-04                                 |
| Autor                     | slummer87                                  |

## 1. Wprowadzenie

Niniejszy raport przedstawia wyniki technicznego testu bezpieczeństwa przeprowadzonego w ramach ćwiczeń na platformie Hack The Box w środowisku laboratoryjnym (maszyna Redeemer). Celem badania była weryfikacja odporności infrastruktury sieciowej na nieautoryzowany dostęp, ze szczególnym uwzględnieniem konfiguracji usługi bazodanowej Redis (magazynu struktur danych klucz-wartość w pamięci), identyfikacja otwartych portów, weryfikacja mechanizmów uwierzytelniania oraz ocena poufności i integralności przechowywanych danych. Testy zrealizowano zgodnie z metodyką black-box w oparciu o wyznaczony scenariusz laboratoryjny.

## 2. Metodyka

Test penetracyjny przeprowadzono w następujących etapach:

1. **Rekonesans sieciowy i pełne skanowanie portów TCP** – identyfikacja aktywnego hosta oraz badanie wszystkich 65535 portów TCP za pomocą narzędzia `nmap` w celu wykrycia uruchomionych usług.
2. **Identyfikacja i analiza wersji usług** – ustalenie typu oraz wersji oprogramowania serwera bazodanowego (`Redis key-value store 5.0.7`) działającego na porcie 6379/tcp.
3. **Weryfikacja mechanizmów uwierzytelniania** – próba nawiązania bezpośredniego połączenia z serwerem bazodanowym za pomocą narzędzia `redis-cli` bez podawania poświadczeń.
4. **Eksploracja bazy danych i potwierdzenie nieautoryzowanego dostępu** – weryfikacja uprawnień do odpytywania o stan instancji (`INFO`), przeszukania przestrzeni kluczy (`KEYS *`) oraz odczytu wartości biznesowych (w tym pozyskanie klucza dowodowego `flag`).
5. **Analiza ryzyka i opracowanie rekomendacji** – ocena wpływu wykrytych luk konfiguracyjnych na bezpieczeństwo środowiska oraz sformułowanie zaleceń naprawczych.

## 3. Przebieg testów

### 3.1. Rekonesans i skanowanie portów

W ramach rekonesansu wykonano pełne skanowanie wszystkich portów TCP na adresie IP maszyny docelowej:

```bash
nmap -Pn -sV -p- 10.129.19.162
```

Zastosowane parametry:
- `-Pn` – pominięcie badania dostępności hosta protokołem ICMP (traktowanie hosta jako aktywnego),
- `-sV` – detekcja wersji i typu uruchomionych usług na wykrytych portach,
- `-p-` – skanowanie pełnego zakresu portów TCP (od 1 do 65535).

**Wynik skanowania:**

```text
Nmap scan report for 10.129.19.162
Host is up (0.061s latency).
Not shown: 65534 closed tcp ports (reset)
PORT     STATE SERVICE VERSION
6379/tcp open  redis   Redis key-value store 5.0.7
```

Na badanym hoście **10.129.19.162** zidentyfikowano otwarty port **6379/tcp** z aktywną usługą **Redis key-value store 5.0.7**.

### 3.2. Weryfikacja mechanizmów uwierzytelniania

Do weryfikacji mechanizmów kontroli dostępu wykorzystano oficjalnego klienta `redis-cli`, podejmując próbę bezpośredniego połączenia z adresem serwera:

```bash
redis-cli -h 10.129.19.162
```

**Wynik:** Serwer Redis zaakceptował sesję bez monitu o hasło i udostępnił interaktywną konsolę tekstową z pełnymi uprawnieniami administracyjnymi do instancji bazy danych.

### 3.3. Eksploracja bazy danych i potwierdzenie nieautoryzowanego dostępu

W konsoli `redis-cli` wykonano polecenia diagnostyczne oraz operacje na danych:

1. Pobranie informacji o stanie instancji, wersji oraz konfiguracji bazy danych:
   ```text
   10.129.19.162:6379> INFO
   ```
   Serwer zwrócił kompletne metadane środowiska, w tym informacje o wykorzystaniu pamięci, liczbie podłączonych klientów oraz statystykach bazy danych `db0`.

2. Wyświetlenie wszystkich kluczy przechowywanych w bieżącej przestrzeni danych:
   ```text
   10.129.19.162:6379> KEYS *
   ```
   Wśród zwróconych rekordów zidentyfikowano klucz o nazwie `flag`.

3. Ekstrakcja wartości skojarzonej ze znalezionym kluczem:
   ```text
   10.129.19.162:6379> GET flag
   ```

Odczytanie zawartości klucza `flag` potwierdziło możliwość swobodnego pobierania dowolnych danych składowanych w pamięci serwera Redis przez każdego nieuwierzytelnionego użytkownika sieciowego.

## 4. Zidentyfikowane podatności

### 4.1. Brak uwierzytelniania w usłudze bazodanowej Redis

| Parametr           | Opis |
|---------------------|------|
| **ID podatności**   | VULN-001 |
| **Host/port**       | 10.129.19.162 : 6379/tcp |
| **Kategoria**       | Brak uwierzytelniania funkcji krytycznych (CWE-306: Missing Authentication for Critical Function, CWE-287: Improper Authentication) |
| **Krytyczność**     | **Krytyczna (Critical)** |
| **Opis**            | Serwer Redis został uruchomiony bez skonfigurowanego hasła dostępowego (`requirepass`). Każdy podmiot posiadający łączność sieciową z portem 6379/tcp może nawiązać sesję i wykonywać dowolne polecenia administracyjne oraz operacje na danych (CRUD) bez jakiejkolwiek autoryzacji. |
| **Dowód (PoC)**      | Połączenie poleceniem `redis-cli -h 10.129.19.162`, wywołanie polecenia `KEYS *` ujawniające strukturę bazy danych oraz odczyt wartości klucza `flag` poleceniem `GET flag`. |
| **Wpływ**            | Całkowite naruszenie poufności i integralności danych przetwarzanych w bazie Redis. Osoba nieuprawniona może odczytać, zmodyfikować lub skasować całą zawartość magazynu danych (np. poleceniem `FLUSHALL`), zatrzymać usługę (`SHUTDOWN`), a w sprzyjających warunkach środowiskowych (poprzez modyfikację parametrów `dir` i `dbfilename` za pomocą `CONFIG SET`) doprowadzić do wykonania dowolnego kodu na serwerze (RCE), np. poprzez nadpisanie kluczy SSH lub zadań cron. |
| **Prawdopodobieństwo wykorzystania** | Bardzo wysokie – luka nie wymaga przygotowywania specjalistycznych exploitów i jest trywialna do wykorzystania przy użyciu standardowych narzędzi sieciowych. |

### 4.2. Bezpośrednia ekspozycja usługi Redis w sieci (brak ograniczenia interfejsu nasłuchiwania)

| Parametr           | Opis |
|---------------------|------|
| **ID podatności**   | VULN-002 |
| **Host/port**       | 10.129.19.162 : 6379/tcp |
| **Kategoria**       | Niewłaściwa konfiguracja sieciowa / Ujawnienie zasobu (CWE-668: Exposure of Resource to Wrong Sphere, CWE-1188: Insecure Default Initialization of Resource) |
| **Krytyczność**     | **Średnia (Medium)** |
| **Opis**            | Usługa Redis nasłuchuje na publicznym / współdzielonym interfejsie sieciowym (adres `0.0.0.0` lub zewnętrzny IP), zamiast być ograniczona do lokalnego interfejsu pętli zwrotnej (`127.0.0.1` / localhost). Baza danych pamięci podręcznej nie powinna być bezpośrednio osiągalna z sieci zewnętrznej. |
| **Dowód (PoC)**      | Narzędzie `nmap` oraz `redis-cli` bez przeszkód nawiązują bezpośrednie połączenie TCP z portem 6379/tcp na zewnętrznym adresie hosta `10.129.19.162`. |
| **Wpływ**            | Zwiększenie powierzchni ataku na infrastrukturę oraz narażenie serwera bazodanowego na ataki sieciowe, próby brute-force lub skanowanie przez podmioty nieuprawnione w sieci lokalnej/zewnętrznej. |
| **Prawdopodobieństwo wykorzystania** | Bardzo wysokie – port usługi jest publicznie widoczny i dostępny w trakcie standardowego skanowania sieci. |

## 5. Rekomendacje

W celu zabezpieczenia serwera Redis oraz infrastruktury przed nieautoryzowanym dostępem zaleca się podjęcie następujących działań naprawczych:

1. **Wdrożenie silnego uwierzytelniania:**
   - W pliku konfiguracyjnym serwera (`redis.conf`) należy zdefiniować silne, długie i losowe hasło za pomocą dyrektywy `requirepass`:
     ```text
     requirepass <silne_losowe_haslo_min_32_znaki>
     ```
   - W nowszych wersjach Redis (6.0+) zaleca się wdrożenie list kontroli dostępu (ACL), umożliwiających tworzenie dedykowanych kont użytkowników z ograniczonymi uprawnieniami do konkretnych komend i przestrzeni kluczy.

2. **Ograniczenie interfejsów nasłuchiwania (Network Binding):**
   - Jeśli baza danych jest wykorzystywana wyłącznie lokalnie przez aplikację działającą na tym samym hoście, należy ograniczyć nasłuchiwanie do interfejsu pętli zwrotnej:
     ```text
     bind 127.0.0.1 ::1
     ```
   - Należy upewnić się, że włączony jest tryb chroniony (`protected-mode yes`), który blokuje nieautoryzowane zapytania sieciowe, gdy hasło nie jest ustawione.

3. **Segmentacja sieci i reguły zapory sieciowej (Firewall):**
   - Zablokować dostęp do portu 6379/tcp na poziomie zapory sieciowej (np. `iptables`, `nftables`, UFW lub firewall sprzętowy) dla ruchu przychodzącego z niezaufanych segmentów sieci. Dostęp powinien być dozwolony wyłącznie ze zdefiniowanych adresów IP serwerów aplikacyjnych.

4. **Wyłączenie lub zmiana nazw niebezpiecznych poleceń:**
   - W konfiguracji `redis.conf` zaleca się wyłączenie lub zmianę nazw komend administracyjnych stwarzających ryzyko modyfikacji konfiguracji serwera lub usunięcia danych:
     ```text
     rename-command CONFIG ""
     rename-command FLUSHALL ""
     rename-command FLUSHDB ""
     rename-command SHUTDOWN ""
     rename-command DEBUG ""
     ```

5. **Zasada najmniejszych uprawnień na poziomie systemu operacyjnego:**
   - Upewnić się, że proces Redis działa w kontekście dedykowanego, nieuprzywilejowanego użytkownika systemowego (np. `redis`) i nie posiada uprawnień do zapisu w krytycznych katalogach systemowych (np. `/root/.ssh`, `/etc/cron*`).

6. **Szyfrowanie komunikacji (TLS):**
   - W przypadku konieczności przesyłania danych przez sieć pomiędzy serwerami aplikacji a bazą Redis, wdrożyć natywne szyfrowanie TLS (dostępne od wersji Redis 6.0) lub tunelowanie połączeń (np. przez Stunnel, WireGuard, IPsec lub SSH).

## 6. Podsumowanie

Podczas testów bezpieczeństwa hosta w środowisku Hack The Box (maszyna Redeemer) zidentyfikowano dwie podatności: **krytyczną** (całkowity brak uwierzytelniania w usłudze bazodanowej Redis) oraz **średnią** (bezpośrednia ekspozycja usługi na zewnętrznym interfejsie sieciowym). 

Wykryte wady konfiguracyjne umożliwiły testerowi natychmiastowe nawiązanie sesji administracyjnej, zbadanie struktury bazy danych oraz odczytanie poufnego rekordu `flag`. Wdrożenie zalecanych środków zaradczych (ustawienie dyrektywy `requirepass`, ograniczenie `bind 127.0.0.1` oraz reguły firewalla) pozwoli w pełni zabezpieczyć usługę przed dostępem ze strony osób niepowołanych.

## 7. Podsumowanie klasyfikacji podatności

| ID        | Nazwa podatności                                              | Krytyczność |
|-----------|---------------------------------------------------------------|--------------|
| VULN-001  | Brak uwierzytelniania w usłudze bazodanowej Redis             | Krytyczna    |
| VULN-002  | Bezpośrednia ekspozycja usługi Redis w sieci (brak ograniczenia interfejsu) | Średnia      |

---
*Niniejszy raport został przygotowany na podstawie testów przeprowadzonych w środowisku laboratoryjnym platformy Hack The Box. Wyniki i rekomendacje mają charakter poglądowy i powinny zostać zweryfikowane przed wdrożeniem w środowisku produkcyjnym.*