Titanic
Foothold
Si mappa l’IP della macchina con l’hostname titanic.htb nel file /etc/hosts.
Si effettua una scansione TCP e si ottiene
kali@0xPR3ST1JH0NN7:~$ sudo nmap -sV -vv -oN tcp.txt titanic.htb
# Nmap 7.94SVN scan initiated Sat Mar 1 15:17:19 2025 as: /usr/lib/nmap/nmap -sV -vv -oN tcp.txt titanic.htb
Nmap scan report for titanic.htb (10.10.11.55)
Host is up, received reset ttl 128 (0.011s latency).
Scanned at 2025-03-01 15:17:19 CET for 16s
Not shown: 998 filtered tcp ports (no-response)
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 128 OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
80/tcp open http syn-ack ttl 128 Apache httpd 2.4.52
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Read data files from: /usr/share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Mar 1 15:17:35 2025 -- 1 IP address (1 host up) scanned in 16.57 seconds
Ci sono due servizi attivi sulla macchina, SSH sulla porta 22 e HTTP sulla porta 80. Il web server sulla porta 80 è un Apache 2.4.52.
Esplorando l’applicazione web si individua una funzionalità di booking, sulla quale si conducono dei test mirati per verificarne le vulnerabilità.
Inviando una prenotazione tramite la funzionalità di booking viene effettuata la seguente richiesta GET.
Richiesta
GET /download?ticket=6c5ff98d-046e-4958-9061-ba9ffc5c0c34.json HTTP/1.1
Host: titanic.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: http://titanic.htb/
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Priority: u=0, i
Osservando la struttura della richiesta GET si verifica se sul parametro “ticket” è presente una vulnerabilità di tipo Path Traversal.
Utilizzando le seguenti payload si ottengono dei risultati.
../../../etc/passwd
../../../etc/hosts
La prima payload permette di leggere il nome dell’utente developer, che potrebbe essere utile per accedere alla macchina.
Con la seconda, si nota un sottodominio dev.titanic.htb da analizzare.
Accedendo al nuovo virtual host ci si trova su un’istanza dell’applicazione gitea. Nella sezione “explore”, in “developer/docker-config”, si trovano due cartelle, gitea e mysql.
Nella cartella gitea è presente un file docker-compose.yml con il seguente contenuto.
Sfruttando il percorso noto e la vulnerabilità di Path Traversal, si punta ai file di configurazione di Gitea, in primis app.ini, prendendo spunto dalla documentazione.
Consultando la guida per i deployment basati su Docker, si nota un paragrafo in cui si specifica che i file di configurazione personalizzati vengono salvati all’interno della cartella “/data/gitea”.
Unendo i pezzi, si sfrutta la vulnerabilità per leggere il file app.ini nel percorso “/home/developer/gitea/data/gitea/conf/app.ini”.
La lettura va a buon fine ed espone parametri particolarmente utili per il prosieguo dell’attacco.
In particolare, questo file contiene il riferimento a un altro file gitea.db. Scaricandolo, si effettuano alcune query con sqlite3 sulla tabella user, considerando solo i campi rilevanti, come mostra la seguente evidenza.
sqlite> select name,email,passwd,salt,passwd_hash_algo from user;
name|email|passwd|salt|passwd_hash_algo
administrator|root@titanic.htb|cba20ccf927d3ad0567b68161732d3fbca098ce886bbc923b4062a3960d459c08d2dfc063b2406ac9207c980c47c5d017136|2d149e5fbd1b20cf31db3e3c6a28fc9b|pbkdf2$50000$50
developer|developer@titanic.htb|e531d398946137baea70ed6a680a54385ecff131309c0bd8f225f284406b7cbc8efc5dbef30bf1682619263444ea594cfb56|8bf3e3452b78544f8bee9400d6936d34|pbkdf2$50000$50
Per craccare le password si utilizza hashcat, quindi si crea un file hashes.txt con gli hash trovati. Il formato utilizzato è il seguente: username, iterazioni, formato SHA-256 per PBKDF2, salt e hash codificato in Base64.
administrator:sha256:50000:MmQxNDllNWZiZDFiMjBjZjMxZGIzZTNjNmEyOGZjOWI=:Y2JhMjBjY2Y5MjdkM2FkMDU2N2I2ODE2MTczMmQzZmJjYTA5OGNlODg2YmJjOTIzYjQwNjJhMzk2MGQ0NTljMDhkMmRmYzA2M2IyNDA2YWM5MjA3Yzk4MGM0N2M1ZDAxNzEzNg==
developer:sha256:50000:OGJmM2UzNDUyYjc4NTQ0ZjhiZWU5NDAwZDY5MzZkMzQ=:ZTUzMWQzOTg5NDYxMzdiYWVhNzBlZDZhNjgwYTU0Mzg1ZWNmZjEzMTMwOWMwYmQ4ZjIyNWYyODQ0MDZiN2NiYzhlZmM1ZGJlZjMwYmYxNjgyNjE5MjYzNDQ0ZWE1OTRjZmI1Ng==
Si lancia il seguente comando
kali@0xPR3ST1JH0NN7:~$ hashcat hashes.txt --wordlist /usr/share/wordlists/rockyou.txt --user
Hashcat fornisce la password per l’utente developer e attraverso le credenziali developer:25282528 si accede alla macchina in SSH.
Foothold ottenuto e si prende la flag user.txt.
Privilege Escalation
Effettuando un’enumerazione manuale dei processi attivi si nota un’applicazione app.py avviata dalla cartella “/opt/app”.
Nella cartella /opt è presente un’altra cartella “scripts” contenente uno script chiamato identify_images.sh.
Il contenuto dello script sembra richiamare tutti i file con estensione .jpg in un percorso, prenderne i metadati attraverso l’utility magick e inserirli nel file metadata.log.
Tentando l’esecuzione manuale dello script viene restituito un errore di permessi negati per la scrittura sul file metadata.log. Una verifica dei privilegi conferma infatti che il file risulta di proprietà dell’utente root.
Questa configurazione lascia ipotizzare la presenza di un cron job di sistema incaricato di eseguire periodicamente lo script con privilegi elevati.
L’utility magick ha la versione 7.1.1-35 e si effettuano delle ricerche su CVE note con exploit al seguito.
La versione individuata risulta affetta dalla vulnerabilità CVE-2024-41817, la quale consente l’esecuzione di codice arbitrario tramite il caricamento di librerie condivise malevole situate nella working directory corrente durante l’esecuzione di ImageMagick. I dettagli operativi e una dimostrazione pratica della falla sono consultabili tramite la PoC disponibile al seguente link.
Poiché la cartella di lavoro dello script è impostata su “/opt/app/static/assets/images” e si dispone dei permessi di scrittura su quel percorso, si procede con l’esecuzione dell’exploit mostrato di seguito.
Si rimane in attesa per verificare l’effettiva presenza del cron job. A distanza di breve tempo, l’ispezione del file metadata.log ne conferma l’esistenza tramite il seguente output.
Viene lanciata la seguente payload per aprire una reverse shell.
Una volta posto il listener in ascolto, viene intercettata la connessione remota dopo un breve intervallo di tempo.
Shell ottenuta! Si invia la flag root.txt.
Foothold
First we map the machine’s IP to the hostname titanic.htb in the /etc/hosts file.
We run a TCP scan and get
kali@0xPR3ST1JH0NN7:~$ sudo nmap -sV -vv -oN tcp.txt titanic.htb
# Nmap 7.94SVN scan initiated Sat Mar 1 15:17:19 2025 as: /usr/lib/nmap/nmap -sV -vv -oN tcp.txt titanic.htb
Nmap scan report for titanic.htb (10.10.11.55)
Host is up, received reset ttl 128 (0.011s latency).
Scanned at 2025-03-01 15:17:19 CET for 16s
Not shown: 998 filtered tcp ports (no-response)
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 128 OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
80/tcp open http syn-ack ttl 128 Apache httpd 2.4.52
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Read data files from: /usr/share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Mar 1 15:17:35 2025 -- 1 IP address (1 host up) scanned in 16.57 seconds
There are two services running on the machine, SSH on port 22 and HTTP on port 80. The web server on port 80 is an Apache 2.4.52.
Exploring the web application we find a booking feature, on which we run targeted tests to check for vulnerabilities.
Submitting a booking through the feature triggers the following GET request.
Request
GET /download?ticket=6c5ff98d-046e-4958-9061-ba9ffc5c0c34.json HTTP/1.1
Host: titanic.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: http://titanic.htb/
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Priority: u=0, i
Looking at the structure of the GET request we check whether the “ticket” parameter is affected by a Path Traversal vulnerability.
Using the following payloads we get some results.
../../../etc/passwd
../../../etc/hosts
The first payload lets us read the name of the developer user, which could be useful to access the machine.
With the second one we notice a dev.titanic.htb subdomain to analyze.
Accessing the new virtual host we land on a gitea application instance. In the “explore” section, under “developer/docker-config”, we find two folders, gitea and mysql.
In the gitea folder there is a docker-compose.yml file with the following content.
Using the known path and the Path Traversal vulnerability, we aim at the Gitea configuration files, first of all app.ini, taking a hint from the documentation.
Checking the guide for Docker based deployments, the Docker documentation, we notice a paragraph stating that the custom configuration files are saved inside the “/data/gitea” folder.
Putting the pieces together, we exploit the vulnerability to read the app.ini file at the “/home/developer/gitea/data/gitea/conf/app.ini” path.
The read succeeds and exposes parameters that are particularly useful for the rest of the attack.
In particular, this file references another file gitea.db. After downloading it, we run some queries with sqlite3 on the user table, considering only the relevant fields, as shown below.
sqlite> select name,email,passwd,salt,passwd_hash_algo from user;
name|email|passwd|salt|passwd_hash_algo
administrator|root@titanic.htb|cba20ccf927d3ad0567b68161732d3fbca098ce886bbc923b4062a3960d459c08d2dfc063b2406ac9207c980c47c5d017136|2d149e5fbd1b20cf31db3e3c6a28fc9b|pbkdf2$50000$50
developer|developer@titanic.htb|e531d398946137baea70ed6a680a54385ecff131309c0bd8f225f284406b7cbc8efc5dbef30bf1682619263444ea594cfb56|8bf3e3452b78544f8bee9400d6936d34|pbkdf2$50000$50
To crack the passwords we use hashcat, so we create a hashes.txt file with the hashes found. The format used is the following: username, iterations, SHA-256 format for PBKDF2, salt and hash encoded in Base64.
administrator:sha256:50000:MmQxNDllNWZiZDFiMjBjZjMxZGIzZTNjNmEyOGZjOWI=:Y2JhMjBjY2Y5MjdkM2FkMDU2N2I2ODE2MTczMmQzZmJjYTA5OGNlODg2YmJjOTIzYjQwNjJhMzk2MGQ0NTljMDhkMmRmYzA2M2IyNDA2YWM5MjA3Yzk4MGM0N2M1ZDAxNzEzNg==
developer:sha256:50000:OGJmM2UzNDUyYjc4NTQ0ZjhiZWU5NDAwZDY5MzZkMzQ=:ZTUzMWQzOTg5NDYxMzdiYWVhNzBlZDZhNjgwYTU0Mzg1ZWNmZjEzMTMwOWMwYmQ4ZjIyNWYyODQ0MDZiN2NiYzhlZmM1ZGJlZjMwYmYxNjgyNjE5MjYzNDQ0ZWE1OTRjZmI1Ng==
We run the following command
kali@0xPR3ST1JH0NN7:~$ hashcat hashes.txt --wordlist /usr/share/wordlists/rockyou.txt --user
Hashcat provides the password for the developer user and with the credentials developer:25282528 we access the machine over SSH.
Foothold obtained and we grab the user.txt flag.
Privilege Escalation
During a manual enumeration of the active processes we notice an app.py application started from the “/opt/app” folder.
In the /opt folder there is another folder “scripts” containing a script called identify_images.sh.
The content of the script seems to call all the files with the .jpg extension in a path, grab their metadata through the magick utility and insert them into the metadata.log file.
Trying to run the script manually returns a permission denied error when writing to the metadata.log file. A check of the privileges indeed confirms that the file is owned by the root user.
This setup suggests the presence of a system cron job in charge of periodically running the script with elevated privileges.
The magick utility is at version 7.1.1-35, so we look for known CVEs that come with an exploit.
The identified version turns out to be affected by the CVE-2024-41817 vulnerability, which allows arbitrary code execution by loading malicious shared libraries located in the current working directory during the execution of ImageMagick. The operational details and a practical demonstration of the flaw are available through the PoC at the following link.
Since the working directory of the script is set to “/opt/app/static/assets/images” and we have write permissions on that path, we proceed with the execution of the exploit shown below.
We wait to verify the actual presence of the cron job. After a short time, the inspection of the metadata.log file confirms its existence through the following output.
We then launch the following payload to open a reverse shell.
Once the listener is set up, the remote connection is intercepted after a short interval.
Shell obtained! We submit the root.txt flag.