HackTheBox Photobomb

Hey guys! This is my first CTF writeup, red teaming is a new thing to me! Let’s get started!

I’m starting with Photobomb from HackTheBox. It’s an easy CTF but I’m pretty new to pentesting so it’s a good challenge for me.

I’ve been told it’s good practice to add the box name to your /etc/hosts file before you get started. So I’ve added to /etc/hosts

10.10.11.182   photobomb.htm

My first instinct on any new box is to run masscan

masscan -p1-65535,U1:65535 10.10.11.183 --rate=1000

But in this situation, I got nothing back.

My next instinct is to run a ffuf directory scan to see what directories we have on this site.

ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt -u http://photobomb.htb/FUZZ  

I visited the site in my browser which returned a web page so I’m not sure why masscan turned up no open ports, but let’s keep going. At least we have some results from ffuf.

Visiting the site in my browser gave me a web page with a link that says “click here”. Of course, clicking this link asks for a password, which I don’t have.

Spoilers for the HTB are ahead, so if you have not completed this box, be warned.

My first instinct when I encounter a web page is to open the inspector and see what the source code says. This is a great way to find business logic flaws. In this instance, I see a link to a Javascript file in the header.

Viewing this JS file, there are hardcoded credentials listed in the JS code. If we plug those creds into the http://photobomb.htb/printer page, we get passed right in.

From here, we can only check which picture we want, then download it. I tried a few things for LFI, I tried looking through the code, but I was unable to find anything else to do. Nothing seemed to change the URL in my browser, which would allow me convenient access to URL parameters that I could play with. So I loaded up Burp Suite to continue playing with the URL.

I set my Burp Proxy to intercept and tried to download a picture from the website.

python3 -m http.server 8081

After trying every field, I was able to get the server to make a connection with the “filetype” parameter.

So I opened a netcat listener and added the Python reverse shell into Burp and viola… a revshell!

The next thing to do is run “sudo -l” to see what this user has permissions for. In this case, the user owns a file called /opt/cleanup.sh

Checking this file, I see a command being run that says “cd /home/wizard/photobomb”. Since the command “cd” is being run from a relative path, the next course of action is obvious: override the path for the “cd” command!

I switched directories to /tmp then created a new file for “cd” by running the command “echo “/bin/bash” > /tmp/cd”. This adds a file in my own local directory called “cd” that just opens a bash session when the command is run. I set this command to executable with “chmod +x cd” and added this to my path with the command “sudo PATH:$PWD:$PATH /opt/cleanup.sh”. When I hit the enter key, I was root.

From here, finding the root flag was pretty trivial.

Lessons Learned

This was the easiest HackTheBox machine to get into. Getting root was far easier than getting the user flag. This writeup makes it seem very easy, but for me it took about an hour to get to the user flag. After that, it took maybe 10 minutes to get to the root flag. Finding the vulnerability for the user was difficult, escalating afterwards was pretty easy. I went into this challenge with an open mind and ran several tools that did not work out (like masscan). Luckily, the web site in the challenge exposed enough information for me to continue.

The biggest lesson for me is, if you’re exposed to a situation where you might be able to crack the security, set up a local webserver or netcat listener while you are testing. That gives you an idea of if your commands are being executed or not.

Blue Team Recommendations

For my recommendations on how to avoid/detect this activity…

First off, I feel like anyone running “sudo -l” should be suspicious. Asking your colleagues why they’re running this command shouldn’t be too hard. There may be a legitimate reason that you never knew of!

More importantly, your developers should be running an allow-list of commands. Running commands outside of what is normally accepted should not be allowed. If a user never needs to run a command separated by a semi-colon, the semi-colons should not be allowed. Defensive programming would have prevented this situation.

Lastly, it’s good Linux/Unix practice to use full paths for commands being run. If you want to use the “cd” command, it’s good practice to use the full path. Otherwise, the path could be overwritten!