OS Command Injection is a web vulnerability that could allow an attacker to execute commands from an arbitrary operating system (OS) on the server running an application, often endangering the application and all its information.
PCI DSS Requirement 6.5.1 requires your organization’s applications to be unaffected by OS Command injection flaws, particularly SQL injection. Malicious people commonly use injection defects to compromise applications.
What Is OS Command Injection?
OS command injection, or shell injection, is a web vulnerability that allows an attacker to arbitrarily execute an operating system (OS) commands on the server running the vulnerable application, often ultimately compromising the application and all data.
See Also: What is SQL Injection and How to Prevent It?
When programs are unable to properly validate and sanitize parameters, they use them to execute system commands when calling shell functions such as system() or exec().
Often, an attacker could exploit an os command injection vulnerability to compromise other server infrastructure parts.
Command Injection is a web application vulnerability. Web applications may need operating system commands to communicate with the operating system and file system. This can be to run system commands or to run scripts written in different programming languages.
This process is like running a command on CMD on Windows and Terminal on Linux. It occurs when the security control of the user’s inputs is not sufficient, and the user has the authority to run commands on the system.
What Are the Types of OS Command Injection?
OS Command injection vulnerabilities can be exploited in three ways: direct, indirect, and blind.
Direct Command Injection
In direct command injection, the attacker first discovers that the application calls a system command, passing data directly entered by the user as an argument to the command. It then enters the malicious command as part of the expected arguments. So the application executes the original command followed immediately by the malicious command.
If we examine it step by step:
- The attacker discovers that the application is using client input to execute a command.
- Sends the malicious command as part of the client’s input to the program.
- Finally, the behavior of the application which executes the malicious command is observed.
Consider a shopping app that enables the user to see whether a product in a specific store is in stock. This data is accessed through a URL such as:
https://insecurewebsite.com/stockStatus?productID=321&storeID=35
The application must query different legacy systems to provide stock details. The feature is introduced for historical purposes by calling the product’s shell command, and the IDs are stored as arguments:
stockreport.pl 321 35
This command pulls out the stock status for the specified product returned to the user.
Since the application does not defend against OS command injection, the attacker can send the following input to execute a random command:
& echo test &
If this entry is sent to the parameter productID, the command that the application executes is:
stockreport.pl & echo test & 35
The Echo command will output the typed string. Some forms of os command injection are a helpful way to evaluate. The & character is a separator for the shell command, so there are three different commands that run one after another. As a result, the user returned the output to:
Error - productID was not provided
test
35: command not found
These three lines output show:
- The stockreport.pl command was executed without its expected variables and therefore returned an error message.
- The injected echo command has been executed, and the supplied string has been written to the output.
- The original argument 35 was executed as a command that caused an error.
Placing the additional command sign (&) after the injected command is often useful because it separates the injected command from what comes after the injection point. This reduces the possibility of blocking the execution of the injected command.
Indirect Command Injection
In indirect command injection, an additional command is sent to the vulnerable application indirectly via a file or environment variable. Next, the attacker learns that using data from an external source such as a file or environment variable, the program calls a system command. In order to add a malicious instruction, it then modifies the content of the external resource. It then forces the program along with the original order to execute the malicious command.
If we examine it step by step:
- The attacker discovers that the application is using data stored on an external source to execute commands.
- Organizes the external resource to contain malicious commands.
- Waits for or forces the application to execute the original command.
- Finally, it verifies that the application is executing the injected command.
Blind Command Injection
Blind injection of commands is one form of OS command injection. Blind command injection means that in the HTTP response, the application does not return the output from the command. To take advantage of this weakness, various techniques like “time delay” and “output routing” are needed.
Many examples of OS command injection vulnerabilities are blind vulnerabilities. Blind vulnerabilities mean that the application does not return the output of the command in response. It is still possible to exploit blind vulnerabilities, but various techniques are required.
Consider a website that allows users to submit feedback on the site. The user enters his e-mail address and a feedback message. The server-side application then generates an e-mail with feedback to the site administrator. To do this, it sends a command to the mail program with the details sent. For example:
mail -s “Great Site” -aFrom: [email protected] [email protected]
The mail command output is not returned in the application’s responses, so using the echo command is not adequate. In this case, you can use time delays to detect and abuse the vulnerability.
You may use an inserted command to cause a time delay that allows you to validate the execution of the command based on the time it took to respond to the application. The Ping and Sleep commands are an effective way to do this.
& ping -c 10 127.0.0.1 &
& sleep 10 &
These commands cause the application to wait 10 seconds to send the response. Therefore, you will detect blind os command vulnerability in this way.
How to Prevent OS Command Injection Attacks?
By far, never calling operating system commands from application layer code is the most productive way of avoiding OS command injection vulnerabilities. There are alternative ways to implement the required functionality using more secure platform APIs in almost all cases.
If it is deemed unavoidable to call OS commands with user-supplied input, strong input validation should be required. Some examples of adequate verification include:
- Create a whitelist of allowed values.
- Verify that the entry is a number.
- Verify that the entry contains only alphanumeric characters / no other syntax or spaces.
When developing software, your team should make sure they are not affected by OS Command injection. Be sure to write test scripts for OS Command injection as part of your secure code development process.
To verify compliance with PCI DSS Requirement 6.5.1 and protection from injection errors, an assessor will review your policies and procedures regarding application development and interview responsible personnel.
There are many useful articles on Owasp’s website, such as weaknesses in web applications, how vulnerabilities occur, how to exploit and prevent these vulnerabilities. You can get more detailed information about OS Command Injection from the links below.
