Command Injection Vulnerability

Category: Web Security Readings - Last Updated: Thu, 04 Jul 2019 - by Netsparker Security Team

Why Do Web Applications Need to Execute System Commands?

Sometimes web applications execute OS commands (operating system commands) to communicate with the underlying host operating system and the file system. This happens when hosting web applications on any flavor of operating system, including Windows, Unix and Linux.

Command Injection Vulnerability

This can either be to run system commands or to start applications written in another programming language such as shell, or execute a python, perl or a PHP script. In order to do this there are functions available that can execute a command that is passed to the other scripts as a shell command. While that is very useful functionality it is equally dangerous when not used correctly, and can lead to web application security problems, as explained in this article.

Why You Should be Careful When Using System Commands in Web Applications

By exploiting a command injection vulnerability on a vulnerable application an attacker can add additional commands or inject his own operating system commands. This means that during a command injection attack he can easily take complete control of the host operating system of the web server. Therefore developers should be very careful how to pass user input into one of those functions when developing web applications.

Example of a Command Injection Vulnerability

In this example of the command injection vulnerability we are using the ping functionality which is notoriously insecure on many routers. Imagine a vulnerable application that has a common function that passes an IP address from a user input to the system's ping command. Therefore if the user input is 127.0.0.1, the following command is executed on the host operating system:

ping -c 5 127.0.0.1

Since we are dealing with a vulnerable web application it is possible to break out of the ping command or provoke an error that returns useful information to the attacker. The attacker can then use this functionality to execute his own arbitrary commands. An example of adding additional system commands could look like this:

ping -c 5 127.0.0.1; id

In the above example, first the ping command is executed and directly after that the id command execution takes place. Therefore the command output on the page will look like this:

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.023 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.074 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.074 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.072 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.037 ms
--- 127.0.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.023/0.056/0.074/0.021 ms
uid=0(root) gid=0(root) groups=0(root)

During an OS command injection attack the attacker can also set up an error based attack. For example a code injection in this case will typically look like the below:

ping -c 5 "$(id)"

The above code injection returns a response like this:

ping: unknown host uid=0(root) gid=0(root) groups=0(root)

How to Prevent System Command Injection Vulnerabilities

In order to prevent an attacker from exploiting a vulnerable web application and insert special characters into the operating system command you should try to generally avoid system calls where possible. Under all circumstances avoid user input of any kind unless it is absolutely necessary. And if it is necessary make sure there is proper input validation in place (input validation is always a must to ensure your web application code is not vulnerably to other high impact vulnerabilities such as XSS and SQL Injection).

Also deactivate that function in your language's configuration file if you don't need it, so attackers can never manage to gain access to the system shell on the host operating system through the vulnerability web applications. In some languages you can separate the execution of the process from the input parameters. You can also build a white-list of possible inputs and check its format. For example integer for a numeric id.

Vulnerability Classification and Severity Table

Classification ID / Severity
PCI v3.1 6.5.1
PCI v3.2 6.5.1
CAPEC 88
CWE 78
WASC 31
OWASP 2013 A1
HIPAA 164.306(a), 164.308(a)
CVSS:3.0
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Netsparker Critical
Netsparker

Keep up to date with web security news from Netsparker