store | blogs | forums | twitter | facebook | wiki | mailing lists | downloads | support portal
Atomic Secure Linux
It is currently Mon Apr 21, 2014 12:48 pm

» Feed - Atomicorp

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: mod_sec not scanning post payload
Unread postPosted: Tue Apr 19, 2011 7:03 am 
Offline
New Forum User
New Forum User

Joined: Tue Apr 19, 2011 6:49 am
Posts: 4
Location: nyc
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:
<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.

Top
 Profile  
 
 Post subject: Re: mod_sec not scanning post payload after session is start
Unread postPosted: Tue Apr 19, 2011 8:23 am 
Offline
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin

Joined: Wed Dec 31, 1969 8:00 pm
Posts: 7779
Location: earth
Id say the first thing to start with is how you built the module & what libraries it is linked against.


Top
 Profile  
 
 Post subject: Re: mod_sec not scanning post payload
Unread postPosted: Tue Apr 19, 2011 10:06 am 
Offline
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
User avatar

Joined: Thu Feb 07, 2008 7:49 pm
Posts: 3548
Location: Chantilly, VA
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.

_________________
Michael Shinn
Atomicorp - Security For Everyone

Co-Author of Troubleshooting Linux Firewalls.


Top
 Profile  
 
 Post subject: Re: mod_sec not scanning post payload
Unread postPosted: Tue Apr 19, 2011 11:09 am 
Offline
New Forum User
New Forum User

Joined: Tue Apr 19, 2011 6:49 am
Posts: 4
Location: nyc
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:
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.


Top
 Profile  
 
 Post subject: Re: mod_sec not scanning post payload
Unread postPosted: Tue Apr 19, 2011 11:59 am 
Offline
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin

Joined: Wed Dec 31, 1969 8:00 pm
Posts: 7779
Location: earth
That sounds like maybe your pcre settings, how did you build the module?


Top
 Profile  
 
 Post subject: Re: mod_sec not scanning post payload
Unread postPosted: Tue Apr 19, 2011 12:00 pm 
Offline
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
User avatar

Joined: Thu Feb 07, 2008 7:49 pm
Posts: 3548
Location: Chantilly, VA
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.

_________________
Michael Shinn
Atomicorp - Security For Everyone

Co-Author of Troubleshooting Linux Firewalls.


Top
 Profile  
 
 Post subject: Re: mod_sec not scanning post payload
Unread postPosted: Wed Apr 20, 2011 6:41 am 
Offline
New Forum User
New Forum User

Joined: Tue Apr 19, 2011 6:49 am
Posts: 4
Location: nyc
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.


Top
 Profile  
 
 Post subject: Re: mod_sec not scanning post payload
Unread postPosted: Wed Apr 20, 2011 9:18 am 
Offline
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin

Joined: Wed Dec 31, 1969 8:00 pm
Posts: 7779
Location: earth
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.


Top
 Profile  
 
 Post subject: Re: mod_sec not scanning post payload
Unread postPosted: Wed Apr 27, 2011 4:20 am 
Offline
New Forum User
New Forum User

Joined: Tue Apr 19, 2011 6:49 am
Posts: 4
Location: nyc
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:
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:
[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?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

» Feed - Atomicorp

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group