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


From: Jose Pablo Valcárcel Lázaro <pablo.valcarcel1980@gmail.com>
Reply-To: "mod-security-users@lists.sourceforge.net" <mod-security-users@lists.sourceforge.net>
Date: Wednesday, January 29, 2014 5:38 AM
To: "mod-security-users@lists.sourceforge.net" <mod-security-users@lists.sourceforge.net>
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 <pablo.valcarcel1980@gmail.com>
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 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.