Saturday, February 4, 2017

Beginning Web Application Testing: OS Command Injection - DVWA

In OS Command objection, we are attempting to leverage the web application's interface to execute OS commands on a web server. With this ability to execute commands, an attacker can perform numerous tasks via the web application similar to if if he or she were at the server console.

In the case of the Dam Vulnerable Web App (DVWA), it allows a page for us to do "ping" as shown below.

Since we know we can ping, let's see if we can add any other commands to this.

Previously we had "-n 1 -l 4000". Let's now make this "-n 1 -l 4000 && tasklist" to see if we can list the running tasks on the device.

Looks like we were successful!

Similar to how we can list the tasks, we can kill a task. This may potentially result in a denial of service (DoS). In this case let's kill the "VBoxService.exe". To do this we will execute "-n 1 -l 4000 && taskkill /IM VBoxService.exe /F". This returns the image below which shows that “VBoxServie.exe” has been terminated successfully.

Using the similar concepts we can perform a host of tasks on the OS.

Before we go …
… let's do a directory listing, using the following command "-n 1 -l 4000 && dir ..\\..\\..\\" to get an idea of what may be available.

Looks like we hit the webserver folder.

How about a list of the users currently configured on the system? Let’s verify this by using “-n 1 -l 4000 && net users”.

Hmmm! Interesting!!

Let’s add a user named “webHack” with password “Password”. To do this we will use “-n 1 -l 4000 && net user webHack Password /add”.

The image below shows this user was successfully added.
command injection add user

Obviously once the user is added we should then move that user into the “Administrator” group. Let’s do that now using the following command “-n 1 -l 4000 && net localgroup Administrators /add webHack”. The output from this should have been “The command completed successfully.” Let’s now verify that it did by looking at the members of the “Administrators” group using the following “-n 1 -l 4000 && net localgroup administrators”.

I think at this point we have clearly demonstrated the dangers of Command Injection attacks.

It is important to note in this example, rather than HTTP “GET” we were using HTTP “POST”. By default, your web server may not be logging the data sent in the “POST” method. As a result you may need to enable this feature based on your server version. For Apache the module “mod_dumpio” can be used for this purpose.

In order to demonstrate how we can detect this attack I needed to add the following lines to my “httpd.conf”:
LogLevel debug
DumpIOInput On
DumpIOOutput On
LogLevel dumpio:trace7

The configuration change above will cause the “POST” data input and output to be sent to Apache’s “error.log” rather than its’ “access.log

See you in the next post for our detection of this type of activity.

Prevention of OS Command Injection can be achieved by leveraging the following OWASP guidance.
1. Perform proper input validation
2. Use of Safe APIs which avoids usage of an interpreter entirely.
3. Escape special characters, using specific escape syntax for the interpreter.

Apache mod_dumpio

No comments:

Post a Comment