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:
Next up I tried the HTTPS version.
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#
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.
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.
Loaded the main WordPress page.
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…
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.