Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Command injection vulnerabilities take two forms:
- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.
- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.
In this case we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:
1. Data enters the application from an untrusted source.
2. The data is used as or as part of a string representing a command that is executed by the application.
3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.
Example 1: The following code from a system utility uses the system property APPHOME
to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.
...
home = os.getenv('APPHOME')
cmd = home.join(INITCMD)
os.system(cmd);
...
APPHOME
to point to a different path containing a malicious version of INITCMD
. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME
, then they can fool the application into running malicious code and take control of the system.rman
utility and then run a cleanup.bat
script to delete some temporary files. The script rmanDB.bat
accepts a single command line parameter, which specifies what type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.
...
btype = req.field('backuptype')
cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\utl\\cleanup.bat\""
os.system(cmd);
...
backuptype
parameter read from the user. Typically the Runtime.exec()
function will not execute multiple commands, but in this case the program first runs the cmd.exe
shell in order to run multiple commands with a single call to Runtime.exec()
. Once the shell is invoked, it will happily execute multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*"
, then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well. make
command in the /var/yp
directory, the code for which is shown below.
...
result = os.system("make");
...
os.system()
. If an attacker can modify the $PATH
variable to point to a malicious binary called make
and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make
will now be run with these privileges, possibly giving the attacker complete control of the system.
[1] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A1 Injection
[2] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A2 Injection Flaws
[3] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A6 Injection Flaws
[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I, APP3570 CAT I
[5] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 77, CWE ID 78
[6] Standards Mapping - SANS Top 25 2010 - (SANS 2010) Insecure Interaction - CWE ID 078
[7] Standards Mapping - SANS Top 25 2009 - (SANS 2009) Insecure Interaction - CWE ID 116
[8] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) OS Commanding
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.2
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.1
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.6