Filter Bypass Vulnerability

[rcbarnett-zz]

CORERULES-8: Details please refer to this link.

http://www.milw0rm.com/exploits/8930

[rcbarnett-zz]

Original reporter: samiux

[rcbarnett-zz]

brectanus: I'll repeat my comments on this here...

I agree, it is still an issue, but it is one of "Impedance Mismatch".

This is documented here:

https://www.modsecurity.org/documentation/modsecurity-apache/2.5.7/modsecurity2-apache-reference.html#N11EEE

And a blog on it here:

http://thread.gmane.org/gmane.comp.apache.mod-security.user/5637

ModSecurity was designed in an Apache centric manner and with Apache
centric technologies in mind (PHP especially as that was what Ivan was
using at the time). So, adding IIS specifics to ModSecurity may make
sense in your case, it may cause some strange side effects in most other
installs -- especially when not used as a reverse proxy.

What needs to be done -- and some thought has gone into it -- is to have
a setting that allows ModSecurity to know what flavor of webserver it is
trying to protect and what technologies are being used. Only then
should it try to workaround issues like you are seeing. If it tries to
guess, it will get it wrong.

You have some other options (workarounds, but require some effort):

1. Use QUERY_STRING, REQUEST_BODY and HTTP_HEADERS:Cookie instead of
   ARGS. This will give you the raw data to match against. You will need
   to modify rule patterns accordingly.

2. Extend ModSecurity and add another target variable or two (ASP_ARGS,
   ASPNET_ARGS maybe). ModSecurity has an API for doing this. An example
   is included in the source (apache2/api/mod_var_remote_addr_port.c).

If you do go the extension route, I am available to answer questions
(well, the mod-users list is). And if it is quality code, then release
it back to us and maybe we can include it in a future version of
ModSecurity.

While it is an issue, it is also a fairly common issue among WAF/IDS/IPS
and one that is rather difficult to solve. Essentially ModSecurity
needs to know how things are parsed by the web app and it can only know
that if you tell it the specifics. In this case, it is just rather
difficult to tell it without some dev efforts in rules and/or additional
targets.

[rcbarnett-zz]

brectanus: Adding Ryan Barnett's comment with a workaround...

Here is the rule to detect if there are multiple parameters submitted that have the same name -

SecRule ARGS_NAMES "." "chain,phase:2,t:none,nolog,pass,capture,setvar:'tx.arg_name%{tx.0}=+1',msg:'Multiple Parameters with the same Name.'"
SecRule TX:/ARG_NAME__/ "@gt 1"

As you can see, we are simply creating a TX collection using macro expansion for the variable name and we are incrementing a counter each time we see a parameter. The 2nd part of the chained rule is then evaluating the TX collection to see if any of them are greater than 1. Keep in mind that this isn't a direct HTTP Parameter Pollution rule per se, as it may in fact be legitimate functionality of your app to have multiple parameters with the same name. This rule works to alert you to where those occurrences are happening. If you find that this is legit functionality, you could incorporate an exception into the rule to exclude those specific parameter names.

[rcbarnett-zz]

rcbarnett: We added this HTTP Parameter Pollution (HPP) rule to the CRS v.2.0.0.