ModSecurity strips POST data information from request in DetectionOnly mode

[rcbarnett-zz]

MODSEC-390: For a Dutch bank we purchased the commercial ruleset from TrustWave labs. In the process of setting-up the ModSecurity in combination with IIS we hit an issue which we cannot solve and basically renders the ModSecurity module unusable for our environment.

When enabling ModSecurity for the default virtual host, POST parameters are no longer passed to the JBoss application server via the mod_jk plugin.
We deployed on this virtual host the mod_jk ISAPI module which works as expected when ModSecurity is disabled.

After enabling ModSecurity (DetectionOnly mode), access to the the login-page via Java ServerFaces works fine (and access to all other dynamic content which does not require POST information to be sent) until we try to submit for instance the username.

The submitted username is received by IIS (confirmed this through our Web Debugging Proxy (Charles)), but the POST parameter data itself is empty when received by our application (confirmed by the log files produced by the application).

In the Windows EventLog Application log there are no ModSecurity errors, only warnings concerning rules have been hit.

We installed ModSecurity using the MSI installer on IIS.
Installation seems successful, we see the in Windows EventLogger the ModSecurity Information logs:

ModSecurity for IIS (STABLE)/2.7.3 (http://www.modsecurity.org/) configured.
ModSecurity: APR compiled version="1.4.6"; loaded version="1.4.6"
ModSecurity: PCRE compiled version="8.30 "; loaded version="8.30 2012-02-04"
ModSecurity: LUA compiled version="Lua 5.1"
ModSecurity: LIBXML compiled version="2.7.7"

Please advice,
All the best,
Robin Huiser

[rcbarnett-zz]

Original reporter: rhuiser

[rcbarnett-zz]

bpinto: This is a known issue. Looks like some modules other than ASP.NET have problem forward request body with ModSecurity.

Right now you cannot enable request body in this cases. Setting SecRequestBodyAccess Off will make it work

Thanks

Breno

[rcbarnett-zz]

rhuiser: Thank you Breno for your swift answer!

Do you know when or which release of ModSecurity this issue will be solved since switching off the option will no longer protect us from XSS or SQL injection (amongst others)?

[rcbarnett-zz]

bpinto: Hello Robin,

We are discussing it with Microsoft. This is an issue based on IIS arch. Right now we don't have an ETA for this issue. However we agree this should be fixed as soon as possible.

Turning off SecRequestBodyAccess means modsecurity will not protect attacks coming into request body. So basically modsecurity will inspect request headers. If SQL attacks are going into requests headers, modsecurity will still protect.

Thanks

Breno

[rcbarnett-zz]

rhuiser: Hi Breno,

We tried to work around the issue by splitting the virtual hosts in IIS; VHOST 1 with ModSecurity including Application Request Routing module of Microsoft to act as a reverse proxy by forwarding all (scanned) traffic to VHOST 2 which has ModJK deployed:

VHOST 1

ModSecurity
ARR 2.5 ----------------> VHOST 2
========
ModJK -------------------> JBOSS SERVER

Unfortunately, when switching "SecRequestBodyAccess" to "On", traffic is no longer forwarded (time out).

Another setup we tried is to remove ModJK from the equation and have ARR forwarding all traffic to JBoss directly:

VHOST 1

ModSecurity
ARR 2.5 ----------------> JBOSS SERVER

Unfortunately, when switching "SecRequestBodyAccess" to "On", POST body is empty again.

Could you confirm from the architecture issues you are facing with ModSecurity / IIS / SecRequestBodyAccess the ARR module is also not usable in the setups shown above or is this a different issue?

Thanks in advance,
Robin

[rcbarnett-zz]

bpinto: Hello Robin,

Yes. Looks like the issue we are already working on.

Thanks

Breno

[rcbarnett-zz]

ianw: I am seeing the exact same symptoms on CentOS 6.4 + nginx 1.5.1 + ModSecurity 2.7.4 - does the same architecture issue exist for the nginx port?

Thanks,
Ian

[rcbarnett-zz]

bpinto: Could you please describe in details your environment and nginx + modsecurity configuration ? I would like to try reproduce.

Also if you can send details about the POST you are trying to send.

Thanks

[rcbarnett-zz]

ianw: The environment is a CentOS 6.4 installation; nginx has the following -V output:

nginx version: nginx/1.5.1
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
TLS SNI support enabled
configure arguments: --with-debug --with-ipv6 --with-http_ssl_module --with-http_spdy_module --with-http_realip_module --with-http_stub_status_module --with-pcre=/home/build/pcre-8.33 --with-pcre-jit --with-openssl=/home/build/openssl-1.0.1e --add-module=/home/build/modsecurity-apache_2.7.4/nginx/modsecurity

ModSecurity is built from the 2.7.4 release tarball, with the following options:
./configure --enable-standalone-module --enable-pcre-jit --with-pcre=../pcre-8.33

I can reproduce the problem with the modsecurity.conf-recommended from the 2.7.4 tarball and the Core Rules 2.27.

Any POST request can cause the issue. Here is a simple form that will trigger it, when combined with the below configuration:

First name:

I can reproduce with the following abbreviated configuration, which sends all requests upstream to the requestb.in service:

upstream requestbin {
server requestb.in;
}

server {
listen 80 default_server;
server_name testserver;

ModSecurityEnabled on;
ModSecurityConfig /etc/nginx/modsecurity.conf;

location / {
    root /var/www/html/;
}
location /requestbin/ {
    proxy_pass http://requestbin/12191nu1;
    proxy_set_header Host requestb.in;
}

}

[rcbarnett-zz]

ianw: Retested with ModSecurity 2.7.5 RC tarball; error is still present. Is there any other status update on this?

[rcbarnett-zz]

bpinto: Ian,

I didn't test with your module options. Just with default nginx modules + modsecurity and a similar configuration:

upstream backend {
    server 192.168.0.103:80;
}

server {
    listen       80;
    server_name  localhost;
    proxy_set_header Accept-Encoding " ";
    ModSecurityEnabled on;
    ModSecurityConfig modsecurity.conf;
    location / {
        root   html;
        index  index.html index.htm;
        proxy_pass http://backend;
        proxy_read_timeout 300;
    }

    location /backend/ {
        proxy_pass http://backend;
        proxy_read_timeout 300;
    }

Then submit a POST to 192.168.0.103/backend/index.html and all looks fine from my side. I will need more time to try reproduce your issue.
Do you see anything from my config i should change to reproduce ?

Thanks

Breno

[rcbarnett-zz]

ianw: I assume you mean submit the POST to localhost/backend/index.html? If submitted to 192.168.0.103/backend/index.html that bypasses the Nginx server entirely.

The critical setting is in my modsecurity.conf:
SecRequestBodyAccess On

If this is set to "Off" my installation works fine; with it "On" all POSTs are truncated during the forward to the backend server.

Thanks,
Ian

[rcbarnett-zz]

bpinto: Yes. Sorry for the typo. Sending it to localhost (nginx server)

SecRequestBodyAccess is also On from my side.

Could you attach your debug.log (level 9) with the malformed POST ?

Thanks

[rcbarnett-zz]

ianw: My apologies for taking so long to get back to this. I've attached a level 9 debug log from ModSecurity for the failed request and also an Nginx debug log for the same request.