|
From: Ryan B. <RBa...@tr...> - 2014-01-31 15:13:11
|
Jose, ModSecurity uses PCRE with its @rx operator - https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-rx Yes, Snort and Suricata IDS also have pcre actions/operators however the format of specifying the actual expression is slightly different. They use the syntax - /REGEX_PATTERN/[optional pcre compilation flag(s)]. The PCRE compilation flags in the example you show below are [si] and mean - http://www.pcre.org/pcre.txt "s" flag - PCRE_DOTALL If this bit is set, a dot metacharacter in the pattern matches a char- acter of any value, including one that indicates a newline. However, it only ever matches one character, even if newlines are coded as CRLF. Without this option, a dot does not match when the current position is at a newline. This option is equivalent to Perl's /s option, and it can be changed within a pattern by a (?s) option setting. A negative class such as [^a] always matches newline characters, independent of the set- ting of this option. "i" flag - PCRE_CASELESS If this bit is set, letters in the pattern match both upper and lower case letters. It is equivalent to Perl's /i option, and it can be changed within a pattern by a (?i) option setting. In UTF-8 mode, PCRE always understands the concept of case for characters whose values are less than 128, so caseless matching is always possible. For characters with higher values, the concept of case is supported if PCRE is com- piled with Unicode property support, but not otherwise. If you want to use caseless matching for characters 128 and above, you must ensure that PCRE is compiled with Unicode property support as well as with UTF-8 support. In ModSecurity, the PCRE expression is defined within the OPERATOR location of the SecRule between double quotes - "@rx REGEX_PATTERN". You can add similar optional compilation flags directly to the beginning of the expression. Example, to add PCRE_CASELESS matching using "@rx (?I)REGEX_PATTERN". Now, for your specific question below about that Snort/Suricata regex. ModSecurity already uses the PCRE_DOTALL (s) flag when compiling the REGEX_PATTERN so you don't need to convert that. You would need to apply the PCRE_CASELESS flag (I) however. Something like this - SecRule RESPONSE_BODY "@rx (?I)<OBJECT\s+[^>]*classid\s*=\s*[\x22\x27]?\s*clsid\s*\x3a\s*\x7B?\s*E2883E8F-472F-4fb0-9522-AC9BF37916A7.+offer-(ineligible|preinstalled|declined|accepted)" "phase:response,t:none,id:2010665,log,deny,msg:'ET ACTIVEX Possible NOS Microsystems Adobe Reader/Acrobat getPlus Get_atlcomHelper ActiveX Control Multiple Stack Overflows Remote Code Execution Attempt'" Ryan Barnett Lead Security Researcher, SpiderLabs Trustwave | SMART SECURITY ON DEMAND www.trustwave.com<http://www.trustwave.com/> From: Jose Pablo Valcárcel Lázaro <pab...@gm...<mailto:pab...@gm...>> Reply-To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>> Date: Wednesday, January 29, 2014 5:38 AM To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>> Subject: Re: [mod-security-users] Question about pcre and how to convert into mod_security rules How is it possible that suricata and mod_security use different values to evaluate insensitive expressions? Within mod_security equivalent pcre for insensitive should be (as we can see on rx directive): "@rx (?i)nikto" while in suricata should be /nikto/i So if both are using pcre software and libraries, how is it possible that insensitive searchs perform in different way for each software? If I want to parse a pcre to match a vulnerability, not exploit, should I parse all the pcre into normal content and finally convert it again into pcre for mod_security? Which pcre does modsecurity uses? Is there any manual reference? Kind regards, 2014-01-29 Jose Pablo Valcárcel Lázaro <pab...@gm...<mailto:pab...@gm...>> Good morning. I was wondering if someone could advice me how to convert regular expression as /<OBJECT\s+[^>]*classid\s*=\s*[\x22\x27]?\s*clsid\s*\x3a\s*\x7B?\s*E2883E8F-472F-4fb0-9522-AC9BF37916A7.+offer-(ineligible|preinstalled|declined|accepted)/si into mod_security compatible regular expression. Looking at the exploit exploit<http://www.exploit-db.com/exploits/11172/> vulnerability string is <objectid=TestObjclassid="CLSID:{E2883E8F-472F-4fb0-9522-AC9BF37916A7}" So I understand that using the pcre you should be able to stop any variation of the exploit? Kind regards, ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. |
