Nexus to linuksowa maszyna o poziomie trudności Easy. Zaczynam od rekonesansu hosta i jego subdomen. W historii commitów Gitea znajduję hasło, które pozwala mi zalogować się do Krayin CRM. Z panelu uzyskuję powłokę jako www-data, a po odnalezieniu kolejnych poświadczeń przechodzę na konto innego użytkownika. Podczas dalszego rekonesansu sprawdzam usługę synchronizacji szablonów Gitea. Działa jako root i wskazuje na możliwość directory traversal, której jednak nie wykorzystuję.

Skanowanie i identyfikacja hosta

Najpierw skanuję wszystkie porty TCP:

  • -p- obejmuje pełny zakres portów.
  • --open pokazuje tylko otwarte porty.
  • -sV próbuje ustalić wersje usług.
nmap -p- --open -sV 10.129.234.54

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.16
80/tcp open  http    nginx 1.24.0 (Ubuntu)

Serwer WWW przekierowuje na domenę nexus.htb. Dodaję więc adres IP maszyny do pliku /etc/hosts, aby domena była rozwiązywana lokalnie:

10.129.234.54   nexus.htb

Enumeracja aplikacji i subdomen

Strona główna jest statyczna i nie ma widocznych podstron. Zapisuję jednak adres e-mail managera: j.matthew@nexus.htb. Następnie sprawdzam, czy na serwerze są dostępne dodatkowe ścieżki. Do skanowania używam ffuf, a parametrem -fc pomijam odpowiedzi o kodach 403 i 302:

ffuf -u http://nexus.htb/FUZZ -fc 403,302 -w /usr/share/seclists/Discovery/Web-Content/common.txt

Potem szukam subdomen. FUZZ zastępuje kolejne nazwy z listy w nagłówku Host, a -ac włącza automatyczne kalibrowanie wyników:

ffuf -u http://nexus.htb -H "Host:FUZZ.nexus.htb" -ac -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt

Skanowanie ujawnia dwie domeny. Dopisuję je do /etc/hosts i sprawdzam dostępne pod nimi aplikacje. Na jednej ze stron znajduję ogłoszenie rekrutacyjne, które pomaga ustalić prawidłowe nazwy użytkowników.

Repozytorium Gitea i hasło w historii

Jedna z domen prowadzi do repozytorium Gitea. Znajdują się w nim między innymi pliki:

  • .env
  • docker-compose.yml

Przeglądam historię commitów i znajduję w niej hasło do bazy danych.

Logowanie do Krayin CRM

Pod drugą domeną działa panel billingowy oparty na Krayin CRM. Widoczny pasek debugowania pokazuje, że aplikacja udostępnia informacje diagnostyczne. Na stronie głównej znajduję adres e-mail managera, a w repozytorium hasło. Używam tych danych do logowania i dostaję się do panelu.

Przeglądam funkcje CRM i trafiam na formularz wysyłania wiadomości e-mail z załącznikiem. W Burp Suite analizuję żądanie i odpowiedź serwera. Po dodaniu pliku odpowiedź zawiera jego pełną ścieżkę na serwerze. Wykorzystuję tę informację do uruchomienia przesłanego skryptu PHP.

Powłoka jako www-data

Pobieram skrypt PHP typu reverse shell i ustawiam w nim adres IP swojej maszyny. Uruchamiam nasłuch na porcie 1234:

nc -lvnp 1234

Wysyłam skrypt przez formularz, a następnie uruchamiam go pod ścieżką zwróconą przez serwer. Otrzymuję interaktywną powłokę jako www-data.

Zaczynam od sprawdzenia katalogów domowych i plików aplikacji w /var/www. W jednym z podkatalogów znajduję plik .env z kolejnym hasłem. Używam go do logowania przez SSH na konto jones. W katalogu domowym tego użytkownika znajduje się user.txt z flagą.

Dalszy rekonesans: usługa Gitea

Po zalogowaniu jako jones wracam do pytania o usługę synchronizującą szablony Gitea. Sprawdzam działające usługi i ich konfigurację. Ustalam, że usługa działa jako root. Zauważam też możliwość directory traversal, która mogłaby prowadzić do eskalacji uprawnień. Na tym kończę analizę: nie uruchamiam exploitu i nie uzyskuję powłoki roota.

Podsumowanie

W trakcie zadania przechodzę od rekonesansu hosta i subdomen do dostępu do Krayin CRM. Hasło znalezione w historii Gitea pozwala mi zalogować się do panelu, a formularz załączników daje możliwość uruchomienia reverse shella jako www-data. Kolejne poświadczenia z pliku .env umożliwiają logowanie SSH na konto jones. Na tym etapie rozpoznaję usługę Gitea działającą jako root i możliwość directory traversal, ale jej nie wykorzystuję.

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