The Planets: Mercury Write-up

Did you know that Mercury’s mean diameter is 4880 kilometers?

Welcome to my first write-up/walktrough on a VulnHub machine. The machine is available at VulnHub.com. The machine emphasizes SQL injection and Linux Privilege Escalation. In this write-up, I did my best to not use any external tools other than the vulnerable machine and your favorite Linux Distro.

I assume that you have correctly set up a LAB network, separated from the ‘real’ internet. You can find the IP of your vulnerable machine using:

sudo netdisover

Mine is 192.168.56.127, so make sure you do not use the same :).

Reconnaissance

When you first get a machine, you should always do your best to get as much information as possible. This will result in solving the machine much faster. Nmap is a very good tool for this, and this is the only tool that does not come pre-installed on all distro’s (Kali has it though). We can scan our vulnerable machine very easily:

sudo nmap -n -sS -sV -p- --script=default 192.168.56.127 --vv

This is the script I most of the times use. It returns a lot of information (not everything is as useful) that we can use further on:

In this result we can see two open ports, namely 22 (SSH) and 8080 (webserver). Keep these two in mind, they are important. Let’s first check out the webserver. What does it show?

Not very much huh? Lets see what happens when we add some gibberish after the URL like depicted below:

That is interesting. This webserver seems to be running Django with Debug=True which you should never do. Luckily for us, we can find the entire URL configuration. I am mainly interested in the mercuryfacts/ page. Let’s check it out…

It has two pages, a To Do and a facts page. What is interesting about the fact page is its URL: 192.168.56.127:8080/mercuryfacts/1/. That one asks the server to display fact one. Let’s break this.

SQL Injection

In this debug information we can see that the string from the URL is directly used to do a query in their database. There should be a lot of alarms ringing in your head at this moment. Why? Because of the so-called SQL Injection attack. With this vulnerability an attacker can inject his own SQL commands into your system which can cause severe security issues. Look below for an example:

Here we can see that instead of one fact, we made this website display all facts. This is not that harmful, but there’s more. We can also write it like this:

192.168.56.127:8080/mercuryfacts/1 AND 2=1 UNION SELECT table_name FROM information_schema.tables/

Try it and observe closely what you see.

We are interested in the last entry of this result, namely the users table. We can open it using

192.168.56.127:8080/mercuryfacts/1 AND 2=1 UNION SELECT username FROM users/
and
192.168.56.127:8080/mercuryfacts/1 AND 2=1 UNION SELECT password FROM users/

The column names username and password were merely a lucky guess. I tried user and pass as well, but that did not return anything.

We now got a lot of interesting credentials. However, the only one we are interested in is the webmaster’s credentials: webmaster:x (find out the x yourself).

You can use these credentials to log in using SSH:

ssh webmaster@192.168.56.127

There we have it, the user_flag.txt. Good job. Now let’s escalate our privileges.

Privilege Escalation

Privilege Escalation is probably the most interesting part about security testing. It is probably also one of the hardest parts, since there are so many possibilities and creativity is really a must-have.

Explore all folders. There should be a note left for you with another pair of credentials:

We are interested in being a Linux master right? However that password is odd (and of course it is not an x, this is just so that you really learn it by doing it). It is encoded in base64 (the ending equal signs give it away). So we should first decode them (replace the x).

echo "x" | base64 -d

Now we can SSH into the linux webmaster account:

ssh linuxmaster@192.168.56.127

As always, a good thing to do when getting into an account is the following:

sudo -l

This gives us a list of all the things that can be run with root permissions, which we can use to escalate. What we find very interesting is that we can run /usr/bin/check_syslog.sh with sudo permissions. When you cat this file you can see that the tail command is being executed. We can take advantage of that by linking.

Linking let’s us run command A while calling command B and it is very easy. Just run:

ln -s /usr/bin/vim tail

From now, every time we run tail actually only the vim command is executed (inside vim it is possible to spawn a bash). To make sure everything will run correctly, let’s run:

export PATH=$(pwd):$PATH

Now we can spawn our root shell:

sudo --perserve-env=PATH /usr/bin/check_syslog.sh

What happens now is that the check_syslog.sh file is being executed, but instead of what it was supposed to do, we get a vim window now. Type

:!bash

to get to root.

Now cd to the root folder and find your flag. Good job

Thank you for reading my walktrough. If you liked this tutorial, please consider giving it some claps. It would be greatly appreciated.