Hello everyone! Back with another TryHackMe CTF Walkthrough. This time, we will check out Marketplace CTF. Marketplace is a medium difficulty machine and according to its tags, we are expecting some cross-site scripting (XSS), SQL injection(SQLi) and Docker vulnerabilities.
In my opinion, it seems we will be dealing with a couple of interesting things, so let’s jump into it.
Let’s see what Nmap will find for us. Here is the output:
root@ip-10–10–65–211:~# nmap -sC -sV 10.10.249.67
Starting Nmap 7.60 ( https://nmap.org ) at 2020–12–31 09:39 GMT
Nmap scan report for ip-10–10–249–67.eu-west-1.compute.internal (10.10.249.67)
Host is up (0.00042s latency).
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 c8:3c:c5:62:65:eb:7f:5d:92:24:e9:3b:11:b5:23:b9 (RSA)
| 256 06:b7:99:94:0b:09:14:39:e1:7f:bf:c7:5f:99:d3:9f (ECDSA)
|_ 256 0a:75:be:a2:60:c6:2b:8a:df:4f:45:71:61:ab:60:b7 (EdDSA)
80/tcp open http nginx 1.19.2
| http-robots.txt: 1 disallowed entry
|_/admin
|_http-server-header: nginx/1.19.2
|_http-title: The Marketplace
32768/tcp open http Node.js (Express middleware)
| http-robots.txt: 1 disallowed entry
|_/admin
|_http-title: The Marketplace
MAC Address: 02:DB:A9:4C:82:A7 (Unknown)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernelService detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 29.83 seconds
From the enumeration done, there must be some kind of web application running on the server, as we can see Nginx/Node.js services running on port 80 and 32768 correspondingly. Visiting both ports, we verify that there is a website named “Marketplace” on ports. Another useful info, is the /admin directory, however, upon visiting it, we can see that we do not possess the adequate rights to access it.
Last but not least, there is a SSH service on default port 22, but it seems useless as of now. For the time being, let’s just focus on the WebApp.
Really quickly, I headed for the Sign Up link in order to check if I can register a new user. Indeed, we were able to add it and login, with limited access as we are still unable to access /admin. The next thing , I wanted to check after logging in was the session cookie. At first look, we can understand that the cookie has a JWT format, so I headed to jwt.io in order to check if I could a extract any valuable hint from it. What I got can be seen on the screenshot below.
On the Payload section of the cookie, we can see the username of our newly created user, its id, as well as user’s privilege status. Instinctively, I changed the admin parameter from false to true, because I thought that I could generate a cookie with elevated privileges for my user, but unfortunately, this did not work. So, I moved into checking the rest of the site’s tabs.
What caught my attention was the New Listing tab, through which the user is able to add new items into the Marketplace. The first thing that we could try here is to try out some XSS payload in order to check if there is any input validation in place. The payload I used for the test was the following:
<script>alert(“Iamvulnerable”)</script>
So, now that we are sure that our target is vulnerable to a stored XSS attack, we can work into exploiting it, by crafting our XSS payload (in our case a fake url that redirects to our machine the session cookie of any user that requests the item that contains the malicious piece of code) and triggering a NetCat session listening on port 8001. The payload used can be seen below:
As soon as, we submitted the new item, we can see on our NetCat session our own cookie, as we are the first user that visited the new item’s page. That’s a good sign, that our stored XSS is working. Now, we should think of a trick in order to temp an administration user to visit the page. The report action that can be found on the rest of the items could make the work for us, so we head into /report/4 (4 is the id of the item that was assign upon the item registration). No long ago after we have submit the report, we can see a new cookie on the NetCat console.
Before using the cookie that we gained, let’s check out its properties using jwt.io once more. As we can see the cookie belongs to user ‘michael’ and seems to be an authorized administrator.
On the Developer Tools, under the tab Storage, we can find our current cookie session stored. Changing its value with Michael’s cookie and refreshing the page, had as a result to get the privileges that needed in order to access /admin directory. There we can see a list of the currently registered users. The very interesting thing that we can see is that if we change the id of the user we are prompt to their corresponding info page. That is some kind of indication that the application might be vulnerable to a SQLi, as well. So, let’s put it into test.
With the above, we verified our suspicion. Indeed, we are dealing with a vulnerable MySQL database. We could perform the attack manually, however I preferred the SQLMap (I am kind of a nood with SQL queries, but I promise that I will fix that :) ).
The very first thing that we will have to do is to record the HTTP request, as it is needed by SQLMap in order to run through the marketplace’s DB. I chose Burp Suite for this, but the request can be, also, recorded through the Developer tools.
Now that we have our HTTP request record, we can trigger SQLMap. The attack technique that I used was the Union (technique=U) and I set the type of the db to MySQL (dbms=MySQL). With -r flag, we can provide the file that contains our HTTP request and we’ve, also, added a delay.
From the above screenshot, we can see that the user column is vulnerable. As soon as the process is finished, we will need to re-trigger the process once more in order to extract the name of the DB (which it comes as no surprise that is named “marketplace”).
Using its name, we can dump the whole of the database.
After searching for a while, we found an interesting entry on the messages.csv, a message for user 3 (which corresponds to ‘Jake’ if we check the administration panel), which includes his SSH password in plain text.
So let’s SSH with Jake. The first thing that we would like to do is to check if we can perform any commands or scripts with sudo rights. Indeed, there is a backup.sh that we can execute as ‘michael’. If we take a look into the script, we can see a tar command along with a wild card. Here is a list of tar vulnerabilities that could be combined with a wildcard injection in order to elevate our rights.
We’ve switched to Michael user, a docker user as well. Indeed, there are a couple of images downloaded and we can use any of them to gain root access. This is due to a well-known Docker vulnerability. So, I’ve chose the nginx image and started a container in interactive mode and mounted on it the root directory. As soon as we got into the container, we can see that we have gained root access and under the /mnt/root directory, we can find the root.txt.
Thoughts on the Marketplace CTF
This CTF combined a good deal of vulnerabilities and it can be seen as a depiction of a real world scenario. Anyone that wants to practice their XSS and SQLi skills should definitely give it a try.
Also, a part from the way, I described above, there are multiple other variations for performing the XSS and SQLi exploitations (such as use different kinds of payloads, try manual SQL queries to get your hands into the DB etc.), so take your time with the machine and experiment as much as you can. ;)
I hope you enjoyed this walkthrough!
Up until next time, stay safe and keep hacking! :)
