Titanic

I think this was the fastest user flag I’ve got so far, but root took me a while. I also wonder if I got the foothold in the intended way. Most importantly, one of the lessons learned with another (still active) box was to do my CVE research more breadth-first instead of going deep on the first option… and I probably over-compensated for this one. Let’s go through it:

Glitch string quartet music on

These Linux boxes usually start the same way, a quick nmap scan showing SSH & HTTP only, and the full TCP scan confirming it later on:

Logistics (/etc/hosts) taken care of, we go have a look at the web app, which lets you book a ticket on the Titanic. I wouldn’t, if I were you. But it looks like we have to, so we do, and it immediately triggers the download of a JSON file containing whatever details we provided, for example, http://titanic.htb/download?ticket=53b1bb14-044c-4b9b-9d19-f7e17b97ad92.json.

There’s nothing interesting about the file itself and it doesn’t look like it can be abused much. But every time we have an endpoint that lets us download a file by name we are compelled to just try something and see what happens… and sure enough it is vulnerable to arbitrary file read via path traversal:

[Hacker voice] we’re kinda in, so this gives me my fastest user flag to date. Trying things out to see what else we can get (sadly there’s no private SSH key, for example), and seeing in the response headers that we’re dealing with Werkzeug as a web app framework, we can hope there is a titanic.py or app.py file. The latter does hit, but it doesn’t tell us anything about the application that we don’t already know.

Not finding much, we go back to our basic checklist, and run directory and vhost enumeration. This is how we find out about dev.titanic.htb:

This is a Gitea site, a source code repository system similar to Github. We can register an account, and that might have opened other cans of worms that I didn’t explore. Maybe that was the intended route… But without even needing to register, we can browse the source code for the app and some docker-compose files.

One of these is for a MySQL database container and includes some credentials. I spent a bit of time (more than I wanted to due to some kind of fail2ban…) trying these, and some modifications of these, on SSH. No luck.

Google-fu

Assuming these credentials were meant for later, I switched attention to the compose file for Gitea itself. The interesting thing was the volume path, /home/developer/gitea/data/, which I could confirm was live with the original file read vulnerability on the site, since providing existing folders to the download endpoint caused an internal server error. I spent quite a bit of time here, either on Gitea’s documentation or on other random Google results, trying to figure out the names of configuration files, but more importantly the right path for any files inside that volume. I finally came across this post by an equally confused user. So the path goes gitea/, data/, … and then gitea/ again, for whatever reason. From there I could finally find what I was looking for, like the app’s configuration file, which pointed us to something valuable:

Using the same technique to get the file, we go straight for the credentials.

Hashcat’s example hashes for PBKDF2 don’t provide a clear match, so I’m back googling for how to properly feed these to the fluffy hash muncher. HTB is slowly eating the world, so one of 0xdf’s write-ups for an old machine came up. It sounded awfully similar to this machine going by the description, though, and I’ve had enough close encounters with spoilers, so I kept looking. Someone wrote a pull-request for Hashcat to add a gitea2hashcat.py (in February, so maybe while working on this box, hah!), and despite not yet being accepted at the time of writing, the code does what it says on the tin. I made a small modification to clean up the output, ran the script to extract the hashes and let Hashcat munch on them. developer’s password comes up quickly (administrator’s doesn’t, as expected, so we kill the process):

We finally have a foothold. Euh, I mean, [hacker voice] we’re in. The flag was already in the pocket, so it’s’ time to look for a way to escalate privileges.

Tragic hijack

Going through the privilege escalation checklist, we find that /opt has interesting things going on. There’s a folder with the same ticket-booking application we know well at this point, and a scripts folder with a single such thing inside:

This metadata.log in /opt/app/static/assets/images is owned and only writeable by root, and we soon realise that it’s being re-written every minute, indicating that, well, the script above is being run every minute by root. Subverting it in some way will give us what we want.

There are a few binaries in that script that are being called without their full path, so I spent some time trying to figure out if this was exploitable by checking for common PATH directories where we could write. Eventually convinced that this was not the way, I started looking for CVEs in ImageMagick.

The very first one I found, because I looked up the exact version of the binary (7.1.1-35) as one should always do, looked promising. If I had just tried it, it would have just worked. But since I had gotten myself in rabbit holes recently for going too deeply into the first thing I’d found, I just noted it down and moved on. In a less specific search, I found out about ImageTragick, a suite of old vulnerabilities, and I think I decided this must be it because the name was great. Yes, instead of going deeply into the first thing, I went deeply into the second thing.

After a good while trying to understand why the tragic JPG files I was creating were apparently not even being processed, I remembered the original promising CVE and finally gave that a try. It exploits an empty LD_LIBRARY_PATH environment variable, so if we place a malicious library file in the scripts directory, it will be loaded when /usr/bin/magick is executed. We’ll make it maliciously connect back to us:

Once the minute passes and identify_images.sh runs, we get our root shell:

Roll the credits

• Sometimes you find the information you need in the weirdest places. I’m not sure LLMs can figure that out, so I’m glad I’m an old Googler.
• Machines are getting retired in an awkward order, but this was not the first time I fumbled my CVE research. I can do better.
• As always, for reading this far, you’re a champ.