TopHatSec: Freshly – Vulnhub Writeup


For this next writeup I wanted to try out a vulnerable VM that dealt at least in part with SQL-injection as a means to exploit.  I’m not entirely sure how this will turn out because I tried to be relatively cautious in avoiding any possible spoilers while searching for VMs exploitable in this way.  I’ll just cross my fingers and start…

Start off with a quick host discovery nmap scan to find the target’s IP:

nmap -sP

Target IP is  Now we’ll do a OS and service scan of the IP.

nmap -O -sV

Great, 3 open service ports to work with.  Let’s try navigating to the main http/https sites first.

First was the HTTP site.  Nothing here but an html page loading a tumblr gif:
<img src=”tumblr_mdeo27ZZjB1r6pf3eo1_500.gif“>

Next up I tried the HTTPS version.

This contained both a link and some interesting JavaScript on the page.
Navigating to brought me to the same page that displayed by using HTTPS (443) so let’s follow the link and check out the WordPress site.

It has a full WP storefront site with cart and payment process.

And a comment section at the bottom.  One of the first things I notice is there are no actual items to add to your card.  This makes me sad.  I like candy.  Let’s try out the comments field.

It works, but with moderation enabled none of our posts will automatically show up on the site.  I try the same thing on both the https (443) and http (8080) sites.  You can see comments of yours submitted in the past, presumably based on your current assigned cookie/session ID (443/8080 both assign their own).

Since the full website in HTTP (8080) seems the most vulnerable at a glance, let’s do a nikto scan on it to see if we can find anything interesting….Well, not really.  It found the /img/ directory and the /wordpress/ directory which we already knew about.  Same with 443.  But then I look at 80 and find this:

Let’s check out the login.php page.

I try a few combinations of user/pw in the field, and each time I get a return error code of ‘0’.  Using this cheat sheet I’ll try some SQL injection tests to see if the site is vulnerable since we already know we have a way of getting some sort of error feedback on-screen.

The first few attempts don’t work but this one does:

User: ‘ or 1=1#
Password: test

Also note the error code is now ‘1’ presumably for a “successful authentication”.  Now that we know we can exploit the login box I’ll fire up sqlmap to run a full scan of the page.

I used the following command with parameters 2/2 (Medium Difficulty, Intermediate level enumeration) and it successfully picked up the 3 fields on the page (user, password, submit button) automatically:

sqlmap –url –wizard

Some positive information right away.  We got OS version, MySQL version, and know the service is being run by root with DBA priv.

A complete list of system users.

A full list of available databases.

A dump of wordpress8080, phpmyadmin, and login.  At this point I kept the first sqlmap running and again utilized the wizard’s automatically generated payload (a time-delay based blind injection method):
IwVT’ AND (SELECT * FROM (SELECT(SLEEP(5)))plpH)– hdgV&password=&s=Submit
And used it to create a new query to spit out all user entries for “wordpress8080”: “users”:

sqlmap –url –wizard –smart –batch –dump -T users -D wordpress8080

Navigating back to I poke around looking to see if there’s a direct link to the WordPress admin page.  There isn’t, but my first guess of /wordpress/admin redirects successfully straight to it (wp-login.php).  Dirbuster would have found that in 2 seconds if I hadn’t.  Let’s go ahead and try the creds we got from sqlmap.

At this point I knew I could probably upload a php page and get reserve shell that way, but I wanted to test out if I could maybe inject script commands via the comments field instead.  I tested out a quick JavaScript alert box and approved it.

Loaded the main WordPress page.

It was at this time that I tested out a handful of JS scripts I found from googling, and even with formatting code to not cause additional <p> tags I couldn’t seem to get any to work and establish a connection back to netcat on my host machine.

I didn’t want to just upload a php page again like I have for other writeups, though.  Let’s look around the WordPress theme editor for some possible options on where to insert our shell code…and I think I’ve found something.>

404 is something that when most users hit, they’ll just back out of right away and not think anything of it.  I toyed around a little with using a bio page or something else, but as those pages weren’t already populated with something it would have looked out of place for me to create them.  So I appended my PHP webshell code to the end of what already existed for the 404 error, and loaded a bogus page and…

Next I use the (almost have it memorized) following command to get a full terminal session:
python -c ‘import pty;pty.spawn(“/bin/bash”)’

Seeing a handful of a available interactive IDs I try out “user” first with the password I found via sqlmap.

That works, but no root access.

Candycane doesn’t work at all.

But root does!  And that’s it!