ModSecurity (Core Rules) HTTP Parameter Pollution Filter Bypass Vulnerability

=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=A0 ModSecurity (Core Rules) HPP Filter Bypass Vulnerability
=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=A0 Affected Software : ModSecurity <=3D 2.5.9 using ModSecurity Core
Rules <=3D 2.5-1.6.1
=A0 Author=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Lavakumar Kupp=
an - lavakumar[dot]in[at]gmail[dot]com
=A0 Advisory URL=A0=A0=A0=A0=A0=A0 :
=A0 Severity=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : High
=A0 Local/Remote=A0=A0=A0=A0=A0=A0 : Remote

=A0 [Vulnerability Details]

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

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

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

=A0 For example when the following query is sent to the server:
=A0 -----------------------------
=A0 POST /index.aspx?a=3D1&a=3D2
=A0 Host:
=A0 Cookie: a=3D5; a=3D6
=A0 Content-Length: 7

=A0 a=3D3&a=3D4
=A0 -----------------------------

=A0 The server side interpretation of this data is as follows:

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

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

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

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

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

=A0=A0 1,2,3 from table

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

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

=A0=A0 1&value=3D2,3 from tab=

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

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


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

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

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

=A0 [Fix Information]

=A0=A0 N/A

=A0 [References]


=A0 [Legal Notices]

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

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