mod_sec not scanning post payload

Community support forums for the free/delayed modsecurity rules feed. There is no such thing as a bad question here as long as it pertains to using the delayed modsecurity rules feed. Newbies feel free to get help getting started or asking questions that may be obvious.
vladimir1
New Forum User
New Forum User
Posts: 4
Joined: Tue Apr 19, 2011 6:49 am
Location: nyc

mod_sec not scanning post payload

Unread post by vladimir1 »

Hi,
I've been pulling my hair out with this, and have googled extensively but can't seem to find the solution.

I'm using mod_sec with the delayed APL rules on a ubuntu 10.04 LAMP setup.
It scans and intercepts malicious $_POST payload perfectly on my test page.

However it refuses to intercept $_POST payload on some pages. The problem is with $_POST array fields such as test[] in the example below:

Code: Select all

<input type="text" name="alpha" />
<br />
<br />
<input type="text" name="test[]" />
<br />
<br />
<input type="text" name="test[]" />
update - after running extensive omission debugging:

1) starting or not starting the session has no effect on this peculiar behaviour
2) not loading or loading AJAX or CSS files makes no difference.
3) putting the test page in the same folder as the problem page makes no difference.(the test page continues to be intercepted normally)
4) var_dump of $_POST looks the same for both test page and problem page.

I'll add a rawdump of the $_POST data as well.

It seems like I'm not doing something simple.

Thanks for any help.
Last edited by vladimir1 on Tue Apr 19, 2011 8:27 am, edited 1 time in total.
scott
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
Posts: 8355
Joined: Wed Dec 31, 1969 8:00 pm
Location: earth
Contact:

Re: mod_sec not scanning post payload after session is start

Unread post by scott »

Id say the first thing to start with is how you built the module & what libraries it is linked against.
User avatar
mikeshinn
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
Posts: 4149
Joined: Thu Feb 07, 2008 7:49 pm
Location: Chantilly, VA

Re: mod_sec not scanning post payload

Unread post by mikeshinn »

Also check your configuration matches:

https://www.atomicorp.com/wiki/index.ph ... rity_Rules

And that modsecurity loads FIRST in apache. If other modules load before it, expect strange behavior including bypassing modsecurity in some cases.
vladimir1
New Forum User
New Forum User
Posts: 4
Joined: Tue Apr 19, 2011 6:49 am
Location: nyc

Re: mod_sec not scanning post payload

Unread post by vladimir1 »

Thank you for the quick replies.

I don't know if this is bug peculiar to my configuration, but after stripping down the offending page to the bare minimum I found that mod_security was not intercepting POST payload arrays which had a name longer than 10 characters(incl. the square brackets]
e.g.

Code: Select all

It doesn't work with name = "userdata[]"
but it works with  name = "userdat[]" 
I have set it up as the first module to load and my config is the same as on the wiki.

I have shortened the Post variables that I was using, and now it seems to be working fine.

Can you confirm that this is particular to my config? It seems highly unusual

Thanks for the help.
scott
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
Posts: 8355
Joined: Wed Dec 31, 1969 8:00 pm
Location: earth
Contact:

Re: mod_sec not scanning post payload

Unread post by scott »

That sounds like maybe your pcre settings, how did you build the module?
User avatar
mikeshinn
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
Posts: 4149
Joined: Thu Feb 07, 2008 7:49 pm
Location: Chantilly, VA

Re: mod_sec not scanning post payload

Unread post by mikeshinn »

Sounds like a possible local issue, because that doesnt happen in a normal build. As Scott mentioned it could be the way you built modsecurity or your config or pcre. Theres no reason in either the rules, or in modsecurity that this would happen. Perhaps you have a bug in an optimizer in your compiler, libpcre, some local build peculiarity, etc. could lead to this. Also the order in which you load your apache modules absolutely will effect the behavior of modsec and other modules.

I'd recommend you double check your config, make sure you arent using some other rules that are bypassing something and check your build to make sure its not some weird system build artifact and of course make sure you are running the latest modsec.

Then throw modsec into debug mode, check to make sure you dont have some weird issue happening with the config and if you rule that our trace apache to make sure its not a weird local build issue.
vladimir1
New Forum User
New Forum User
Posts: 4
Joined: Tue Apr 19, 2011 6:49 am
Location: nyc

Re: mod_sec not scanning post payload

Unread post by vladimir1 »

I installed mod_sec & apache from the repositories for 10.04 ubuntu server 32bit edition.
Last night I set up a virtual machine using the 64 bit server edition and it had the exact same problem. I also updated to the latest modsec that is in the repos on both machines; it made no difference.

http://packages.ubuntu.com/natty/libapache-mod-security

I haven't installed PCRE separately, modsec and apache are using the one bundled with them in the distribution.

I had really hoped my days of compiling were history.
scott
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
Posts: 8355
Joined: Wed Dec 31, 1969 8:00 pm
Location: earth
Contact:

Re: mod_sec not scanning post payload

Unread post by scott »

Its possible to that upstream put it together wrong, or that some other library on the system is interfering with the module. I can confirm that your test case does not occur on:

centos 5.6 with mod_security 2.5.13-2 with pcre 6.6-2, and httpd 2.2.3-43
and
fedora 14 with mod_security 2.5.13-2 with pcre 8.10.1, and httpd 2.2.17-1

if you want to try ruling out issues with your mod_security build itself, I recommend you compile it with the following settings:
./configure \
--disable-pcre-match-limit \
--disable-pcre-match-limit-recursion

and when you load the module into apache, make sure its loaded before other components, like php, mod_perl, etc. We do this by invoking it through the conf.d/ dir as 00_mod_security.conf. Also ensure that you've removed the previous mod_security, and if you have by any chance multiple pcre installs on the system that you limit it to just the one library. Ive absolutely seen multiple pcre libraries cause very unusual rule loading problems when we were doing the cpanel integration.
vladimir1
New Forum User
New Forum User
Posts: 4
Joined: Tue Apr 19, 2011 6:49 am
Location: nyc

Re: mod_sec not scanning post payload

Unread post by vladimir1 »

Hi,

I compiled mod-sec with the above configure options on a fresh CentOS 5.6 install, and I had the same problem.

I then compiled PCRE and mod-sec both from source on my 10.04 64bit ubuntu install, and I had the same problem as before.

As before mod-sec is the first module to load, and I am using the ASL rules.
I think I'm overlooking something really simple?

I enabled debug mode and this is the output (from the relevant areas):

FIRST: $_POST name is userdata[] and mod-sec did not pick up <script>

Code: Select all

5978][/test1.php][4] Recipe: Invoking rule 7f314d4b6de8; [file "/etc/apache2/modsecurity.d/gotroot/10_asl_rules.conf"] [line "904"].
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][5] Rule 7f314d4b6de8: SecRule "REQUEST_URI|ARGS|ARGS_NAMES|!ARGS:arg2|!ARGS:resumoDetalhe|!ARGS:Right_photo_1|!ARGS:/^K2ExtraField/|!ARGS:/submitcode/|!ARGS:beschrijving|!ARGS:custombannercode|!ARGS:bannercode|!ARGS:privatecapacity|!ARGS:diz|!ARGS:FormLayout|!ARGS:/^fck/|!ARGS:parent_name|!ARGS:/^code_tscript/|!ARGS:_qf_Group_next|!ARGS:project_company|!ARGS:categories_title|!ARGS:antwoord|!ARGS:project_company|!ARGS:signature|!ARGS:paepdc|!ARGS:tpl_source|!ARGS:teaser_js|!ARGS:/^autoDS/|!ARGS:FrmSide|!ARGS:mainKeywords|!ARGS:/VB_announce/|!ARGS:guardar|!ARGS:/serendipity/|!ARGS:omschrijving|!ARGS:resolution|!ARGS:newyddionc|!ARGS:bericht|!ARGS:property_copy|!ARGS:/^outpay/|!ARGS:bedrijfsprofiel|!ARGS:s_query|!ARGS:finish_survey|!ARGS:photolater|!ARGS:ticket_response|!ARGS:/element/|!ARGS:option[vbpclosedreason]|!ARGS:/introduction/|!ARGS:/contenido/|!ARGS:/sql/|!ARGS:query|!ARGS:c_features|!ARGS:/tekst/|!ARGS:embeddump|!ARGS:other_clubs|!ARGS:/^elm/|!ARGS:/^saes/|!ARGS:dlv_instructions|!ARGS:/^cymr/|!ARGS:_qf_
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][4] Expanded "REQUEST_URI|ARGS|ARGS_NAMES|!ARGS:arg2|!ARGS:resumoDetalhe|!ARGS:Right_photo_1|!ARGS:/^K2ExtraField/|!ARGS:/submitcode/|!ARGS:beschrijving|!ARGS:custombannercode|!ARGS:bannercode|!ARGS:privatecapacity|!ARGS:diz|!ARGS:FormLayout|!ARGS:/^fck/|!ARGS:parent_name|!ARGS:/^code_tscript/|!ARGS:_qf_Group_next|!ARGS:project_company|!ARGS:categories_title|!ARGS:antwoord|!ARGS:project_company|!ARGS:signature|!ARGS:paepdc|!ARGS:tpl_source|!ARGS:teaser_js|!ARGS:/^autoDS/|!ARGS:FrmSide|!ARGS:mainKeywords|!ARGS:/VB_announce/|!ARGS:guardar|!ARGS:/serendipity/|!ARGS:omschrijving|!ARGS:resolution|!ARGS:newyddionc|!ARGS:bericht|!ARGS:property_copy|!ARGS:/^outpay/|!ARGS:bedrijfsprofiel|!ARGS:s_query|!ARGS:finish_survey|!ARGS:photolater|!ARGS:ticket_response|!ARGS:/element/|!ARGS:option[vbpclosedreason]|!ARGS:/introduction/|!ARGS:/contenido/|!ARGS:/sql/|!ARGS:query|!ARGS:c_features|!ARGS:/tekst/|!ARGS:embeddump|!ARGS:other_clubs|!ARGS:/^elm/|!ARGS:/^saes/|!ARGS:dlv_instructions|!ARGS:/^cymr/|!ARGS:_qf_Register_upload|!A
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][4] Transformation completed in 13 usec.
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][4] Executing operator "rx" with param "(< ?(?:(?:java|vb)?script|about|applet|activex|chrome) ?>|> ?< ?(img ?src|a ?href) ?= ?(ht|f)tps?:/|\" ?> ?<|\" ?[a-z]+ ?<.*>|> ?\"? ?(>|<)|< ?/?i?frame|\\%env)" against REQUEST_URI.
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][4] Operator completed in 30 usec.
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][4] Transformation completed in 13 usec.
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][4] Executing operator "rx" with param "(< ?(?:(?:java|vb)?script|about|applet|activex|chrome) ?>|> ?< ?(img ?src|a ?href) ?= ?(ht|f)tps?:/|\" ?> ?<|\" ?[a-z]+ ?<.*>|> ?\"? ?(>|<)|< ?/?i?frame|\\%env)" against ARGS_NAMES:userdata[].
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][4] Operator completed in 14 usec.
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][4] Transformation completed in 13 usec.
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][4] Executing operator "rx" with param "(< ?(?:(?:java|vb)?script|about|applet|activex|chrome) ?>|> ?< ?(img ?src|a ?href) ?= ?(ht|f)tps?:/|\" ?> ?<|\" ?[a-z]+ ?<.*>|> ?\"? ?(>|<)|< ?/?i?frame|\\%env)" against ARGS_NAMES:userdata[].
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][4] Operator completed in 13 usec.
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][4] Transformation completed in 13 usec.
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][4] Executing operator "rx" with param "(< ?(?:(?:java|vb)?script|about|applet|activex|chrome) ?>|> ?< ?(img ?src|a ?href) ?= ?(ht|f)tps?:/|\" ?> ?<|\" ?[a-z]+ ?<.*>|> ?\"? ?(>|<)|< ?/?i?frame|\\%env)" against ARGS_NAMES:submit.
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][4] Operator completed in 13 usec.
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][4] Rule returned 0.
[27/Apr/2011:02:28:25 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c35978][/test1.php][4] Recipe: Invoking rule 7f314b7f4580; [file "/etc/apache2/modsecurity.d/gotroot/10_asl_rules.conf"] [line "908"] [id "340158"] [rev "9"].


SECOND: $_POST name is userdat[] and mod-sec picks up <script>

Code: Select all

[27/Apr/2011:02:31:51 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c1a958][/test1.php][4] Recipe: Invoking rule 7f314d4b6de8; [file "/etc/apache2/modsecurity.d/gotroot/10_asl_rules.conf"] [line "904"].
[27/Apr/2011:02:31:51 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c1a958][/test1.php][5] Rule 7f314d4b6de8: SecRule "REQUEST_URI|ARGS|ARGS_NAMES|!ARGS:arg2|!ARGS:resumoDetalhe|!ARGS:Right_photo_1|!ARGS:/^K2ExtraField/|!ARGS:/submitcode/|!ARGS:beschrijving|!ARGS:custombannercode|!ARGS:bannercode|!ARGS:privatecapacity|!ARGS:diz|!ARGS:FormLayout|!ARGS:/^fck/|!ARGS:parent_name|!ARGS:/^code_tscript/|!ARGS:_qf_Group_next|!ARGS:project_company|!ARGS:categories_title|!ARGS:antwoord|!ARGS:project_company|!ARGS:signature|!ARGS:paepdc|!ARGS:tpl_source|!ARGS:teaser_js|!ARGS:/^autoDS/|!ARGS:FrmSide|!ARGS:mainKeywords|!ARGS:/VB_announce/|!ARGS:guardar|!ARGS:/serendipity/|!ARGS:omschrijving|!ARGS:resolution|!ARGS:newyddionc|!ARGS:bericht|!ARGS:property_copy|!ARGS:/^outpay/|!ARGS:bedrijfsprofiel|!ARGS:s_query|!ARGS:finish_survey|!ARGS:photolater|!ARGS:ticket_response|!ARGS:/element/|!ARGS:option[vbpclosedreason]|!ARGS:/introduction/|!ARGS:/contenido/|!ARGS:/sql/|!ARGS:query|!ARGS:c_features|!ARGS:/tekst/|!ARGS:embeddump|!ARGS:other_clubs|!ARGS:/^elm/|!ARGS:/^saes/|!ARGS:dlv_instructions|!ARGS:/^cymr/|!ARGS:_qf_
[27/Apr/2011:02:31:51 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c1a958][/test1.php][4] Expanded "REQUEST_URI|ARGS|ARGS_NAMES|!ARGS:arg2|!ARGS:resumoDetalhe|!ARGS:Right_photo_1|!ARGS:/^K2ExtraField/|!ARGS:/submitcode/|!ARGS:beschrijving|!ARGS:custombannercode|!ARGS:bannercode|!ARGS:privatecapacity|!ARGS:diz|!ARGS:FormLayout|!ARGS:/^fck/|!ARGS:parent_name|!ARGS:/^code_tscript/|!ARGS:_qf_Group_next|!ARGS:project_company|!ARGS:categories_title|!ARGS:antwoord|!ARGS:project_company|!ARGS:signature|!ARGS:paepdc|!ARGS:tpl_source|!ARGS:teaser_js|!ARGS:/^autoDS/|!ARGS:FrmSide|!ARGS:mainKeywords|!ARGS:/VB_announce/|!ARGS:guardar|!ARGS:/serendipity/|!ARGS:omschrijving|!ARGS:resolution|!ARGS:newyddionc|!ARGS:bericht|!ARGS:property_copy|!ARGS:/^outpay/|!ARGS:bedrijfsprofiel|!ARGS:s_query|!ARGS:finish_survey|!ARGS:photolater|!ARGS:ticket_response|!ARGS:/element/|!ARGS:option[vbpclosedreason]|!ARGS:/introduction/|!ARGS:/contenido/|!ARGS:/sql/|!ARGS:query|!ARGS:c_features|!ARGS:/tekst/|!ARGS:embeddump|!ARGS:other_clubs|!ARGS:/^elm/|!ARGS:/^saes/|!ARGS:dlv_instructions|!ARGS:/^cymr/|!ARGS:_qf_Register_upload|!A
[27/Apr/2011:02:31:51 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c1a958][/test1.php][4] Transformation completed in 14 usec.
[27/Apr/2011:02:31:51 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c1a958][/test1.php][4] Executing operator "rx" with param "(< ?(?:(?:java|vb)?script|about|applet|activex|chrome) ?>|> ?< ?(img ?src|a ?href) ?= ?(ht|f)tps?:/|\" ?> ?<|\" ?[a-z]+ ?<.*>|> ?\"? ?(>|<)|< ?/?i?frame|\\%env)" against REQUEST_URI.
[27/Apr/2011:02:31:51 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c1a958][/test1.php][4] Operator completed in 30 usec.
[27/Apr/2011:02:31:51 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c1a958][/test1.php][4] Transformation completed in 13 usec.
[27/Apr/2011:02:31:51 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c1a958][/test1.php][4] Executing operator "rx" with param "(< ?(?:(?:java|vb)?script|about|applet|activex|chrome) ?>|> ?< ?(img ?src|a ?href) ?= ?(ht|f)tps?:/|\" ?> ?<|\" ?[a-z]+ ?<.*>|> ?\"? ?(>|<)|< ?/?i?frame|\\%env)" against ARGS:userdat[].
[27/Apr/2011:02:31:51 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c1a958][/test1.php][4] Operator completed in 16 usec.
[27/Apr/2011:02:31:51 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c1a958][/test1.php][4] Rule returned 1.
[27/Apr/2011:02:31:51 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c1a958][/test1.php][1] Access denied with code 403 (phase 2). Pattern match "(< ?(?:(?:java|vb)?script|about|applet|activex|chrome) ?>|> ?< ?(img ?src|a ?href) ?= ?(ht|f)tps?:/|" ?> ?<|" ?[a-z]+ ?<.*>|> ?"? ?(>|<)|< ?/?i?frame|\%env)" at ARGS:userdat[]. [file "/etc/apache2/modsecurity.d/gotroot/10_asl_rules.conf"] [line "903"] [id "340147"] [rev "81"] [msg "Atomicorp.com - FREE UNSUPPORTED DELAYED FEED - WAF Rules: Generic XSS filter"] [data "53"] [severity "CRITICAL"]
[27/Apr/2011:02:31:51 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c1a958][/test1.php][4] Time #2: 215120
[27/Apr/2011:02:31:51 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c1a958][/test1.php][4] Initialising logging.
[27/Apr/2011:02:31:51 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c1a958][/test1.php][4] Starting phase LOGGING.
[27/Apr/2011:02:31:51 +0100] [192.168.1.65/sid#7f31528d6508][rid#7f3154c1a958][/test1.php][4] Audit log: Logging this transaction.

What should I do now?
Post Reply