OS Command Injection Primer: How They Work and How to Prevent Attacks

What is OS Command Injection?

Command injection refers to a class of critical application vulnerabilities involving dynamically generated content. Attackers execute arbitrary commands on a host operating system using a vulnerable application. They pass the bad data to the system shell through forms, cookies, and HTTP headers. This allows the attackers to gain control over a web site and carry out any action or process that the underlying application accommodates. Attackers who gain access to these systems can modify, manipulate, or read data; inject commands that steal data or attack infrastructure; and engage in other damaging activities. Command injection is highly dependent on privileges. It occurs when insufficient input validation takes place.

Click here for Remediation Guidance on OS Command Injection for Java or here for Remediation Guidance for ASP.NET

How Command Injection Works

Step 1: Attackers identify a critical vulnerability in an application. This allows them to insert malicious code into the OS and gain any functionality the underlying application offers. The attackers can unleash the attack even without direct access to the OS.

Step 2: The attacker alters dynamically generated content on a web page using HTML code through an input mechanism such as a form field or cookies.

Step 3: Once the code is inserted into the affected web page, browsers interpret the code. This allows the attackers to execute specific commands across user's computers — along with both users’ networks and the infected system's network.

Anatomy of an Attack

There are two basic ways attackers deploy OS command injection:

An application executes a fixed program that operates under its control. After the breach, it accepts outside input as arguments. These arguments trigger various actions and behavior.

Example: The attack script accesses the system call ("nslookup [hostname]") to run nslookup with the HOSTNAME appearing as an argument from the user. If the program does not removed separators included with the externally generated HOSTNAME argument, the attacker can place separators inside the argument and executive his or her own commands.

An application relies on input to select the program that will run along with the commands to include in the attack. The application sanitizes the input and then redirects the command to the OS.

Example: The application relies on exec([COMMAND]). The input is supplied from an external source. Once an attacker controls the [COMMAND] argument, he or she can execute arbitrary commands and desired scripts on the system.

The Impact of an Attack

Problems resulting from an OS command injection attack can range from minor to highly disruptive. An attacker might alter or corrupt a database, steal customer records, use an API to launch a specific process or event, or launch a distributed denial of service (DDoS) attack. Once attackers have gained control of a server, they can use the underlying application to exploit any and all capabilities built into the software. The resulting damage is determined by the user authorizations and security protections an organization has in place. What's more, attackers may retain access to systems even after an organization has detected and fixed the underlying vulnerability.

Preventing Damage

After discovering that an OS command injection attack has taken place, it's critical to cut off access to the application that’s been compromised. This may require a temporary solution, such as blocking access to the vulnerable script until a development or security team can resolve the underlying issue. The task can be addressed in one of two ways: making changes using the native functionality of the web server or altering system access permissions to the affected file.

Remediation is Critical

It's vital to address potential vulnerabilities that could lead to an OS command injection attack. There are a few ways to handle the task:

Preventing manipulation at the source. It's vital that any applications accessible through a web browser avoid user-controllable data in operating system commands. Development and cybersecurity teams should focus on the use of code that doesn't allow for manipulation of server-level tasks via unintended commands.

Rejecting unacceptable code. If it's impossible to find a safer and more secure way to perform server-level tasks, then it's critical to strictly validate all user data. This is often achieved by creating a whitelist of acceptable values. In addition, some organizations limit input to short alphanumeric strings. Any input outside the range of acceptable data is automatically rejected by the system.

Controls over APIs. In some cases, an application might pass a command string for an API to a shell interpreter that handles command chaining and redirection. This can lead to a breach. Instead, the application should only launch a specific process based on a specific name and command line parameters. This way, even if attackers circumvent basic input validation methods, their options and choices are limited.

Veracode Can Help with OS Command Injection

Veracode Discovery can safely, accurately, and quickly discover web application flaws, including OS command injection, in running web applications in either production or pre-production environments.

Veracode Static Analysis can accurately identify OS command injection vulnerabilities and other flaws in your application and its third-party components, and tell your developers exactly where and how to repair them, all without ever looking at the source code.

Our cloud-based application security platform helps you manage your application security program, track progress, and educate your developers on avoiding and repairing OS command injection and other security flaws through integrated eLearning materials.

About Veracode Developer Training

Learn More

Common Web Application Vulnerabilities