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.
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#
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