Settings
Log out
Command injection is an attack in which the goal is the 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 Command Injection, the attacker extends the default functionality of the application, which executes system commands, without the necessity of injecting code.
The code below is from a web-based CGI utility that allows users to change their passwords. The password update process under NIS includes running make in the /var/yp directory. Note that since the program updates password records, it has been installed setuid root.
The program invokes make as follows:
system("cd /var/yp && make &> /dev/null");
Unlike the previous examples, the command in this example is hardcoded, so an attacker cannot control the argument passed to system(). However, since the program does not specify an absolute path for make, and does not scrub any environment variables prior to invoking the command, the attacker can modify their $PATH variable to point to a malicious binary named make and execute the CGI script from a shell prompt. And since the program has been installed setuid root, the attacker’s version of make now runs with root privileges.
The environment plays a powerful role in the execution of system commands within programs. Functions like system() and exec() use the environment of the program that calls them, and therefore attackers have a potential opportunity to influence the behavior of these calls.
There are many sites that will tell you that Java’s Runtime.exec is exactly the same as C’s system function. This is not true. Both allow you to invoke a new program/process. However, C’s system function passes its arguments to the shell (/bin/sh) to be parsed, whereas Runtime.exec tries to split the string into an array of words, then executes the first word in the array with the rest of the words as parameters. Runtime.exec does NOT try to invoke the shell at any point. The key difference is that much of the functionality provided by the shell that could be used for mischief (chaining commands using “&”, “&&”, “|”, “||”, etc, redirecting input and output) would simply end up as a parameter being passed to the first command, and likely causing a syntax error, or being thrown out as an invalid parameter.
The following PHP code snippet is vulnerable to a command injection attack:
<?php print("Please specify the name of the file to delete"); print("<p>"); $file=$_GET['filename']; system("rm $file"); ?>
The following request and response is an example of a successful attack:
Request
http://127.0.0.1/delete.php?filename=bob.txt;id
Response
Please specify the name of the file to delete uid=33(www-data) gid=33(www-data) groups=33(www-data)
Sanitizing Input
Replace or Ban arguments with “;” Other shell escapes available Example: – && – | – ...