Command Injection Vulnerabilities
In the previous articles, we discussed what Command Injection vulnerabilities are and what causes command injection vulnerabilities. This article provides an overview of how command injection vulnerabilities can be identified and exploited using some automated tools. We will then discuss why we should not always rely on automated tools to identify command injection vulnerabilities.
What is command injection?
As already mentioned in earlier articles, Command injection is a type of web vulnerability that allows attackers to execute arbitrary Operating System commands on the server, where the application is running. Command Injection vulnerabilities occur when the applications make use of shell commands or scripts that execute shell commands in the background.
In the next few sections, let us discuss how command injection vulnerabilities can be discovered by automated web vulnerability scanners and why manual intervention is required in some cases.
Automated scanners for finding command injection vulnerabilities
Let us consider the following code snippet, which is vulnerable to command injection.
This vulnerability can be simply exploited by passing arbitrary commands via the parameter cmd as shown below.
Now, let us scan this URL using OWASP ZAP and observe if the command injection vulnerability can be identified. Let us enter the URL to be scanned and click Attack.
After the scan finishes, we should see the following alerts, where Remote OS Command Injection vulnerability can be seen.
Clicking on the reported vulnerability shows the details such as Risk, parameter and the payload used to confirm the vulnerability.
The following excerpts show the request and response provided by OWASP ZAP, which can be used to understand how the vulnerability was discovered. Following is the request sent by OWASP ZAP.
|GET http://192.168.1.90/cmd/index.php?cmd=tet%26cat+%2Fetc%2Fpasswd%26 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0
As highlighted, a payload with OS command tet&cat+/etc/passwd& has been sent and the following response was received, which confirms that the application is vulnerable to OS command injection.
|HTTP/1.1 200 OK
Date: Mon, 05 Oct 2020 12:02:59 GMT
Server: Apache/2.4.18 (Ubuntu)
Content-Type: text/html; charset=UTF-8
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
systemd-timesync:x:100:102:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:103:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false
Automated command injection exploitation using commix
Aside from standard web vulnerability scanners, there are tools which can specifically identify and exploit command injection vulnerabilities and it comes preinstalled with Kali Linux. Commix is one such tool, which can be used to identify and exploit command injection vulnerabilities in web applications. According to the GitHub documentation, “Commix (short for [comm]and [i]njection e[x]ploiter) is an automated tool written by Anastasios Stasinopoulos (@ancst) that can be used from web developers, penetration testers or even security researchers in order to test web-based applications with the view to find bugs, errors or vulnerabilities related to command injection attacks. By using this tool, it is very easy to find and exploit a command injection vulnerability in a certain vulnerable parameter or HTTP header.”
Let’s see Commix in action.
Run the following command to start with basic command injection.
|# commix –url=”http://192.168.1.90/cmd/index.php?cmd=INJECT_HERE”|
Notice that we have replaced the value of the parameter “cmd” with “INJECT_HERE”. This is how Commix understands the target parameter to be tested. Now, Commix starts performing tests on this parameter and gives us an interactive shell as shown below if the application is exploitable.
As we can notice in the preceding figure, commix confirms with the following message that the application is injectable and it asks for user confirmation before giving us a pseudo-terminal shell.
|[+] The GET parameter ‘cmd’ seems injectable via (results-based) classic command injection technique.
[~] Payload: echo HRNZHE$((40+48))$(echo HRNZHE)HRNZHE
Entering yes should give us an interactive shell, which can be used to run OS commands on the target web server.
Clearly, automated tools such as OWASP ZAP and Commix come handy when we want to discover and exploit command injection vulnerabilities. However, it should be noted that not every single command injection vulnerability can be spotted even by some powerful automated tools because of the manual interaction required by the application flow.
Let us consider the following example.
system(“echo -n”. $input.” | base64″);
As we can see in the preceding excerpt, even though the code is vulnerable to command injection, the output is base64 encoded and then sent back to the user. It could be hard for automated tools to detect this vulnerability since the tool must be designed to verify the encoded text coming back in the HTTP response. Often, blind injection techniques have to be employed by the tools to detect such vulnerabilities. Let us check if OWASP ZAP or Commix can discover this vulnerability.
Following is the URL provided to ZAP. Click Attack to start the scan.
Following is the scan result from ZAP.
As we can notice, the OS command injection vulnerability is not identified by ZAP.
When scanned using commix, it has resulted in errors, when going through the blind injection scan and commix stopped with the following message.
Command Injection vulnerabilities, just like any other vulnerabilities may or may not be identified by automated scanners and clearly manual testing can be helpful in identifying these issues. In the next few articles, we will discuss more command injection related concepts such as Blind command injection, exploiting and mitigating command injection vulnerabilities.