exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

ModSecurity 2.5.9 Filter Bypass

ModSecurity 2.5.9 Filter Bypass
Posted Jun 11, 2009
Authored by Lavakumar Kuppan

ModSecurity versions 2.5.9 and below using ModSecurity Core Rules versions 2.5-1.6.1 and below suffer from a HPP filter bypass vulnerability.

tags | exploit, bypass
SHA-256 | 2f61c414417e494073857e6cf0e2a2326c2b1a0f0799ba9d2d5afabe77938145

ModSecurity 2.5.9 Filter Bypass

Change Mirror Download
ModSecurity (Core Rules) HPP Filter Bypass Vulnerability

Affected Software : ModSecurity <= 2.5.9 using ModSecurity Core Rules <= 2.5-1.6.1
Author : Lavakumar Kuppan - lavakumar[dot]in[at]gmail[dot]com
Advisory URL : http://www.lavakumar.com
Severity : High
Local/Remote : Remote

[Vulnerability Details]

Modsecurity is an Open source Web Application firewall which runs as an Apache
module. It has a comprehensive set of rules called 'ModSecurity Core Rules' for common web application
attacks like SQL Injection, Cross-Site Scripting etc.

It is possible to bypass the ModSecurity Core Rules due to the difference in behaviour
of ModSecurity and ASP/ASP.NET applications in handling duplicate HTTP GET/POST/Cookie
parameters. Using duplicate parameters has been termed as HTTP Parameter Pollution by Luca Carettoni
and Stefano Di Paola.

When multiple GET/POST/Cookie parameters of the same name are passed in the HTTP request
to ASP and ASP.NET applications they are treated as an array collection.
This leads to the values being concatenated with a comma inbetween them.

For example when the following query is sent to the server:
POST /index.aspx?a=1&a=2
Host: www.example.com
Cookie: a=5; a=6
Content-Length: 7


The server side interpretation of this data is as follows:

Request.Params["a"] --> "1,2,3,4,5,6" ( if "a" was registered as a server-side control ) (ASP.NET Only)
Request.Params["a"] --> "1,2,5,6" ( if "a" was not registered as a server-side control ) (ASP.NET Only)
Request.QueryString["a"] --> "1,2" (ASP and ASP.NET)
Request.Form["a"] --> "3,4" (ASP and ASP.NET)

This behaviour is unique to ASP and ASP.NET applications and ModSecurity does not interpret this data in the
same way. When dealt with multiple parameters of the same name ModSecurity matches the value of each instance
of the parameter seperately against its rule base. Incase of the above example ModSecurity would run '1' against
the rule set first then '2' and so on till '6'.

Since data is interpreted differently by the Web Application and the Firewall this produces intresting possibilities
for a filter bypass scenario.

This theory was tested against the SQL Injection rule base of ModSecurity Core Rules and was found to bypass the
default-enabled rule set successfully.

The following request is blocked by ModSecurity as this matches its Generic SQL Injection Attack rule.

http://example.com/search.aspx?value=select 1,2,3 from table

ModSecurity Interpretation:
value = select 1,2,3 from table
Web Application Interpretation:
value = select 1,2,3 from table

However the same payload can be sent to the server by splitting it using duplicate parameters like below.

http://example.com/search.aspx?value=select 1&value=2,3 from table

ModSecurity Interpretation:
value = select 1
value = 2,3 from table
Web Application Interpretation:
value select 1,2,3 from table

The attack can be made more flexible by using the inline comment feature in MS SQL servers.


ModSecurity Interpretation:
Web Application Interpretation:
value = select/*,*/1,2,3/*,*/from/*,*/table

This technique could possibly be extended to exploit other types of Web Application vulnerabilities as well.

Refer the whitepaper 'Split and Join' (see references) for more details on this attack.

[Fix Information]




[Legal Notices]

The information in the advisory is believed to be accurate at the
time of publishing based on currently available information.
This information is provided as-is, as a free service to the community.
There are no warranties with regard to this information.
The author does not accept any liability for any direct,
indirect, or consequential loss or damage arising from use of,
or reliance on, this information.
Permission is hereby granted for the redistribution of this alert,
provided that the content is not altered in any way, except
reformatting, and that due credit is given.

This vulnerability has been disclosed in accordance with the RFP
Full-Disclosure Policy v2.0, available at:

Login or Register to add favorites

File Archive:

February 2023

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Feb 1st
    11 Files
  • 2
    Feb 2nd
    9 Files
  • 3
    Feb 3rd
    0 Files
  • 4
    Feb 4th
    0 Files
  • 5
    Feb 5th
    0 Files
  • 6
    Feb 6th
    0 Files
  • 7
    Feb 7th
    0 Files
  • 8
    Feb 8th
    0 Files
  • 9
    Feb 9th
    0 Files
  • 10
    Feb 10th
    0 Files
  • 11
    Feb 11th
    0 Files
  • 12
    Feb 12th
    0 Files
  • 13
    Feb 13th
    0 Files
  • 14
    Feb 14th
    0 Files
  • 15
    Feb 15th
    0 Files
  • 16
    Feb 16th
    0 Files
  • 17
    Feb 17th
    0 Files
  • 18
    Feb 18th
    0 Files
  • 19
    Feb 19th
    0 Files
  • 20
    Feb 20th
    0 Files
  • 21
    Feb 21st
    0 Files
  • 22
    Feb 22nd
    0 Files
  • 23
    Feb 23rd
    0 Files
  • 24
    Feb 24th
    0 Files
  • 25
    Feb 25th
    0 Files
  • 26
    Feb 26th
    0 Files
  • 27
    Feb 27th
    0 Files
  • 28
    Feb 28th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Hosting By