Command Injection – a generalized term for both Shell Injection and OS Command Injection. OS Command Injection – When particular OS commands are executed, based on.nix/Win32. When you come across these terms, the applied terms are meant to be a form of injection. Command injection is a serious vulnerability that allows malicious actors to execute commands on the host operating system. This vulnerability is typically discovered using common security tools and scanners, such as Burp Suite. TCell protects your application from command injection attacks by monitoring all commands that your application issues to the operating system,.

Command Injection vulnerabilities are a class of application security issue where an attacker can cause the application to execute an underlying operating system command. For that reason it’s generally a high impact issue. It can be exploited simply by chaining commands along with the expected input by using shell control characters such as:

Developers have a variety of reasons why they might want their web applications to execute underlying operating system commands. One example could be an application that allows a user to check if a host is online by pinging its IP address. The URL for this function could look something like this:

and the output on the screen could be:

However if user input is insecurely passed to this function a user could chain a command on the end, such as ” && id” and this would be executed along with the main command, changing the input in our example to this:

and so the output on the screen would be:

As you might guess from above, the user gains the permissions that the affected application has, so if it’s running as www-data or root you’d get that privilege level! An easy way to compromise a box and potentially allow an attacker to take over the webserver, deface the application or steal confidential data!

However things get more complicated for the attacker is the system does not show the output in the application itself, it might just silently execute the command and output something generic like “Success” or “done”. If this is the case an attacker can still determine the existance of the vulnerability and blindly exploit it through inference.

For example imaging chaining to the end of the input the linux command “sleep”, such as:

With this request the output, if vulnerable, would come through as expected with the “Success” message, however it would take a noticable about of time to return – something around 10 seconds longer than without the payload. To determine if this was just a laggy server or not you could try multiple different delay levels to see if the received delay matches the expected amount. So sleep 10 causes approximately a 10 second delay and sleep 30 causes approximately a 30 second delay, reducing the likelihood that this is a false positive.

At this point you’ve got a successful Blind Command Injection vulnerability! Before I get on to how to utilise that as an attacker however, there’s one more type to deal with. Blind injection with out-of-band detection. This class occurs is a vulnerability is vulnerable but no change in output can be perceived through the application, for example if the application executes the request in a new thread, so delaying the server through the “sleep” command doesn’t work (or at least can’t be perceived through the application itself).

In this case we can get our “noticable change” by calling out to another server and monitoring that server for requests. For example you could try a payload like the following:

This would cause an affected (Linux) server to call out to the attacker’s machine. The wget command online requests the server download a web page. Therefore the attacker could see that the payload worked successfully as their logs would show a GET request to the file: /?attacksuccessful

Now to turn that into a viable attack payload to, for example, steal confidential files the attacker could try chaining the contents of the file in the request to the attackers server! A payload like this would be effective:

Here the attacker is taking the contents of the confidential file /etc/password, encoding it with base64 so that it’s possible to transmit it in a URL and then using the wget command again to send that file in a HTTP GET request to the atttacker controlled server! One thing to remember is that the base64 command will line wrap by default after 76 characters, but you can use -w 0 parameter to disable this, like this:

As you can imagine, this is a pretty bad vulnerability which I’ve seen multiple times during Penetration Testing engagements but I’ve seen little in the way of content online about the issue, so I thought I’d throw a few notes down in a post. The important part though: there are specific ways to secure command execution depending on your underlying language and programming framework however one thing that’ll work for general cases is effective user input filtering! Luckily, I’ve written about that here!
Again, the minimum characters to consider dangerous in regards to this issue are:

Payloads can be incredibly varied as the attacker has an awful lot of flexibility, but a few simple ones are things like:

Introduction:

In the previous articles of this series, we discussed various topics around Command Injection vulnerabilities. We began by understanding what Command Injection vulnerabilities are and how they occur. We then discussed how one can exploit Command Injection vulnerabilities. In this article, we will discuss how to mitigate Command Injection vulnerabilities.

Remote Os Command Injection

Use builtin APIs instead of OS commands

As we noticed in the earlier articles, Command injection occurs due to the fact that code is written to execute OS commands and an attacker can manipulate this behaviour to execute more commands than what the system is intended for. To prevent such vulnerabilities, one of the primary defenses developers should use it to avoid executing OS commands and use APIs provided by the framework or the language. For instance, to get the system date, instead of executing the following:

<?php system(date); ?>

The developers should use the following.

<?php echo date(‘l jS of F Y h:i:s A’); ?>

This will help the developers prevent command injection vulnerabilities due to the fact that the data function doesn’t execute anything other than getting the date.

Input validation

Lack of input validation is the primary culprit of most of the web vulnerabilities and Command Injection is one of them. Command Injection vulnerabilities can be prevented using proper input validation. Developers must use a whitelisting approach to validate the user input. It can often be achieved using regular expressions. In the following example, the variable $target just expects an IP Address and it must be properly validated to ensure that the received data is indeed an IP Address.

<?php // Get input $target = $_REQUEST[ ‘ip’ ]; // Execute user input $cmd = shell_exec( ‘ping -c 4 ‘ . $target ); // Show the response back to the user echo $cmd; ?>

The following IP Address validation code snippet taken from DVWA impossible level, shows that the IP Address should be properly validated before passing it to shell_exec function.

<?php // Get input $target = $_REQUEST[ ‘ip’ ]; $target = stripslashes( $target ); // Split the IP into 4 octects $octet = explode( “.”, $target ); // Check IF each octet is an integer if( ( is_numeric( $octet[0] ) ) && ( is_numeric( $octet[1] ) ) && ( is_numeric( $octet[2] ) ) && ( is_numeric( $octet[3] ) ) && ( sizeof( $octet ) 4 ) ) { // If all 4 octets are int’s put the IP back together. $target = $octet[0] . ‘.’ . $octet[1] . ‘.’ . $octet[2] . ‘.’ . $octet[3]; // Execute user input $cmd = shell_exec( ‘ping -c 4 ‘ . $target ); // Show the response back to the user echo $cmd; } ?>

Os Command Injection Fix

Escaping shell metacharacters

Command Injection Cheat Sheet

As mentioned in the earlier articles, in most cases we will terminate the existing commands using shell metacharacters and then execute commands of our choice when exploiting Command Injection vulnerabilities. In these situations, escaping shell metacharacters can be used to prevent command execution vulnerabilities. Let us consider the following example.

<?php // Get input $target = $_REQUEST[ ‘ip’ ]; // Execute user input $cmd = shell_exec( ‘ping -c 4 ‘ . escapeshellarg($target)); // Show the response back to the user echo $cmd; ?>

The preceding code snippet shows that the user supplied input is first passed to escapeshellarg function and then it is passed to shell_exec function. When an IP Address is passed to it, it works just fine.

However, if we pass any additional commands using shell metacharacters, it won’t be processed by the application as shown below.

Though, all the examples in the article are shown using PHP programming language, they can be applied to other languages such as Java and .NET.

Conclusion:

Command Injection vulnerabilities may not exist commonly in every single application, but they can cause the worst damage when exploited by an attacker. As we have seen, they give completed control on the underlying host and it is extremely important for developers to be aware of Command Injection vulnerabilities. This article has provided some examples of how Command Injection vulnerabilities. As demonstrated, the best way to avoid Command Injection vulnerabilities is to avoid the use of execution of OS commands. When it cannot be avoided, proper input validation must be implemented preferably using a whitelisting approach.

Sources: