Write-Up

Step-by-step guide on the approach taken to pwn the machine.

Objective

The goal of this machine is to "find the flag."

Reconnaissance

We start by scanning the open ports of the target machine using nmap:

sudo nmap -F -T5 -sCV <ip_target>

  • -F scans the 100 most common ports

  • -T5 performs a fast, aggressive scan

  • -sC runs default scripts for common vulnerabilities

  • -sV provides service version information

The open ports are:

  • 22 - SSH

  • 80 - HTTP

Accessing the Web Application

We first navigate to port 80:

http://<ip_target>:80

The website redirects us to titanic.htb, so we need to add this to our /etc/hosts file:

sudo vim /etc/hosts

After editing the hosts file, we retry accessing the website.

Website Navigation

On the website, we quickly realize that the only functional buttons are "book your trip" and "book now," both of which lead to the same form. When we fill and submit the form, a JSON file is downloaded.

At this point, we decide to explore the directories on the server. For this, we use gobuster:

gobuster dir -u http://titanic.htb -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

We find two interesting directories:

  • /download

  • /book (this leads to the JSON form)

Let's check out /download.

Local File Inclusion (LFI) and Discovery of User

In the /download directory, we notice that the ticket parameter is required. We try performing Local File Inclusion (LFI) by modifying the URL:

http://titanic.htb/download?ticket=../../../../etc/passwd

We successfully download the file and save it as passwd.titanic.json. Let's use grep to find user information:

cat passwd.titanic.json | grep home/

We discover the developer user. Next, we attempt to brute-force the SSH login using hydra:

hydra -l developer -P /usr/share/wordlists/rockyou.txt ssh://titanic.htb

However, we encounter a "connection refused" error. Despite this, we now have LFI, so let's explore other files.

Discovering a Subdomain

We attempt to access /etc/hosts using LFI:

http://titanic.htb/download?ticket=../../../../etc/hosts

This reveals a subdomain: dev.titanic.htb. We add this to our /etc/hosts and navigate to it.

Accessing Gitea

The subdomain leads us to Gitea, a self-hosted Git service. We see a login page, so we try logging in with developer:developer, but we get an error. To verify if "developer" is a valid username, we create a new user, developer.

We can confirm that "developer" is already taken. Now, we create a new user, developer1.

We navigate through the "Explore" section and find the docker-config repository under the developer user.

Inside the repository, we explore the mysql folder and discover database credentials for the ticketing system. We try connecting via MySQL using DBeaver, but we don't get access.

Investigating the Gitea Repository

The docker-config repo contains a README.md file with information on how the ticketing system works. We also see an app.py file that contains route definitions, but nothing out of the ordinary. The static folder contains a .css file, and the templates folder contains an .html file. The only remaining folder is tickets.

We explore the tickets folder and find ticket data, but there's nothing immediately useful. However, based on Gitea's documentation, we learn that it stores the database at:

%(APP_DATA_PATH)/gitea.db

Using LFI to Access the Database

We go back to the /download directory and modify the URL to access the Gitea database file:

http://titanic.htb/download?ticket=/home/developer/gitea/data/gitea/gitea.db

We open the database and navigate to the user table.

Here, we find the hash and salt for the developer user. To crack this, we use the gitea2hashcat Python script to extract the hash and salt, then run hashcat to brute-force the password:

hashcat -m 10900 hashdeveloper.txt /usr/share/wordlists/rockyou.txt

After a while, we successfully recover the password and log into SSH as developer.

Privilege Escalation

Now that we have SSH access, we attempt to escalate privileges. We first check for sudo permissions and SUID binaries, but nothing useful comes up. We decide to investigate manually.

We navigate to the /opt directory, where third-party software is stored. Here, we find a script named identify_images.sh. After examining the script, we notice it uses ImageMagick.

Running magick --version reveals that the version of ImageMagick installed is 7.1.1-35. We search for known vulnerabilities in this version and find CVE-2024-41817, which allows arbitrary code execution.

Exploiting ImageMagick Vulnerability

We create a shared library in the current directory to obtain root privileges and run cat root.txt to capture the flag.

With a simple cat root.txt the flag is our.

PreviousTitanicNextTechnical Report

Last updated