DVWA Command Injection
In my previous article of the DVWA series, I have demonstrated how to exploit DOM-based XSS vulnerabilities at low, medium and high security in DVWA Web Application and we have also reviewed the PHP source code which was running on the server. In this article, I will show you how to exploit Command Injection vulnerability in the same web application at low, medium and high security, simultaneously by reviewing their php source code. Again, I am writing this article from a very beginner’s point of view, keeping in mind you don’t know anything about Command Injection vulnerability.
Before we go to exploit the DVWA challenge let me clear your concept on Command Injection vulnerability and understand answers of some questions like:
What is Command Injection?
Why Command Injection vulnerability arises?
How to identify Command Injection vulnerability?
How to protect application from this vulnerability?
What is command injection?
Command Injection is the most dangerous web application vulnerability (rated mostly 9-10.0/10.0 in CVS Score) that allows an attacker to run any arbitrary OS command on host Operating System using vulnerable web application. This vulnerability is also referred with various other names like OS injection, OS command injection, shell injection, shell command injection, etc.
Once an attacker injects any arbitrary OS Command on server OS through the vulnerable application, he can completely compromise the server. This vulnerability always compromises the confidentiality, integrity and availability of the information present on the remote vulnerable machine.
Don’t get confuse with Code Injection because Code Injection and Command Injection both are different vulnerabilities.
Code Injection Vs Command Injection
| Code Injection | Command Injection |
|---|---|
| Code Injection is the general term for attack types which consists of injecting code that is then interpreted/executed by the application. | Command Injection is an attack vector pertaining specifically to the injection of OS commands in remote machine through vulnerable web application. |
| Here the injected payload is any programming language code. For example: any valid php code, python code, ruby code, etc. | Here the injected payload is any programming language code. For example any valid PHP code, python code, ruby code, etc. |
| In Code Injection, the privilege of the reverse shell is mostly root/admin after the execution of code on the remote machine because most of the time programming languages are executed with high privileges. | It breaches the Confidentiality, Integrity, and Availability (CIA triad) of information only when the injected code is executed with high privileges. |
| Here the injected payload is an OS command. For example: id, whoami, ipconfig or any valid OS command. | In this attack vector, the attacker-supplied operating system commands are usually executed with the privileges of the vulnerable application. For example, if the command injection is in the vulnerable web application, then mostly the privilege of the reverse shell is www-data. |
Why Command Injection Vulnerability arises?
Before understanding how command injection vulnerability arises let us understand the basics how any command is executed in any operating system shell. From the below screenshot, it is clear that whenever we want to execute more than one command simultaneously we use some concatenating characters like &&, ||, ;, etc. So, when there is more than one OS command, they are executed in a sequence (from left to right). Also, when a command in the sequence fails, it won’t stop executing the other commands. This concatenating feature of command is primarily responsible for OS command injection if not implemented properly by web applications.
For example, suppose there is a web application that has a ping functionality and it allows the user to check whether the entered IP or domain is pingable or not. So, whenever the user enters his/her IP address in the input field then in the background the command executed is $ ping 172.217.161.14 on the command shell.
Now what if an attacker enters 172.217.161.14 && whoami in the input field. It will also execute $ whoami command in the shell if no any input validation or check is implemented on the user input field in the user form (See below PoC).
Main cause of Command Injection
Command injection vulnerability mainly arises when the application does not perform proper input validation on input given by the user in the input field and passes that data to the system shell unmodified.
How to identify Command Injection Vulnerability?
Below are the steps which we generally use while checking for command injection vulnerability.
- Identify the behaviour/functionality of the application on giving input in the input field.
- If the application is executing any OS command in the backend to process your input, then you should definitely try to inject the command injection payload there.
Some of the applications where you can test for command injection are in any lookup application, shopping websites, website providing online tools, etc.
Note: Since each Operating System has different OS commands so try to inject those OS command in your payload on which the application is running.
Some of the OS commands that you can use for testing this vulnerability are:
Useful Commands: Linux
whoami, ifconfig, ls, uname -a
Useful Commands: Windows
whoami, ipconfig, dir, ver
Payload building Techniques
You can frame your own command injection payload using the following command execution rules using characters | ; & $ > < ' !.
cmd1|cmd2: Uses of|will make command 2 to be executed whether command 1 execution is successful or not.cmd1;cmd2: Uses of;will make command 2 to be executed whether command 1 execution is successful or not.cmd1||cmd2: Command 2 will only be executed if command 1 execution fails.cmd1&&cmd2: Command 2 will only be executed if command 1 execution succeeds.$(cmd): For example, echo $(whoami) or $(touch test.sh; echo ‘ls’ > test.sh)cmd: It’s used to execute specific command. For example, whoami-
>(cmd):>(ls) <(cmd):<(ls)
How to Avoid Command Injection vulnerability?
As we know, the main reason for command injection vulnerability is improper input validation. So the most significant way to protect it is by implementing proper input validation on the input given by the user from the client as well as server ends. Some of the other techniques are:
- Avoid calling out directly to operating system commands. If that is not possible then
prefer built-in APIs that cannot be manipulatedto execute commands other than the one intended. - If possible, a
whitelist should be used to restrict userinput to a specific set of expected values rather than implementing blacklist.
Now we have learnt the basics. Let us exploit the Command Injection vulnerability in the DVWA application at low, medium and high levels.
First of all, login into your DVWA application by default credential admin : password or something else which you have set.
Low Level
We will start from low level and will proceed to high level gradually. Click on DVWA security button on the left pane to change the difficulty to low and select Command Injection challenge.
We are on the challenge page. First of all, we have to check the functionality of the application how it is behaving. On entering the loop back address or any valid IP address we found that the application is pinging it.
From our previous concept, we also know that pinging can only be done by the $ ping command [in Windows as well as Linux] which means, this application is executing OS command in the background to perform the desired functionality. What if we concatenate our command injection payload with the loopback address? If this application is vulnerable to command injection, we will find our injected OS command gets executed. I have injected 127.0.0.1 && ipconfig payload in the input field and found that our injected command $ ipconfig also got executed (check arrow 4 for PoC).
We can also inject other OS commands for our surety. This time I have used the payload 127.0.0.1 && ver and the result of $ ver command can be observed indicated by arrow 4.
Source Code Analysis
Let us check the source code of this level. $_Request[‘ip’],php global variable (denoted by arrow 1), accepts user input inside ip parameter. Arrows 2 & 3 indicate whatever input given inside ip parameter by the user is directly passed inside the shell_exec() function. shell_exec() function is responsible for executing OS command. Since there is no any input validation or sanitization implemented on ip parameter therefore our injected payload got executed.
Medium Level
Now change the dvwa security to medium as shown below.
We got the same page as we had in the low-level challenge. Again, we will follow the same general steps for finding command injection vulnerability. Again, enter the loopback IP address and click on Submit button to check the functionality of the application.
This time too the application is executing OS command in the background. Let us concatenate our basic command injection payload 127.0.0.1 && ipconfig with the loopback address and submit it.
We got the error Bad parameter ipconfig. It appears that the application is performing some type of input validation on the ip parameter.
Source Code Analysis
Let us analyze the source code to find what is happening in the background. Block no 1, 4 & 5 indicate the same code as we had in Low-level security. Block 2 contains an array that contains characters && and ; inside substitutions variable and passes it inside the str_replace() function in block 3 to replace these characters [ && and ; ] with ‘ ’ (space). This was the reason, when we were concatenating our payload && ipconfig, it became ipconfig ( after && is replaced with space) and we got the error.
Bypass
We can bypass this by using some other concatenating characters like &, |, ||, etc. Let us use the payload 127.0.0.1 & ipconfig instead of the previous one. We found that our injected payload got executed [indicated by arrow 4].
We can also inject other OS commands for our surety. This time I have used the payload 127.0.0.1 & ver and the result of $ ver command is shown by arrow 4.
High Level
Change the DVWA security level to High as shown below.
Again, we got on the same page as we had at low and medium levels. Again, we will follow the same general steps for finding command injection vulnerability. So, click on Submit button by entering the loopback address to check the functionality of the application.
This time too, the application is executing OS command in the background. Let us concatenate our basic command injection payload with the loopback address and submit it.
We got the error Bad parameter ipconfig. I have also tried the payload 127.0.0.1 && ipconfig, and again it gave the same error. It appears that the application is again performing some type of input validation on the ip parameter.
Source Code Analysis
Let us analyze the source code to find what is exactly happening in the background. All the blocks are the same as we have at the medium level. Block no 2 contains some extra characters like &, -, $, (, etc. inside substitutions variable and passes it inside the str_replace() function in block 3 to replace these characters with ‘ ’ (space). This was the reason, when we were concatenating our payload && ipconfig or & ipconfig with 127.0.0.1, we got the error.
Bypass
One thing that is catchy in block 2 in the above source code that there is a space after pipe [| ] character which means, when the input in ip parameter is | ipconfig (note the space) it will replace it with ‘ ’ [space]. We can bypass it by using the payload |ipconfig (without space) and it will not block it. So, our final payload will become something like 127.0.0.1|ipconfig.
Let us use this payload instead of the previous one. We found that our injected payload got executed [indicated by arrow 3].
We can also inject other OS commands for our surety. I have used the payload 127.0.0.1 |ver and the result of $ ver command is shown by arrow 3.
So, we have successfully exploited the Command Injection vulnerability in the DVWA web application at low, medium and high security.
Thanks for reading this article on Command Injection. Hope you would have learnt something new from it or have refined your concept of Command Injection. For any query and suggestion feel free to write us at [email protected].
References
https://owasp.org/www-community/attacks/Command_Injection
