Opis maszyny
The „Publisher” CTF machine is a simulated environment hosting some services. Through a series of enumeration techniques, including directory fuzzing and version identification, a vulnerability is discovered, allowing for Remote Code Execution (RCE). Attempts to escalate privileges using a custom binary are hindered by restricted access to critical system files and directories, necessitating a deeper exploration into the system’s security profile to ultimately exploit a loophole that enables the execution of an unconfined bash shell and achieve privilege escalation.
Rekonesans
Zastrzeżenie: We wpisach opisujących CTFy nie znajdziesz gotowych flag do wklejenia na THM, znajdziesz natomiast wskazówki jak samemu rozwiązać dany problem.
Standardowo rozpocząłem rekonesans od narzędzia Nmap, aby sprawdzić jakie porty są otwarte na maszynie:
nmap -sV -p- adressIP
-sV -wersja uruchomionej usługi
-p- skanuje wszystkie porty
-O sprawdza system operacyjny hosta
Informacje, które mogą okazać się przydatne:
- otwarty port 22 SSH w wersji OpenSSH 8.2p1
- otwarty port 80 HTTP działający na Apache 2.4.41
- Linux kernel 4.15
Wchodząc na stronę z adresem IP usługi zauważyłem, że wszędzie pojawia się logo SPIP, które to jest narzędziem klasy CMS. W takim razie jest szansa, że serwis korzysta właśnie z tego narzędzia.
Przystąpiłem więc do skanowania endpointów za pomocą narzędzia gobuster z wybraną wordlistą
gobuster dir -w <wordlist> -u <url>
W wyniku skanowania otrzymałem:
Pod odwiedzeniu podstrony /spip sprawdziłem nagłówek jaki dostałem w odpowiedzi od serwera – udało się znaleźć wersję używanego CMSa – SPIP 4.2.0.
Sprawdziłem znane podatności na ExploitDB dla tej wersji SPIP i znalazłem wspomnianą podatność RCE w zadaniu.
Exploitation
Skorzystałem z searchsploit żeby znaleźć numer i plik exploitu na Kali Linux
Skopiowałem plik aby zmodyfikować go przed uruchomieniem
Sprawdziłem helpa do skryptu. Uruchomienie wymagało podania adresu URL celu oraz komendy, która ma wykonać się zdalnie na urządzeniu. Stwierdziłem że najodpowiedniejszą opcją będzie uruchomienie reverse shella. W tym celu uruchomiłem netcat’a w celu nasłuchiwania na odpowiednim porcie
nc -nlvp 4444
Po uruchomieniu reverse shella przygotowałem odpowiednie parametry do uruchomienia skryptu
python3 51536.py -u <url> -c <command>
Ze względu na błąd w KaliLinux z jedną z bibliotek Pythona zmieniłem system na ParrotOS, żeby sprawdzić czy tylko Kali ma problem. Okazało się że korzystając z ParrotOS wszystko działa poprawnie (przeszedłem więc do dalszego działania na tym systemie, ponieważ już wystarczająco dużo czasu straciłem na troubleshooting Kaliego).
Aby uruchomić reverse shella skorzystałem ze strony www.revshells.com.
Następnie przekształciłem payload na base64 i wykonałem skrypt. Udało się nawiązać połączenie z serwerem!
Uruchomienie nasłuchu na porcie 4444 dla reverse shella
Najpierw sprawdziłem jakie mam uprawnienia i w jakim miejscu w systemie się znajduję
Sprawdzając lokalizacje znajdujące się na serwerze doszedłem do lokalizacji /home/think/ w którym znajdował się plik user.txt – pierwsza flaga złapana
Privilege escalation
Aby zdobyć drugą flagę wymagana jest eskalacja uprawnień. W tej samej lokalizacji sprawdzając ukryte pliki i foldery znalazłem folder .ssh w którym znajdują się pliki authorized_keys, id_rsa oraz id_rsa_pub
plik id_rsa zawiera klucz prywatny do połączenia przez openssh. Działanie usługi i otwarcie portu znalazłem na samym początku rekonesansu.
Skopiowałem plik na swoją maszynę wirtualną. Zostało spróbować podłączyć się po ssh do maszyny. po próbie podłączenia dostałem błąd Unprotected private key więc zmniejszyłem uprawnienia do pliku tak, aby nie powodował błędu:
Po podłączeniu się ssh i poszperaniu trochę po systemie zdecydowałem się znaleźć miejsce do którego możemy pisać, aby móc użyć narzędzia linpeas. Wukorzystałem do tego komendę find:
find <search start catalog> -type d -user <user> -writable
/ -przeszukiwanie zaczyna się od głównego katalogu
-type d -sprawdzane są tylko katalogi
-user -filtruje katalogi których właścicielem jest dany użytkownik
-writable – sprawdza czy użytkownik uruchamiający skrypt ma możliwość zapisu do danej lokalizacji
Na długiej liście lokalizacji znalazłem coś co można wykorzystać:
Zdecydowałem się wykorzystać tą lokalizację do pobrania tam narzędzia linpeas.
Najpierw pobrałem narzędzie na maszynę z której łączyłem się do atakowanej maszyny i uruchomiłem serwer http w celu udostępnienia pliku, po czym pobrałem plik na atakowaną maszynę.
Uruchomienie serwera http z wykorzystaniem Pythona
Pobranie plików na maszynę docelową
Zmodyfikowałem uprawnienia aby można było uruchomić skrypt:
Po uruchomieniu skanera znalazłem coś co można spróbować wykorzystać do eskalacji uprawnień – shella, który uruchamiany jest jako root i którego możemy modyfikować:
Znalazłem komendy które może wykonywać każdy użytkownik z uprawnieniami właściciela pliku. W śród nich widać komendę run_container.
find / -perm 4000 2>/dev/null
/ -przeszukiwanie zaczyna się od głównego katalogu
-perm 4000 – cyfra 4 na początku oznacza bit SUID. Ustawienie tego bitu na pliku który można wykonać skutkuje uruchomieniem z uprawnieniami właściciela, a nie użytkownika uruchamiającego
2>dev/null – przekierowanie błędów do „czarnej dziury” – skutkuje ukryciem komunikatów o braku uprawnień
Aby sprawdzić czy ta komenda odnosi się do skryptu który możemy modyfikować użyłem komendy strings. W wyniku widać, że komenda odwołuje się do skryptu który nas interesuje:
Skopiowałem więc bliki /bin/bash do lokalizacji w której aktualnie się znajduję, uruchomiłem skopiowanego shella i wziąłem się do modyfikowania skryptu do którego mamy dostęp:
W skrypcie dołożyłem fragment w którym znowu kopiuję /bin/bash i nadaję uprawnienia do uruchamiania dla wszystkich jako root poprzez parametr +s (setuid)
Następnie uruchomiłem komendę run_container i plik bash został utworzony
Widać, że plik jest wykonywalny jako root:
Uruchomiłem więc shella z parametrem -p (tryb uprzywilejowany – z podniesieniem uprawnień) i sprawdziłem z jakimi uprawnieniami uruchomiła się konsola – root! Przeszedłem do lokalizacji w której spodziewałem się odnaleźć ostatnią flagę:
CTF rozwiązany!
DTM 