OS Command Injection [CWE-78]

OS Command Injection weakness describes improper neutralization of special elements, which could result in modification of the intended OS command that is sent to a downstream component.

Created: September 11, 2012
Latest Update: December 29, 2020

Table of Content

1. Description
2. Potential impact
3. Attack patterns
4. Affected software
5. Exploitation Examples
6. Severity and CVSS Scoring
7. Mitigations
8. Vulnerability Remediation Techniques and Examples
9. Common Fix Errors and Bypasses
10. References
11. Related Security Advisories

Want to have an in-depth understanding of all modern aspects of
OS Command Injection [CWE-78]? Read carefully this article and bookmark it to get back later, we regularly update this page.

1. Description

An attacker can execute malicious commands on a target operating system. OS command injection weaknesses can expose an environment to an attacker even if he does not have direct access to the operating system.

If the weakness occurs in a high privileged program, it may allow an attacker to specify commands that would not be available otherwise, or call alternate commands with privileges that the attacker does not have.

The danger of this weakness is aggravated if the breached process does not follow the principle of the least privilege because the malicious command may gain system privileges and allow the attacker to cause additional damage.

There are two major subtypes of OS Command Injection:

• An application is going to execute a fixed program that is under its control and accepts external input as arguments to that program.

  Example: The program uses the system("nslookup [HOSTNAME]") call to run nslookup and the HOSTNAME is given as an argument by the user. The hacker cannot prevent nslookup from executing, but if the program does not remove separators from the externally supplied HOSTNAME argument, the attacker could place separators inside the argument and execute his own command.

• The application uses input to select which program to run and what commands to use. The application sanitizes the input and then simply redirects the entire command to the operating system.

  Example: Application uses exec([COMMAND]) whereas [COMMAND] is supplied from and external source. The hacker that controls [COMMAND] argument can execute arbitrary commands or programs on the system.

2. Potential impact

An attacker can leverage this weakness to execute arbitrary commands, disclose sensitive information and cause denial of service. Any malicious activities would appear to come from the vulnerable application and will be executed in the security context of that application.

3. Attack patterns

The following CAPEC (Common Attack Pattern Enumeration and Classification) vectors are related to OS command injection weakness:

• CAPEC-6: TCP Header
• CAPEC-15: Command Delimiters
• CAPEC-43: Exploiting Multiple Input Interpretation Layers
• CAPEC-88: OS Command Injection
• CAPEC-108: Command Line Execution through SQL Injection

In an alternative WASC Threat Classification this weakness is described as an attack technique under WASC-31.

4. Affected software

Software that uses external input to send commands to the operating system can be vulnerable to this weakness. The weakness is common for many web applications.

5. Exploitation Examples

Let's have a look at vulnerability #2 in HTB23069 security advisory (CVE-2012-0992). Exploitation requirements dictate that user is logged-in into the application.

After successful authentication, apply the PoC code from the advisory:
http://[host]/interface/fax/fax_dispatch.php?file=1%27%20||%20ls%20%2Dla%20%3E%20123%20||

Execution result is shown on the image below:

This PoC code creates a file named 123 in the current directory with output of the "ls –la" command. We can access the file directly to view its contents:

This vulnerability can be used by any authenticated user to execute arbitrary commands on the target system with the privileges of the webserver as well as completely compromise the vulnerable application.

6. Severity and CVSS Scoring

When scoring OS Command Injection weaknesses, security specialists must consider the maximum possible impact. If an attacker can execute arbitrary commands with privileges of a system user the vulnerability must be scored as C:H/I:H/A:H.

Usually OS command injection vulnerabilities in web applications are scored with maximum confidentiality, integrity and availability ratings:
9.8 [CVSS:3.0/AV:N/.AC:L/.PR:N/.UI:N/.S:U/.C:H/.I:H/.A:H] - Critical severity.

7. Mitigations

To defend systems from this weakness, developers need to use library calls when possible, to create the desired functionality without external input. When external input is inescapable, developers need to use secure input and output handling. Sanitizing functions that attempt to catch each potentially dangerous character are prone to bypasses, a safer approach is to ensure that the data appears as it should before being processed, by using an appropriate regular expression.

As a temporary solution we strongly recommend blocking access to the vulnerable script until the issue is resolved. This can be achieved either using native functionality of the webserver or changing system access permissions to file.

Apache HTTP Server

Edit the configuration of your virtual host (usually this can be done via ".htaccess" file) and add the following lines:
<Files script.php>
order deny,allow
deny from all
</Files>


You can also allow access to file from specific IP address:
<Files script.php>
order deny,allow
deny from all
allow from 10.0.0.1
</Files>


Microsoft IIS

Edit the web.config file to limit access to the vulnerable "script.aspx":
The following rule allows access from IP address 10.0.0.1 and from subnet 192.168.0.0/24. Access from other IP addresses is restricted:
<configuration>
  <location path="script.aspx">
    <system.webServer>
      <security>
        <ipSecurity>
        <add ipAddress="10.0.0.1" />
        <add ipAddress="192.168.0.0" subnetMask="255.255.255.0" />
      </ipSecurity>
      </security>
    </system.webServer>
  </location>
</configuration>


You can also allow or restrict access to certain systems groups. The following configuration example allows only members of the "Administrators" group to access the vulnerable "script.aspx" file:
<configuration>
  <location path="script.aspx">
    <system.webServer>
      <security>
        <authorization>
          <remove users="*" roles="" verbs="" />
          <add accessType="Allow" roles="Administrators" />
        </authorization>
      </security>
    </system.webServer>
  </location>
</configuration>


Apache Tomcat

Add the following lines to your web.xml configuration file for a specific web application to restrict access to "script.jsp" file:
<security-constraint>
  <web-resource-collection>
    <web-resource-name>Forbidden</web-resource-name>
    <url-pattern>/script.jsp</url-pattern>
  </web-resource-collection>
  <auth-constraint />
</security-constraint>


nginx

Add the following rule to the "nginx.conf" file to restrict access to the "script.php" file located in the webroot folder:
location /script.php {
  deny all;
}


8. Vulnerability Remediation Techniques and Examples

8.1 General recommendations for software developers

All parameters should be enclosed in quotes in most cases to prevent successful exploitation of the vulnerability. Special symbols within parameter values must be escaped or replaced by safe symbols. Sometimes it is necessary to subtract all special symbols and spaces.

Assume that the "param" variable receives input via HTTP GET or HTTP POST request and then is used as a part of the filename within functions that manipulate files. In this case developers should follow instructions below to avoid the appearance of vulnerable code.

The following examples demonstrate sanitation of input data for popular programming languages:

PHP

or

PERL

ASP.NET

ColdFusion

Python

JAVA/JSP

These are general recommendations. Every case must be treated separately, considering application logic, peculiarities of each system and required functionality.

Caution: do not blindly copy-paste the above-mentioned solutions into your application code. In some cases this may result in incorrect behavior of the application or inconsistent patch. Carefully read the References or consult security specialists in case you are not sure how to patch a vulnerability.

8.2 Using Web Application Firewall (WAF)

Web Application Firewall can be an efficient solution to prevent vulnerability exploitation while you are developing or waiting for a security patch. We do not recommend using WAF as a long-term solution, neither as a replacement to properly developed security patch.

As an example, we will use an open source web application firewall ModSecurity developed by Trustwave. There are many rule sets for ModSecurity licensed under ASLv2 and widely distributed by security companies and organizations. These rule sets can be applied to cover all basic cases of vulnerabilities’ exploitation and can be used on production servers.

The following rule is part of the core rule set modsecurity_crs_40_generic_attacks.conf and can be used to protect web application against basic command injection attacks:

SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "(?i:(?:[\;\|\`]\W*?\bcc|\b(wget|curl))\b|\/cc(?:[\'\"\|\;\`\-\s]|$))" "phase:2,rev:'2',ver:'OWASP_CRS/2.2.7',maturity:'9',accuracy:'8',capture, t:none, t:normalisePath,ctl:auditLogParts=+E,block,msg:'System Command Injection',id:'950907', tag:'OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION', tag:'WASCTC/WASC-31',tag:'OWASP_TOP_10/A1',tag:'PCI/6.5.2',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION-%{matched_var_name}=%{tx.0},skipAfter:END_COMMAND_INJECTION1"
SecMarker END_COMMAND_INJECTION1

The rule searches for “bcc”, “wget”, “curl” and “cc” substrings within the request. OS command injection is hard to detect and block this way because there might be numerous ways to execute commands on the system.

Let’s have a look at OS command injection vulnerability in CosCms described in HTB23145 (CVE-2013-1668). The application uses the PHP "exec()" function to perform certain actions on the uploaded file. An attacker can create an HTTP POST request with a specially crafted filename and execute arbitrary commands on the system, as demonstrated by the PoC code. To mitigate this vulnerability we will have to validate filenames and allow only safe characters:

SecRule FILES_NAMES|FILES "!^([a-zA-Z\.0-9\:\\\\]+)$" "phase:2,rev:'2',ver:'HTBRIDGE /0.1',maturity:'9',accuracy:'7', t:none, ctl:auditLogParts=+E,block,msg:'OS Command Injection in CosCms HTB23145',id:'1000000002',severity:'2',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',capture,tag:'HTBRIDGE/WEB_ATTACK/OS',setvar:'tx.msg=%{rule.msg}'"

9. Common Fix Errors and Bypasses

A blacklist approach to filtering special characters is dangerous, as alternate characters and encodings may be used to break from the current context.

Below is a small list of examples of alternate characters that could be utilized by an attacker:

Argument Separators:

Curly Braces	{$COMMAND, $ARGUMENT}
Percent Encoding (Space	%20
Control Chars (Horizontal Tab)	%09
Vertical Tab (Windows)	%0b
UNIX Internal Field Separator (IFS)	$IFS$9 environment variable

Command Separators:

Newline Character	%0a
Carriage Return	%0d
.bat file Command Separator	%1a

10. References

1. CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') [cwe.mitre.org]
2. OS Command Injection [www.owasp.org]
3. Least Privilege [buildsecurityin.us-cert.gov]
4. Top 25 Series - Rank 9 - OS Command Injection [software-security.sans.org]
5. The World Wide Web Security FAQ: 6. CGI (Server) Scripts [www.w3.org]
6. CS390S, Week 9:Meta-Character Vulnerabilities [www.cs.purdue.edu]

11. OS Command Injection Vulnerabilities, Exploits and Examples

Path Traversal [CWE-22]

Path traversal or Directory traversal is a security vulnerability that describes improper limitation of pathname to a restricted directory.

Created: September 11, 2012
Latest Update: December 29, 2020

Table of Content

1. Description
2. Potential impact
3. Attack patterns
4. Affected software
5. Exploitation Examples
6. Severity and CVSS Scoring
7. Mitigations
8. Vulnerability Remediation Techniques and Examples
9. Common Fix Errors and Bypasses
10. References
11. Related Security Advisories

Want to have an in-depth understanding of all modern aspects of Path Traversal.
Read carefully this article and bookmark it to get back later, we regularly update this page.

1. Description

Path traversal or Directory traversal is a security vulnerability that occurs when software uses attacker-controlled input to construct a pathname to a directory or file located outside of the restricted directory. An attacker might be able to read arbitrary files on the target system.

There are two types of path traversal weaknesses:

2. Potential impact

An attacker can gain access to sensitive and system information on the system, delete or modify files. The maximum impact depends on the functionality of the application.

3. Attack patterns

There are following CAPEC (Common Attack Pattern Enumeration and Classification) patterns for the weakness:

• CAPEC-23: File System Function Injection, Content Based
• CAPEC-64: Using Slashes and URL Encoding Combined to Bypass Validation Logic
• CAPEC-76: Manipulating Input to File System Calls
• CAPEC-78: Using Escaped Slashes in Alternate Encoding
• CAPEC-79: Using Slashes in Alternate Encoding
• CAPEC-139: Relative Path Traversal

This weakness is also mentioned in alternative WASC Threat Classification under WASC-33 and is treated as an attack.

4. Affected software

Software that uses external input to manipulate files is potentially vulnerable to this weakness.

5. Exploitation Examples

As an example we will use HTB23079 security advisory (CVE-2012-1467). This vulnerability allows renaming arbitrary files on the target system. We will demonstrate how to use this weakness to read database credentials.

This vulnerability can be exploited by authenticated users only, however user registration is enabled by default. We will use the PoC code provided in the advisory: http://[host]/lib/pkp/lib/tinymce/jscripts/tiny_mce/plugins/ibrowser/scripts/rfiles.php?lang=en&param=rename|/../../../../../../../../../../../../config.inc.php|1x.txt%00.jpg

The above code renames the config.inc.php file into 1x.txt which is accessible remotely. Now, we can use the following URL http://[host]/public/site/images/[user]/1x.txt to read the contents of the config.inc.php file:

As demonstrated above, we obtained credentials of the database user. This technique can be used to gain complete control over the application or even the entire system.

6. Severity and CVSS Scoring

In most cases this vulnerability can be used to access restricted information. Depending on software design, this could be exploited to read and write files on the system or even execute arbitrary code.

In case of information disclosure, when an attacker can read only certain files, this weakness should be scored as:
5.3 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N] – Medium severity.

If an attacker can read arbitrary file on the system, it should be scored as:
7.5 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N] – High severity.

If an attacker can write files to arbitrary locations on the system, the vulnerability is usually scored as:
9.8 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H] – Critical severity.

7. Mitigations

To protect the application from this weakness it is advised to follow these instructions:

• Never use attacker controlled data as a filename or part of the filename when performing operations on files or folders. If filename should be based on the user's choice use predefined conditions instead of direct input.
• Perform whitelist checks when working with files or directories using user controlled input.
• Use sandbox environments (e.g. jail, chroot) that enforce strict boundaries between the process and the operating system.

8. Vulnerability Remediation Techniques and Examples

8.1 General recommendations for software developers

In the provided examples we consider the "param" variable to be received from a user via HTTP GET or POST request and used as part of a filename in functions that work with files. To avoid the vulnerability we need to handle the variable as recommended below. The examples illustrate the variable handling in popular programming languages.

PHP

PERL

ASP.NET

ColdFusion

or with POSIX class:

Python

JAVA/JSP

These are general recommendations. Every case must be treated separately, considering the logic of the application as well as singularity of the system and tasks. Direct coping of the data into the code may cause disruption of the application functionality or can lead to improper patching of the vulnerability.

Caution: do not blindly copy-paste the above-mentioned solutions into your application code. In some cases this may result in incorrect behavior of the application or an inconsistent patch. Carefully read the References or consult security specialists in case you are not sure how to patch a vulnerability.

8.2 Using Web Application Firewall (WAF)

Web Application Firewalls can be an efficient solution to prevent vulnerability exploitation while you are developing or waiting for a security patch. We do not recommend using a WAF as a long-term solution, neither as a replacement for properly developed security patch.

As an example, we will use an open source web application firewall ModSecurity developed by Trustwave. There are many rule sets for ModSecurity licensed under ASLv2 and widely distributed by security companies and organizations. These rule sets can be applied to cover all basic cases of vulnerabilities’ exploitation and can be used on production servers.

The following rule is a part of the core rule set modsecurity_crs_42_tight_security.conf and can be used to protect a web application against the majority of directory traversal attacks:
SecRule REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS:Referer "(?i)(?:\x5c|(?:%(?:2(?:5(?:2f|5c)|%46|f)|c(?:0%(?:9v|af)|1%1c)|u(?:221[56]|002f)|%32(?:%46|F)|e0%80%af|1u|5c)|\/))(?:%(?:2(?:(?:52)?e|%45)|(?:e0%8|c)0%ae|u(?:002e|2024)|%32(?:%45|E))|\.){2}(?:\x5c|(?:%(?:2(?:5(?:2f|5c)|%46|f)|c(?:0%(?:9v|af)|1%1c)|u(?:221[56]|002f)|%32(?:%46|F)|e0%80%af|1u|5c)|\/))" "phase:2,rev:'2',ver:'OWASP_CRS/2.2.7',maturity:'9',accuracy:'7',t:none, ctl:auditLogParts=+E,block,msg:'Path Traversal Attack',id:'950103',severity:'2',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',t:none,capture,tag:'OWASP_CRS/WEB_ATTACK/DIR_TRAVERSAL', setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:'tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/DIR_TRAVERSAL-%{matched_var_name}=%{matched_var}'"

Let’s have a look at a vulnerable PHP script that reads contents of a file passed via the “file” HTTP GET parameter:

The abovementioned SecRule will be triggered if we try to use classic exploitation example:
http://[host]/vulnscript.php?file=../../../etc/passwd

Now, let’s have a look at a real-world example of vulnerable code described in HTB23144 (CVE-2013-1469):

This vulnerability can be exploited on systems where the "file_exists()" PHP function returns "true" for nonexistent directories within the filename.
The following PoC code will be blocked by the provided rule and will protect the vulnerable application:
http://[host]/install.php?dl=/../../local/config/database.inc.php

Another example of path traversal weakness in ocPortal descibed in HTB23078 (CVE-2012-1471) accepts a full file path via the file parameter and displays contents of the provided filename. Unfortunately, this vulnerability will not be blocked by the default rule set since there is no need to use directory traversal sequences to exploit this vulnerability:
http://[host]/site/catalogue_file.php?original_filename=1.txt&file=%252fetc%252fpasswd

The following rule will block access to any file outside the current directory:
SecRule ARGS_GET:file "(/)|(\\\\)" "phase:2,rev:'1',ver:'HTBRIDGE /0.1',maturity:'9',accuracy:'7', t:none, ctl:auditLogParts=+E,block, msg:'Path Traversal in ocPortal HTB23078',id:'1000000001',severity:'2', logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',capture,tag:'HTBRIDGE/WEB_ATTACK/TRAVERSAL',setvar:'tx.msg=%{rule.msg}'"

We remind once again that delegation of web application security to a WAF may be quite an efficient temporary solution. However, it is not intended to replace a proper security patch.

9. Common Fix Errors and Bypasses

There are numerous techniques attackers may use to fool weak defence implementations, a subset of common techniques is listed below:

URL Encoding

http://[host]/vuln_script.php?lang=..%2F..%2F..%2F..%2Fetc%2Fpasswd

Double URL encoding

Encoding the traversal sequences twice may fool systems that decode the input once:

http://[host]/vuln_script.php?lang=%252e%252e%252e%252e%252fetc%252fpasswd%00

Unicode Encoding

Encoding the traversal sequences with 16-bit Unicode encoding:

http://[host]/vuln_script.php?lang=%u002e%u2215%u002e%u2215etc%u2215passwd

Overlong Unicode UTF-8 Encoding

Works on systems that have the capability to process overlong UTF-8 sequences:

http://[host]/vuln_script.php?lang=..%c0%af..%c0%af..%c0%afetc%c0%afpasswd

Valid Traversal Sequences

The web browser will treat the following examples as valid:

http://[host]/vuln_script.php?lang=/%5C../%5C../%5C../%5C../%5C../%5C..etc/passwd http://[host]/vuln_script.php?lang=..//.//.//etc/passwd

10. References

1. CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') [cwe.mitre.org]
2. Path Traversal [owasp.org]
3. Top 25 Series - Rank 7 - Path Traversal [software-security.sans.org]

11. Path Traversal Vulnerabilities, Exploits and Examples

• HTB23261: OS Command Injection in Vesta Control Panel
• HTB23145: OS Command Injection in CosCms
• HTB23127: Multiple Command Execution Vulnerabilities in Smartphone Pentest Framework (SPF)
• HTB23123: Multiple Vulnerabilities in Smartphone Pentest Framework (SPF)
• HTB23069: Multiple vulnerabilities in OpenEMR

Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to ImmuniWeb is given.

↑ Back to Top