Bypassing insufficient blacklisting: Brief introduction

Operating system (OS) command injection attack is a variant of code injection attacks which are considered a major security threat that in fact, is classified as No. 1 on the 2013 OWASP top ten web security risks [1]. There are many types of code injection attacks including:

• SQL injection [2]
• Cross Site Scripting [3]
• OS command injection [4]
• XPath injection [5]
• LDAP injection [6]

OS command injection attacks may occur in applications that accept user provided input and execute OS commands using as parameters the received input. They have been discovered in web applications hosted in web servers (Windows or Linux) as well as in web-based management interfaces of networking devices, such as home/office routers, IP cameras, IP PBX applications and network printers. Moreover, command injection vulnerabilities can be found in IoT devices. However, the injected OS commands are usually executed with the same permissions that the application possesses (i.e. root). OS command injection attacks are possible in most cases due to lack of correct input data validation, which can be manipulated by the attacker (web forms, cookies, HTTP headers etc.)

Detecting and exploiting command injection flaws

Due to the fact that there are not many tools to automate the process of detecting and exploiting command injection vulnerabilities, in this blog post Commix tool will be used. Commix (a short for [COMM]and [I]njection e[X]ploiter) is an automated tool aiming to facilitate web developers, penetration testers and security researchers to test web applications with the view to find bugs, errors or vulnerabilities related to command injection attacks. It is important to note that the module is capable of performing command injection not only in the HTTP GET / POST parameters, but also in HTTP parameters, such as HTTP cookie, HTTP user-agent and referrer header values. The tool is written in Python (version 2.6. or 2.7) and runs in both Unix/Linux and Windows operating systems. Commix is free to download through the GitHub repository [7]. It is worth mentioning that Commix comes preinstalled in many security-oriented OS’s including the well-known Kali Linux [8], while its capabilities have been presented in the BlackHat Europe 2015 Security Conference (Netherlands, Amsterdam) [9].

Attack scenarios and lab setup

The main objective of this article is to examine the detection and exploitation capabilities of Commix against blacklisting techniques. The general idea behind blacklisting is to check for malicious patterns before allowing the execution of users input. More specifically, in the case of OS command injection attack, a blacklist can strip out from the users’ input all “suspicious” characters (i.e. “;”,”|”,”&”, etc.). However, a basic disadvantage of blacklisting, which greatly limits its effectiveness, is that the attacker can discover a variation of the command injection attack vectors not included in the blacklist and, hence, he can launch the attack successfully. In order to be able to get a reliable sample of checks against the most common blacklisting techniques, the Damn Vulnerable Web Application (DVWA) v1.10 [10] was installed on a Debian Linux (3.16.0-4) operating system. DVWA is a free, open source PHP/MySQL web application that supports four different security levels, low, medium, high or impossible. The security level changes the vulnerability level of DVWA:

• Low: This security level is completely vulnerable and has no security countermeasures at all. Its use is to be as an example of how web application vulnerabilities manifest through bad coding practices and to serve as a platform to teach or learn basic exploitation techniques.
• Medium: This setting is mainly to give an example to the user of bad security practices, where the developer has tried but failed to secure an application. It also acts as a challenge to users to refine their exploitation techniques.
• High: This option is an extension to the medium difficulty, with a mixture of harder or alternative bad practices to attempt to secure the code. The vulnerability may not allow the same extent of the exploitation, similar in various CTF competitions.
• Impossible: This level should be secure against all vulnerabilities. It is used to compare the vulnerable source code to the secure source code. (Prior to DVWA v1.9, this level was known as ‘high’).

DVWA also comes with an outdated (v0.6) Web Application Firewall (WAF) called PHPIDS. PHPIDS (PHP-Intrusion Detection System) [11] is a security layer for PHP based web applications. PHPIDS works by filtering any user’s supplied input against a blacklist of potentially malicious code. It is used in DVWA to serve as a live example of how WAFs can help improve security and in some cases how WAFs can be circumvented. At this point it is worth noting that during this research, the latest stable version (v0.7) [12] of PHPIDS was installed in DVWA.

All the experiments were mainly conducted in two separate rounds of checks:

• In the first round of security checks, attacks were attempted at all security levels of DVWA without the PHPIDS WAF being activated.
• In the second round of security checks, exactly the same attacks were attempted as the first set of checks, but with the PHPIDS WAF enabled during the detection and exploitation procedure.

Detection and exploitation results

It is summarized below, the detection and exploitation results of the first and the second round of security checks that were conducted against the vulnerable “ip” POST parameter of “/vulnerabilities/exec/” in DVWA against all* supported security levels (from Low to Impossible).

* On both rounds of security checks, in the “Impossible” security level, Commix did not detect any vulnerability (as expected) because this level is not meant to be exploitable.

1^st Round of checks: PHPIDS 0.7 WAF disabled (Table 1):

• Regarding the “Low” and “Medium” security levels, Commix successfully identified and exploited the command injection vulnerability with every supported exploitation technique.
• Finally, in the “High” security level, although more strict security measures – in order to secure the code – were applied (i.e., better characters blacklisting) Commix successfully identified and exploited the command injection vulnerability using file-based exploitation technique.

Table 1: Succeeded command injection attacks with PHPIDS disabled.

2^nd Round of checks: PHPIDS 0.7 WAF enabled (Table 2):

• Concerning the “Low” and “Medium” security levels, Commix successfully identified and exploited the command injection vulnerabilities using results-based and file-based exploitation techniques.
• Also, in “High” security level, Commix successfully identified and exploited the OS command injection vulnerabilities using the file-based exploitation technique.

Table 2: Succeeded command injection attacks with the PHPIDS enabled.

Lastly it is worth mentioning that, even though the remote command execution protection filter that is used by the PHPIDS v0.7 to prevent remote OS command injection attacks seems quite weak (on this we will refer later) specific characters (i.e “$”, “{“,”}”,”))” etc) which are used in most payloads were detected. After further analysis on that issue it was identified that this happens due to overlays by other irrelevant WAF filters. In order to circumvent this restriction the “–backticks” switch (which uses the backtick (`) instead of the “$()” for command substitution [13]) was used.

Analyzing the weak filter of PHPIDS v0.7

As it has been already mentioned, PHPIDS 0.7 does not protect against OS command injection attacks. The filter that is used for protection against this type of attacks is included in the “default_filter.json” and “default_filter.xml” files. More specifically the filter with id “74” checks only for attempts to execute OS commands, such “ping  -n 3 127.0.0.1 ”, ping localhost -n 3” etc as presented below:

ping(.*)[\-(.*)\w|\w(.*)\-]

Moreover, we came to the point to suggest an additional regular expression for the aforementioned filter in such way all the attempted payloads have failed due to all the symbols used for OS command injection attacks are now being detected and blocked by the newly proposed filter:

(?:[^|;|&|\||\<|\>|`|\$|\(|\)|\{|\}]\W*?\b)

Table 3:  Failed command injection attacks after PHPIDS updated filter

Conclusions

Concluding all the above, this article was mainly focused on the weak blacklisting features, as provided by all security levels of DVWA, combined with the latest stable version of the PHPIDS WAF. Once it was identified that Commix was able to bypass the weak blacklisting filters on each security level (i.e. Low, Medium, and High) with the presence of the latest stable PHPIDS WAF, a new rule (that successfully blocks all the exploitation attempts) was proposed.

References

[1] https://www.owasp.org/index.php/Code_Injection
[2] https://www.owasp.org/index.php/SQL_Injection
[3] https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
[4] https://www.owasp.org/index.php/Command_Injection
[5] https://www.owasp.org/index.php/XPATH_Injection
[6] https://www.owasp.org/index.php/LDAP_injection
[7] https://github.com/commixproject/commix
[8] https://tools.kali.org/exploitation-tools/commix
[9] https://www.blackhat.com/docs/eu-15/materials/eu-15-Stasinopoulos-Commix-Detecting-And-Exploiting-Command-Injection-Flaws.pdf
[10] https://github.com/ethicalhack3r/DVWA
[11] https://github.com/PHPIDS/PHPIDS
[12] https://github.com/PHPIDS/PHPIDS/releases/tag/0.7
[13] http://tldp.org/LDP/abs/html/commandsub.html