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 10.0.0.103 && 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 10.0.0.103 && 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 10.0.0.103 && 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 10.0.0.103 && net users”.
Hmmm! Interesting!!
Let’s add a user named “webHack” with password “Password”. To do this we will use “-n 1 -l 4000 10.0.0.103 && net user webHack Password /add”.
The image below shows this user was successfully added.
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 10.0.0.103 && 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 10.0.0.103 && 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.
Remediation:
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.
Reference:
https://www.owasp.org/index.php/Testing_for_Command_Injection_(OTG-INPVAL-013)
https://www.blackhat.com/docs/eu-15/materials/eu-15-Stasinopoulos-Commix-Detecting-And-Exploiting-Command-Injection-Flaws-wp.pdf
http://www.computersecuritystudent.com/SECURITY_TOOLS/DVWA/DVWAv107/lesson2/
https://www.owasp.org/index.php/Injection_Prevention_Cheat_Sheet
Apache mod_dumpio
No comments:
Post a Comment