Today we will be taking a look at the command injection vulnerability of the Damn Vulnerable Web Application (DVWA 1.9).
The DVWA has several options to choose from once you logged in. In the section DVWA Security you can choose 4 values: low, medium, high and impossible. From now on we will try and exploit the low, medium and high settings for each vulnerability.
As we already performed a CSRF / Brute force attack to get into the system I am leaving those as an exercise for you :)
The things we are doing in this series can be quite damaging to real websites. What we do here is purely for education, in a lab environment. If you try this on the website/server of another party without permission you are probably breaking the law! Be responsible.
Lets get started!
command injection basically means that you trick the application to execute a command of your choice on the host system. This is generally done through another command that the author intended to be executed, like in this case
If you think about what is happening here; you enter an IP address and the host system will go and ping it. So it probably does something like
shell_exec( 'ping ' . $target ) when we are looking at an PHP application.
The easiest level in DVWA, so it will probably mean we can just terminate the command and add one of our choosing, lets give it a try adding
BAM! that was easy! the
ls command was executed right after the ping command itself.
Lets up the ante and try the same thing with the medium level. Sadly nothing happens. What can be happening here? A safe bet would be that there is some form of filtering going on. Lets run through the options that we have in a normal shell:
&& both fail!
If you have ever done some scripting you might also know that the
&& means perform the thing on the left, if it succeeds, do the thing on the right. There is a counterpart for a failure case (logical OR), which is
||, either left or right succeeds. Lets try that! If we pass no argument to
ping the command should fail, meaning we can utilize the OR operator.
Alright then, that seems to work just nicely!
All the previous options now fail us. Also using shell escapes like
$() and the backtick itself do not work.
We can see that it is still accepting hostnames, like
localhost, so any filtering that is done is quite selective, perhaps they made a mistake in the patterns? The next step is to try to play with the spaces around operators, it is all very tedius and often results in nothing.
I must admit that at this time I took a look at the sourcecode for this exercise.
Ah, look at that. It indeed filtered out all the normal operands and did it quite nicely, but do you see where the pipe sign is?
|<space> means that it will not filter out a single
| directly followed by a different command! Lets give that a try! Indeed
|ls yields a directory listing as before!
That was a lot of effort for something that seems to not be as usefull, but you might be surprised what all you can do with a command injection. One of the most usefull things is that you can actually get a shell on the remote machine. Lets take a look at some tooling.
The Commix Project aims to create a tool specifically for testing for Command Injections. Lets give that a try to make this vulnerability a little more usefull.
As we did with the login page, we will grab the cookie from our proxy. Lets give the tool a try.
commix --url="http://172.17.0.1:32770/vulnerabilities/exec/#" --data="ip=127.0.0.1&Submit=Submit" --cookie="PHPSESSID=guikjtc8rbhaousgcg2imuatj4; security=medium" --ignore-redirect --flush-session
The sessions looks like the follow screenshot:
It correctly identifies the
ip as being vulnerable and allows us to run a remote pseudo shell. This allows us to look around a server as if it was our own.
Experimenting with the security settings and commix shows us it can find vulnerabilities on
high it fails to find the case.
If we pass the
--all flag to commix it will retrieve all the usefull information it can. For my sessions that looked like this.
As the www-data user is not privileged it can’t find password hashes, but we do get a pretty good sense of the environment already.
The impossible setting for DVWA has proofed to be just that. They properly filter the user input, meaning that it now will only accept an IP address to ping. I have not found a way around this, yet!