I want a "Red Teaming"
Michael Schneider
The command injection vulnerability, which is described in the OWASP Testing Guide under OTG-INPVAL-013, is a rare but welcome “guest” – at least from the attacker’s point of view. It enables them to sneak in commands in the relevant programming language via an input variable.
One useful example of this is a network tool such as a ping, which allows ICMP echo packets to be sent to any IP address. If the attacker replaces the IP address with an input such as 127.0.0.1; whoami
, and no validation takes place, then a command injection is possible.
This can allow the attacker to introduce their commands directly via the available function.
Another scenario involves the attacker exploiting the opportunity to introduce their own code into the target system in order to execute commands on an operating system-level. This can be done using a PHP script, for example.
The PHP scripting language includes various functions for executing commands on operating systems. Commonly used functions are system()
and exec()
, which can also be found in other programming languages, such as C. The functions accept a command, execute it and then return the result.
On well-secured web servers, functions capable of this degree of damage are disabled. This requires including the disable_functions
setting in the php.ini configuration file. One downside to the blacklist approach is that only those functions that the administrator is actually familiar with are disabled.
So if attackers can execute their own PHP scripts on a server, they will attempt to find out which functions can be used to execute commands on operating systems. The easiest way to do this is via the phpinfo()
function. To prevent exposure of the configuration settings, the function needs to be included in the list of disabled functions. Thus, the attacker must then find other ways to identify active functions.
We wrote a PHP script shell_test.php (GitHub) that tests all functions that might be used to execute commands and then indicates whether the respective function can be used on the web server. The script is written for Linux systems but should, for the most part, work on Windows systems as well.
However, the script itself does not offer any interactivity; the executable command must be defined with a variable, which is why we have expanded the script and added a simple input form: shell.php (GitHub). The form enables the execution of commands with the function that are also supported by the web server. If multiple functions are available, the desired function can be selected from a drop-down list. The first time the function is executed, or if no commands are specified, the script executes several basic queries such as reading the Linux kernel version, username, Netcat availability, current directory, list of active processes, and active network connections.
When testing the script, we found that on Windows systems, the system()
function might not return any value and, consequently, no important information is displayed. The reason for this is that there are commands/programs that return detailed information in the standard error stream (stderr). This is the case for some PowerShell cmdlets. By adding 2>&1
to the end of the command, the stderr stream is passed to the standard output stream (stdout) such that detailed information can be displayed as well. The call for system()
will then look like this: system("command 2>&1", $return)
.
The scripts are linked here in the Labs and are also available in our GitHub repository. We welcome feedback about where the scripts are used as well as any change suggestions and feature requests.
Our experts will get in contact with you!
Michael Schneider
Michael Schneider
Michael Schneider
Michael Schneider
Our experts will get in contact with you!