Kolejnym wyzwaniem na platformie Hack The Box w ścieżce maszyn linuksowych jest Cap, oznaczona poziomem trudności Easy. W tym laboratorium badam aplikację webową do monitorowania sieci, wykorzystuję podatność IDOR do przechwycenia poświadczeń z nieszyfrowanego zrzutu pakietów, uzyskuję dostęp do systemu przez FTP i SSH, a na koniec przeprowadzam eskalację uprawnień do konta root za pomocą mechanizmu Linux Capabilities.

Skanowanie i identyfikacja usług

Zadanie rozpoczynam od pełnego rekonesansu portów TCP na przydzielonym adresie IP maszyny docelowej. Aby sprawdzić cały zakres portów oraz ustalić wersje uruchomionego oprogramowania, wykonuję skanowanie narzędziem nmap:

nmap -p- --open -sV 10.129.117.225

W poleceniu wykorzystałem następujące przełączniki:

  • Pełny zakres portów (All Ports) – opcja -p- skanuje wszystkie 65535 portów TCP.
  • Filtrowanie otwartych portów (Open Ports Only) – parametr --open ogranicza raportowane wyniki wyłącznie do portów o statusie otwartym.
  • Wykrywanie wersji (Service Version Detection) – flaga -sV odpytuje otwarte porty, aby ustalić nazwy i wersje działających usług.

Wynik skanowania wskazuje trzy aktywne usługi:

Nmap scan report for 10.129.117.225
Host is up (0.066s latency).
Not shown: 65532 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.3
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.2 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Gunicorn
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Na maszynie zidentyfikowałem serwer FTP (vsftpd 3.0.3), usługę SSH (OpenSSH 8.2p1) oraz serwer HTTP obsługiwany przez Gunicorn.

Rekonesans aplikacji webowej i podatność IDOR

Po otwarciu adresu IP w przeglądarce trafiam na aplikację webową pełniącą funkcję panelu administracyjnego do monitorowania parametrów sieciowych serwera. W menu znajduje się między innymi zakładka Security Snapshot, która pozwala na generowanie zrzutów ruchu sieciowego.

Podczas analizy ruchu HTTP w narzędziu Burp Suite zauważam, że wyświetlenie szczegółów zrzutu wysyła żądanie do endpointu /data/1, natomiast pobranie wygenerowanego pliku PCAP odbywa się pod adresem /download/1.

Wskazuje to na bezpośrednie odwoływanie się do obiektów IDOR.

Podatność typu IDOR polega na braku weryfikacji uprawnień użytkownika do zasobu wskazanego w parametrze żądania, co umożliwia dostęp do danych innych użytkowników poprzez modyfikację identyfikatora.

Postanawiam przetestować podatność i zmieniam identyfikator w żądaniu z 1 na 0, odpytując adres /download/0. Serwer bez żadnej autoryzacji zwraca wcześniejszy zrzut pakietów, zarejestrowany podczas startu systemu.

Pobrany plik 0.pcap poddaję analizie. Wśród przechwyconych pakietów odnajduję nieszyfrowaną sesję protokołu FTP, w której użytkownik nathan przesyła swoje hasło jawnym tekstem.

Weryfikacja poświadczeń i zdobycie flagi użytkownika

Mając pozyskany login oraz hasło, przechodzę do weryfikacji poświadczeń na serwerze FTP:

ftp nathan@10.129.117.225

Po podaniu hasła logowanie kończy się sukcesem, a wylistowanie zawartości katalogu poleceniem ls potwierdza obecność pliku user.txt:

Ponieważ użytkownicy często stosują to samo hasło w różnych usługach, sprawdzam możliwość zalogowania się na konto systemowe przez protokół SSH:

ssh nathan@10.129.117.225

Uwierzytelnienie przebiega pomyślnie. Uzyskuję interaktywną powłokę w systemie docelowym jako użytkownik nathan i odczytuję flagę użytkownika z pliku user.txt.

Eskalacja uprawnień za pomocą Linux Capabilities

Kolejnym etapem jest podniesienie uprawnień do konta administratora (root). W celu przeprowadzenia audytu konfiguracji systemu przesyłam na maszynę skrypt LinPEAS za pośrednictwem protokołu SCP:

scp linpeas.sh nathan@10.129.117.225:/home/nathan

Po nadaniu uprawnień wykonywania uruchamiam skrypt na maszynie docelowej. W sekcji dotyczącej plików wykonywalnych ze specjalnymi uprawnieniami LinPEAS wyróżnia interpreter Pythona:

Obecność uprawnień weryfikuję również wbudowanym poleceniem systemowym:

getcap -r / 2>/dev/null

Plik /usr/bin/python3.8 posiada przypisane uprawnienie cap_setuid+eip:

Uprawnienia procesów w Linuksie (Linux Capabilities) – mechanizm dzielący pełne uprawnienia roota na mniejsze, precyzyjne przywileje przypisywane do konkretnych plików wykonywalnych.

Zmiana identyfikatora użytkownika (Set UID Capability) – uprawnienie cap_setuid pozwala procesowi na dowolną zmianę swojego identyfikatora UID, w tym na przyjęcie tożsamości roota (UID 0).

Ponieważ interpreter Pythona może manipulować własnym identyfikatorem UID, uruchamiam go i wykonuję krótki kod wykorzystujący moduł os:

import os
os.setuid(0)

Po zmianie UID na 0 proces zyskuje pełne uprawnienia administratora, co pozwala wylistować zawartość katalogu /root oraz odczytać flagę z pliku root.txt:

W ten sposób pomyślnie zdobywam flagę roota i kończę realizację maszyny.

Podsumowanie

Laboratorium Cap doskonale ilustruje łańcuch ataku, w którym pojedyncze błędy konfiguracyjne prowadzą do całkowitego przejęcia systemu:

  • Podatność IDOR (Insecure Direct Object Reference) – brak weryfikacji uprawnień w aplikacji webowej pozwolił na nieautoryzowane pobranie zrzutu ruchu sieciowego.
  • Nieszyfrowana transmisja (Cleartext Transmission) – przesyłanie poświadczeń otwartym tekstem w protokole FTP umożliwiło łatwe przechwycenie hasła.
  • Ponowne użycie haseł (Password Reuse) – wykorzystanie tego samego hasła w usłudze SSH pozwoliło na natychmiastowe uzyskanie powłoki systemowej.
  • Nadmiarowe uprawnienia (Excessive Capabilities) – nadanie uprawnienia cap_setuid interpreterowi Pythona otworzyło bezpośrednią drogę do przejęcia konta root.

W środowisku produkcyjnym kluczowe jest rygorystyczne sprawdzanie uprawnień na poziomie aplikacji, wycofanie nieszyfrowanych protokołów transmisji oraz stosowanie zasady najmniejszych uprawnień przy konfigurowaniu przywilejów plików wykonywalnych.

Raport z testów można pobrać tutaj.