The goal of a command injection is to execute command line commands on the target host’s operating system. When an application passes user supplied data to a system shell or references files via the command line interface insecurely, it can allow clients to give commands they weren’t intended to be leveraged with.

Unlike code injection (e.g. XSS) – where an attacker adds code to then be executed by the application – in command injection, the default functionality of the app is extended to execute system commands without needing to inject code.

How and How Dangerous

Command injections are a vulnerability of an application that passes unsafe user-supplied data (e.g., forms, cookies, HTTP headers, etc.) to a system shell. From there the attacker can typically execute OS commands with the privileges of the target application. To understand the seriousness of the leverage that access to a host’s shell gives to an attacker, check out our Intro to Bash Shell Commands post!

What’s so concerning about this type of vulnerability is the capability of its exploitation into different connected systems or processes. The surface of vulnerability can quickly escalate from a web application to full system control to access to whatever else might be connected (e.g. servers, user info and settings, admin applications, sensitive data, local networks). This vulnerability can be far-reaching.

Variations

Command Injections are often categorized into two types: result based command injection and blind command injection. The latter can also be broken down into two technique types: time-based technique and file-based technique.

Result based command injection –

Here the output to executed commands are visible to the attacker in the application’s response.

Blind command injection –

Here the output to executed commands aren’t visible to the attacker directly in the application response. But this doesn’t mean the vulnerability can’t be exploited. In order to gather output information or confirm if the injection was a success, special techniques have to be used. 

The time-based technique (blind) –

By causing time delays to the application’s response given a certain output or its length, information can be gathered indirectly.

The file-based technique (semi-blind) –

When accessible directories are write able within an application, responses can be written as a file and retrieved. If a web server’s root directory isn’t writable or accessible, temporary directories can also be used to output information.

Mitigation

Here are some tips to avoid command injection vulnerabilities:

  • Sanitize the user input. Removing, replacing, escaping, or encoding special characters reduces possible commands to plain text at possible injection points.

   • Avoid system calls. By simply not using the technology in the first place, the attack vectors aren’t possible.

   • Whitelist possible command inputs and checking their formats. When using system calls seems unavoidable, confirming only alphanumeric characters are used in certain instances clears a lot surface.

For pentesters looking to understand this vulnerability hands-on,the tools used for exploiting command injection include Commix and BurpSuite. To really delve into this, you can automate pentesting methods for command injection alongside Burp Suite with python. Check out our Python + Shell Injection post for a step-by-step guide!

PortSwigger, the developer of Burp Suite, also has a series of vulnerability labs you can attempt to exploit in a safe learning environment. This is an excellent place to start.

Conclusion

In order to reduce the possibility of vulnerabilities, it’s important to know their sources, types, and the dangers of their exploitation.Now you have an understanding of command injections and how to

‍