What is 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. OS injection, Command Injection, and Arbitrary Command Execution are synonyms of Command Execution.
OS command injection (also known as shell injection) that allows an attacker to execute arbitrary operating system (OS) commands on the server that is running an application, and typically fully compromise the application and all its data. An attacker can leverage an OS command injection vulnerability to compromise other parts of the hosting infrastructure, exploiting trust relationships to pivot the attack to other systems within the organization.
Command injection attacks are possible when an application passes unsafe user supplied data (via forms, cookies, HTTP headers etc.) to a system shell.
This attack differs from Code Injection, in that code injection allows the attacker to add their own code that is then executed by the application. In Command Injection, the attacker extends the default functionality of the application, which execute system commands, without the necessity of injecting code.
How to execute arbitrary command? and Examples.
Let us see take one simple example
Consider a ecommerce website that lets the user view whether an item is in stock. This information is accessed via a URL like:
https://awsome-ecommerce-website.com/stockStatus?productID=123
To provide the stock information, the application must query various legacy systems. Let us say, the functionality is implemented by calling out to a shell command with the product ID as argument:
stockStatus.pl 123
This command outputs the stock status for the specified item, which is returned to the user.
Since the application implements no defenses against OS command injection, an attacker can submit the following input to execute an arbitrary command:
& echo IamInside
If this input is submitted in the productID parameter, then the command executed by the application is:
stockStatus.pl & echo IamInside
The echo command simply causes the supplied string to be echoed in the output, and is a useful and common way to test for some types of OS command injection. The & character is a shell command separator, and so what gets executed is actually three separate commands one after another. As a result, the output returned to the user is:
Error - productID was not provided
IamInside
The two lines of output demonstrate that:
- The original stockreport.pl command was executed without its expected arguments, and so returned an error message.
- The injected echo command was executed, and the supplied string was echoed in the output.
For more examples refer this
Useful commands
When you have identified an OS command injection vulnerability, it is generally useful to execute some initial commands to obtain information about the system that you have compromised. Below is a summary of some commands that are useful on Linux and Windows platforms:
Purpose of command Linux Windows
----------------------------------------------------
Name of current user whoami whoami
Operating system uname -a ver
Network configuration ifconfig ipconfig /all
Network connections netstat -an netstat -an
Running processes ps -ef tasklist
Understanding the role of Special Characters in Command Injection
Combining Special characters with the user input, lets you modify or diverge the application to perform unintended actions. As in Command Injection, a request to perform a command 2 which is ordered dynamically by the attacker. The following special character can be used for command injection such as | ; & $ > < ' !
- cmd1|cmd2 : Use of | will make command 2 to be executed independent of the fact whether command 1 is executed or not.
- cmd1;cmd2 : Use of ; will make command 2 to be executed independent of the fact whether command 1 is executed or not.
- cmd1||cmd2 : Command 2 will only be executed if command 1 fails to execute.
- cmd1&&cmd2 : Command 2 will only be executed if command 1 succeeds in execution.
- $(cmd) : For example, echo $(whoami) or $(touch test.sh; echo ‘ls’ > test.sh)
How to bypass the mitigations?
Try using some characters as shown below to bypass the checks or escaping done by the application.
For command injection try characters or combination of characters as below to test the defense implemented by the application:
Escape or filter special characters for Windows,
( ) < > & * ‘ | = ? ; [ ] ^ ~ ! . ” % @ / \ : + , `
Escape or filter special characters for Linux,
{ } ( ) > < & * ‘ | = ? ; [ ] $ – # ~ ! . ” % / \ : + , `
Further exploitation
Have a keen eye for below system commands that are more likely to be vulnerable for Command Injection. Check if you can run these commands directly.
Java -
C/C++ -
Python -
exec
eval
os.system
os.popen
subprocess.popen
subprocess.call
PHP -
system
shell_exec
exec
proc_open
eval
For more command and payload you can refer this
Command Injection Vulnerabilities
Below are common vulnerabilities, which can potentially expose an application to command injection attacks.
Arbitrary Command Injection
Applications can receive arbitrary system commands directly from end users. Once the application receives the commands, it executes them on the host. This is a common vulnerability that allows command injections.
Arbitrary File Uploads
Applications may allow end users to upload files containing arbitrary file extensions. It is possible for an attacker to upload a script to issue operating system commands. This same vulnerability can also be exploited by an authenticated attacker with normal user privileges. Read here
Server-side Template Injection
Web applications sometimes use server-side templating tools, like Jinja2, when generating dynamic HTML responses. A server-side template injection (SSTI) vulnerability occurs when user input is insecurely embedded within a template in a manner that allows threat actors to remotely execute code on the server. Read here
XML External Entity Injection
XML external entity (XXE) vulnerabilities occur in applications that use weakly configured XML parsers to parse user-controlled XML input. XXE vulnerabilities can allow threat actors to read arbitrary files from the server and cause Denial of Service (DoS) attacks. Read here
Blind OS command injection
Many instances of OS command injection are blind vulnerabilities. This means that the application does not return the output from the command within its HTTP response. Blind vulnerabilities can still be exploited, but different techniques are required. Read here
Ways To Prevent Command Injection?
- Don’t Run System Commands with User-Supplied Input
If you do need to use user-input for a system command, do not call operating system commands directly. Instead, you can use built-in library functions, because by far the most effective way to prevent OS command injection vulnerabilities is to never call out to OS commands from application-layer code.
For example, if you are using the Python os library, do not use this command, which directly calls an operating system command:
os.system(“listdir <directory-path>”)
Instead, use this command, which uses a library function:
os.listdir(“<directory-path>”)
This protects the integrity of existing system files that are included, executed, or parsed by your code.
- Use Strong Input Validation for Input Passed into Commands
You can achieve this by using a whitelist for strings or allowed characters. To unable users to execute arbitrary commands, for example, you can whitelist certain commands, like ls and pwd, to allow only these input strings.
Alternatively, you can whitelist only allowed characters. For example, the regular expression ^[a-z0–9]{1,10}$ allows only numbers and lowercase letters and numbers. It does not allow special characters at all, because actors can use them to manipulate the logic of the command. This expression also limits the length of the input string 10 characters.
- Use the Principle of Least Privilege
This method strives to provide applications and processes with only the minimum privileges they need for their tasks. The goal is to lower the risk and damage of successful attacks. This way, if attacker manage to inject commands, they are restricted to the privileges allowed to the application or process.
