Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the wp-pagenavi domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/u918112125/domains/exploit.company/public_html/wp-includes/functions.php on line 6114
mod_security - exploit.company
header-logo
Suggest Exploit
vendor:
mod_security
by:
Unknown
5.5
CVSS
MEDIUM
Bypass
20
CWE
Product Name: mod_security
Affected Version From: mod_security <= 2.1.0
Affected Version To: mod_security <= 2.1.0
Patch Exists: NO
Related CWE:
CPE:
Metasploit:
Other Scripts:
Platforms Tested:
2007

mod_security <= 2.1.0 (ASCIIZ byte) POST Rules Bypass Vulnerability

mod_security <= 2.1.0 is vulnerable to a bypass vulnerability where ASCIIZ bytes in POST data of the application/x-www-form-urlencoded content-type are not properly handled, allowing an attacker to bypass security rules. This vulnerability occurs due to a mismatch between the RFC-defined rules followed by mod_security and the actual behavior of HTTP request parsers in scripting languages like Perl, Python, Java, and PHP.

Mitigation:

Upgrade to a version of mod_security greater than 2.1.0.
Source

Exploit-DB raw data:

mod_security <= 2.1.0 (ASCIIZ byte) POST Rules Bypass Vulnerability 
http://www.php-security.org/MOPB/BONUS-12-2007.html 

Affected is mod_security <= 2.1.0 Detailed information 

Detailed information

When mod_security receives a request it parses it into web application 
parameters in a way it believes is correct. Because the way it parses 
the incoming data follows the rules defined in RFCs and not the reality 
of how the HTTP request parsers are implemented in Perl, Python, Java, 
PHP there are a number of bypass vulnerabilities when the RFC and 
reality mismatch. 

One of the these differences is the way ASCIIZ bytes are handled when 
they occur in POST data of the application/x-www-form-urlencoded 
content-type. Because mod_security handles POST data of this kind as a C 
string it does not touch anything behind the first ASCIIZ byte because 
in the eyes of mod_security this is the end of the data. 

Unfortunately for mod_security this is not how the HTTP parsers of the 
different script languages handle this situation. Most script languages 
(Perl, Python, ...) just ignore the ASCIIZ byte and parse the data as if 
it is legal. Since PHP 5.2.0 this also applies to PHP. Proof of concept, 
exploit or instructions to reproduce 

<?php if (isset($_POST['var']) echo($_POST['var']); ?> 

Now call it with a command like 

$ echo -e "&var=<script>alert(/xss/);</script>" > postdata 
$ curl http://localhost/test.php --data-binary @postdata -A HarmlessUserAgent 
<script>alert(/xss/);</script> 

The example should not be blocked (because this is the default 
configuration) but in your error.log you will find a line saying that a 
possible XSS attack was detected. 

Now try the same with a ASCIIZ byte embedded. 

$ echo -e "\000&var=<script>alert(/xss/);</script>" > postdata 
$ curl http://localhost/test.php --data-binary @postdata -A HarmlessUserAgent 
<script>alert(/xss/);</script> 

This time there should be no log message in your error.log, because 
mod_security cannot see the var parameter behind the ASCIIZ byte.

# milw0rm.com [2007-03-07]