TopHatSec: Freshly – Vulnhub Writeup

Source: https://www.vulnhub.com/entry/tophatsec-freshly,118/

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 192.168.111.0/24 -sP

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

nmap 192.168.111.100 -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 http://192.168.111.100:8080 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 http://192.168.111.100/login.php –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 http://192.168.111.100/login.php –wizard –smart –batch –dump -T users -D wordpress8080
Navigating back to http://192.168.111.100:8080 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!

Leave a Reply

Your email address will not be published. Required fields are marked *