The Planets:Mercury Walkthrough

This is a quick walkthrough of the beginner-ish CTF machine “The Planets:Mercury” on Vulnhub.

  ****Spoiler Alert****          ****Spoiler Alert****    

Nmap Scan:

It looks like we have a Python WSGIserver under port 8080, but browsing the root directory was a dud, so let’s see if we can enumerate any more info from a Nikto scan:

Here we can see Nikto picked up directory browsing under the /SilverStream directory, so let’s take a look at that:

I’ve already checked the robots file (from the Nikto scan) and found it to be pretty vanilla, but we can see a separate mercuryfacts/ folder here we can take a further look into:

Now we’re getting somewhere. Bread crumbs that lead to this page. This all looks pretty unfinished. One link goes to a page that lists different facts about Mercury. We can increment the parameter used here, going from a “1” to a “2” lists a different fact (we’ll store this away to look for SQL Injection, or Local File Inclusion in a bit). The other links, leads to an informational page:

So, just a note really, but an informational one to us. We can pull 3 pieces of useful info from this note:

1. We know the webpage is using MySQL as the backend database.
2. We know the webpage is using a direct call to MySQL.
3. We don’t know the name of the database, but we do know that the name of the table where the users and passwords likely are is called users.

Let’s take what we’ve learned and go back to the facts page to see if we can trigger any kind of SQL Injection to get more info out of this MySQL database.

Testing the site with a single apostrophe we receive the following SQL error:

There is a lot of additional information. It turns out DEBUG was turned on in the Django settings file, which allows us to get a bit more info about the database as well:

So the database is mercury and the current user is dbmaster. So let’s see if we can use injection to extract some useful data here.

So this is a bit of an incomplete injection (as SQLi is something I need to work on) but you can see that these are definitely user passwords. Now what user accounts do they go to?
For this I looked one more time at the Django debug page from the SQL error before. Looking there you can see the Linux home directory where the Mercury project is at:

I took a shot here and thought it would make sense to try the webmaster account with one of the database passwords I just uncovered:

Alright! We’re in, and we get a user flag for our troubles:

So since we’re in the webmaster home directory I decided to take a look at the web folder under here. It turns out there was a notes.txt file, with passwords, score!

The passwords were Base64 encoded, a perfect example of where security by obscurity isn’t really security at all. From here I just bumped up my privileges by switching to the linuxmaster user account.

Let’s check our sudo privileges on this account:

Looks like we can run a single script as root. So how do we get this to work? This is the first time I ran accross this particular situation so I’m glad it came up. There are some commands that let you drop to a shell, vim being one of them. To escalate privileges when you only have access to run a single script, you can link one of these commands (like vim) to the command being run in the script, and then link that to your PATH environment variable. You then run the regular script with (with sudo of course), but also specify your environment variable by using the –preserve-env=PATH switch:

This opens up the command in vim and then you can just drop to a shell by using :!/bin/sh

Look Mom, I’m root!

This was a fun CTF box, probably very easy for most, but I’ve been away for a while and just getting my feet wet again. Automated tools like SQLMap would have made quick work of the SQLi items, but it’s good to do as much manual work as you can to keep concepts/skills fresh.