Titanic writeup
Titanic is a Linux box that starts with a local file inclusion (LFI) vulnerability in a Flask web application. We will discover a subdomain, extract credentials from a Gitea instance, crack hashes, and escalate privileges via an ImageMagick configuration‑path vulnerability (GHSA‑8rxc‑922v‑phg8).
titanic.htb has two ports open: 22 (SSH) and 80 (web).
On the web server we can book a trip.
Which redirects us to a <uuid>.json file.
If it were just a UUID, it could be seen as an SQL query context where SQL injection would be interesting; however, because it’s a .json, it looks more likely to have an LFI in case there is no validation in place.
And it works.
/proc/self/cwd points to our current directory, so something like /proc/self/cwd/app.py (default for Flask) can be used to enumerate files in the current directory, including application source code.
Using /etc/passwd and grepping for /home you can see all users that have a home directory. We see that there is a developer user who has one, then use /home/developer/user.txt to get the home flag.
ffuf vhost enumeration finds a .dev subdomain.
We could also find this using the LFI vulnerability earlier by checking /etc/hosts.
After adding this new host to /etc/hosts we can find exposed credentials in a repo published on this Gitea instance.
The second config exposes that the Gitea instance is located at the developer’s home directory, so by investigating the directory structure in Gitea (because it’s open source) we can find the location of its database and exfiltrate it with our LFI vulnerability.
The gitea2hashcat.py script can help convert this data into crackable passwords:
Don’t forget to delete anything that’s not a hash from the file.
Then run hashcat:
Example hash line:
sha256:50000:i/PjRSt4VE+L7pQA1pNtNA==:5THTmJRhN7rqcO1qaApUOF7P8TEwnAvY8iXyhEBrfLyO/F2+8wvxaCYZJjRE6llM+1Y=:25282528
One of them gets recovered, the password being 25282528, which is the developer’s password for SSH.
Inside SSH:
/opt/ has a scripts directory containing identify_images.sh.
By going to this images directory you can see that metadata.log is created very recently, hinting that it’s executed very often, likely by a cron.
Files are passed to ImageMagick as an argument, so let’s check ImageMagick’s version to look for vulnerabilities:
The search returns useful results:
https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-8rxc-922v-phg8
“Additionally, if MAGICK_CONFIGURE_PATH and LD_LIBRARY_PATH are not set, AppRun will append an empty path to MAGICK_CONFIGURE_PATH and LD_LIBRARY_PATH.
This results in while the ImageMagick is executing, it might use current working directory as the path to search for the configuration file or shared libraries, because empty path in these environment variables means the current working directory.
Which means it might load the delegates.xml or shared libraries from the current working directory.
So if an attacker can control the file in the current working directory while the ImageMagick is executing, it might lead to arbitrary code execution by loading malicious configuration file or shared libraries.”
This command would create a library in our present working directory having instructions to execute our reverse‑shell code, and because the environment variable would be empty in this version, ImageMagick would also seek for it in our PWD, thus reading our library and executing code.
Credentials
sql_svc:MySQLP@$$w0rd!