[Owasp-modsecurity-core-rule-set] More Squirrelmail Denials

Arthur Dent misc.lists at blueyonder.co.uk
Wed Jan 13 13:17:35 EST 2010


On Wed, 2010-01-13 at 10:54 -0500, Ryan Barnett wrote:
> On Wednesday 13 January 2010 07:10:55 am Arthur Dent wrote:
> 
> > On Mon, 2010-01-11 at 22:22 +0000, Arthur Dent wrote:
> 
> > > On Wed, 2010-01-06 at 09:57 +0000, Arthur Dent wrote:

> Hey Mark,
> 
> Sorry for the delay. 
> 
> There is always a delicate balance between false negatives and false
> positives with 
> 
> developing these rules :( If you look in the CHANGES file for the
> 2.0.2/2.0.3 updates, 
> 
> we were addressing false negative/bypass issues that were reported to
> us. We chose to 
> 
> become a bit more aggressive in our detection. While our updates
> helped to address those 
> 
> issues, they result in a higher false positive rate. The main issue
> here is when we are 
> 
> applying these negative security regexs to an unparsed variable such
> as REQUEST_URI_RAW or 
> 
> REQUEST_BODY. This data is essentially a blob of text and includes the
> = character for 
> 
> separating the parameter name from the parameter payload. This results
> in a higher number 
> 
> of matches. We are going to keep on tweaking these rules however as I
> am sure we do better.
> 
> Now, for your specific issue, what you want to do is to add some
> exceptions to the 48 local exceptions file. Take a look at some of the
> examples in the file. What you want to do is to create rules that will
> inspect the saved TX variable data from these PHPIDS rules that
> triggered. If these exact matches occur, then you want to remove them
> and adjust the anomaly score. Looks like there are 4 different phpids
> rule matches -
> 
> phpids-18
> 
> phpids-1
> 
> phpids-30
> 
> phpids-3
> 
> I tested your payloads with my current (newer) phpids filter file and
> only the phpids-18 and phpids-30 rules matched. I believe that the
> other two matches will be fixed with the updated phpids filter in CRS
> 2.0.5.
> 
> Here are some examples (untested) based on the error_log snippets you
> showed above for phpids-18 and phpids-30 matches -
> 
> SecRule TX:'/PHPIDS-18-(.*)REQUEST_URI_RAW/' "@contains &sort="
> "chain,phase:2,t:none,nolog,pass"
> 
> SecRule MATCHED_VAR_NAME "TX\:(.*)" "capture,t:none,setvar:!
> tx.%{tx.1},setvar:tx.anomaly_score=-4"
> 
> SecRule "TX:PHPIDS-30-WEB_ATTACK/INJECTION-2-Detects common XSS
> concatenation patterns 1/2-ARGS_NAMES:smaction[save][1]"
> "@contains ][" "chain,phase:2,t:none,nolog,pass"
> 
> SecRule MATCHED_VAR_NAME "TX\:(.*)" "capture,t:none,setvar:!
> tx.%{tx.1},setvar:tx.anomaly_score=-4"
> 
> Let me know if these help.
> 
> Ryan

Hi Ryan,

Many thanks for this. I wish I understood better how the CRS works, but
I'm afraid I don't. This means that I am at a bit of a loss to know what
to do when Apache reports a syntax error in your rules... Sorry...

# service httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd: Syntax error on line 65 of /etc/httpd/modsecurity.d/base_rules/modsecurity_crs_48_local_exceptions.conf:
Error creating rule: Unexpected character at position 51: TX:PHPIDS-30-WEB_ATTACK/INJECTION-2-Detects common XSS concatenation patterns 1/2-ARGS_NAMES:smaction[save][1]
                                                           [FAILED]

I do appreciate your help with this. Thanks.

Mark

p.s.
When is CRS 2.0.5 coming out?






More information about the Owasp-modsecurity-core-rule-set mailing list