Re: [Snort-sigs] PCRE problem with some security policy rules

["Joel Esler \(jesler\) via Snort-users" <snort-users () lists snort org>]

Yup.  The second one, I think I wrote. It should be off by default, and probably hasn't been regression tested in 
awhile, as that threat is dead.  Rule can probably be retired, despite the fact that it's terrible. 

As far as the first one, I've sent this thread over to the analyst team.

--
Joel Esler
Manager, Communities Division
Cisco Talos Intelligence Group
http://www.talosintelligence.com

> On Aug 2, 2019, at 12:59 PM, Dave Killion <dave.killion () gmail com> wrote:
>
> I'm going to be a bit indelicate and say that first one is without a doubt the worst PCRE signature I've ever seen.
>
> These two examples you have provided have serious issues with un-escaped characters - specifically brackets, parens, 
> quotes, and especially the question marks.
>
> The un-escaped question mark is why the second example fails.  A question mark is used to modify the previous match 
> to make it optional, and its literally the first character of the pattern, so there's nothing to modify.  
>
> It looks more like they were trying to anchor against the question mark delimiter of a URL (another bad idea, because 
> you can re-order or insert parameters in any order you like) and forgot that you must escape literal question marks.
>
> It's also possible that the back-slash to escape these characters was somehow stripped out during a file conversion 
> or similar - I don't see these signatures as ever working as-is.
>
> -Dave
>
> On Thu, Aug 1, 2019 at 6:33 PM Joel Esler (jesler) via Snort-sigs <snort-sigs () lists snort org <mailto:snort-sigs 
> () lists snort org>> wrote:
> Adding in snort-sigs, where signatures questions should live.  
>
> We’ll have a look here. Thanks
>
> Sent from my  iPhone
>
> > On Aug 1, 2019, at 14:01, clemence.roulin--- via Snort-users <snort-users () lists snort org <mailto:snort-users () 
> > lists snort org>> wrote:
> >
> > 
> > Hello,
> > I'm using Snort 2.9.13 on Centos7 with the registered Talos rules. With the default rules, Snort runs just fine but 
> > didn't raise many alerts so we decided to switch to the security-ips policy. When using the rules from this policy, 
> > Snort fails to start, displaying errors always linked to PCRE.
> > Here is an example of what Snort says (shortened):
> >  
> >  
> > snort -d -l /var/log/snort/ -c /etc/snort/snort.conf -k none
> > Running in IDS mode
> >  
> > --== Initializing Snort ==--
> > Initializing Output Plugins!
> > Initializing Preprocessors!
> > Initializing Plug-ins!
> > Parsing Rules file "/etc/snort/snort.conf"
> > ...
> > ...
> > ...
> > Reputation config:
> > WARNING: Can't find any whitelist/blacklist entries. Reputation Preprocessor disabled.
> >  
> > +++++++++++++++++++++++++++++++++++++++++++++++++++
> > Initializing rule chains...
> > ERROR: /etc/snort/rules/exploit-kit.rules(130) : pcre compile of "?java=[0-9]{2,6}$" failed at offset 0 : nothing 
> > to repeat
> > Fatal Error, Quitting..
> >  
> >  
> >  
> > The rule in question, from exploit-kit.rules :
> > alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"BROWSER-WEBKIT WebKit button column memory corruption 
> > attempt"; flow:to_ client,established; file_data; content:"-webkit-column-span"; fast_pattern; nocase; 
> > content:"document.documentElement.offsetTop"; d istance:0; 
> > pcre:"/(functions+(?P<function>[a-z0-9_-]+)()s*{.*?(?P<div>[a-z0-9_-]+)s*=s*document.createElement('div')x3b.*?(?P=div).
> >  
> > style['-webkit-column-span']s*=s*'all'x3b.*?document.getElementById("(?P<button>[a-z0-9_-]+)").appendChild((?P=div))x3b.*?document.
> >  
> > documentElement.offsetTopx3b.*?<body[^>]*?onloads*=s*"(?P=function)()"[^>]*?>.*?<button[^>]*?ids*=s*"(?P=button)"[^>]*?styles*=s*"[
> >  
> > ^"]*?-webkit-column-widthx3a1px"[^>]*?>)|(<style>.*?{s*-webkit-column-spanx3as*allx3b.*?functions+(?P<function2>[a-z0-9_-]+)()s*{.*
> >  
> > ?(?P<div2>[a-z0-9_-]+)*s*=s*document.createElement('div')x3b.*?(?P<button2>[a-z0-9_-]+)s*=s*document.createElement('button')x3b.*?d
> >  
> > ocument.documentElement.appendChild((?P=button2))x3b.*?(?P=button2).appendChild((?P=div2)).*?document.documentElement.offsetTopx3b)
> >  /smi"; metadata:policy max-detect-ips drop, policy security-ips drop, service http; reference:bugtraq,54680; 
> > reference:cve,2012-152 0; classtype:attempted-user; sid:23805; rev:8;)
> >  
> > I had PCRE 8.32 when it started, so updated it to PCRE 8.43 which seemed to be the most recent version, but the 
> > errors remain. I have put it through pcretest, and have the same error so the problem definitely comes from the 
> > PCRE pattern and not any other part of the rules. I have downloaded the rules directly from the snort.org 
> > <http://snort.org/> website, and tried to download it again to check if it wasn't due to the file being corrupted 
> > while downloaded, but it's not.
> > I tried to comment out this rule, but many more have similar problems, for example this other rule where the PCRE 
> > parser fails, also from exploit-kit.rules :
> > alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"EXPLOIT-KIT Whitehole exploit kit malicious jar download 
> > attempt"; flow: to_server,established; content:"?java="; fast_pattern:only; http_uri; pcre:"/?java=[0-9]{2,6}$/U"; 
> > flowbits:set,file.exploit_kit.ja r; metadata:impact_flag red, policy balanced-ips drop, policy max-detect-ips drop, 
> > policy security-ips drop, service http; referenc e:cve,2011-3544; reference:cve,2012-1723; reference:cve,2012-4681; 
> > reference:cve,2012-5076; reference:cve,2013-0422; reference:cve, 2013-1493; reference:cve,2013-2423; 
> > reference:url,malware.dontneedcoffee.com/2013/02/briefly-wave-whitehole-exploit-kit-hello.html 
> > <http://malware.dontneedcoffee.com/2013/02/briefly-wave-whitehole-exploit-kit-hello.html>; 
> > classtype:trojan-activity; sid:25804; rev:5;
> > Some rules also work fine while containing PCRE patterns.
> >  
> > Are the weird rules basing their PCRE patterns on another version of PCRE ? Or is the problem somewhere else ?
> > Thank you
> >
> >
> > _______________________________________________
> > Snort-users mailing list
> > Snort-users () lists snort org <mailto:Snort-users () lists snort org>
> > Go to this URL to change user options or unsubscribe:
> > https://lists.snort.org/mailman/listinfo/snort-users <https://lists.snort.org/mailman/listinfo/snort-users>
> >
> >    To unsubscribe, send an email to:
> >    snort-users-leave () lists snort org <mailto:snort-users-leave () lists snort org>
> >
> > Please visit http://blog.snort.org <http://blog.snort.org/> to stay current on all the latest Snort news!
> >
> > Please follow these rules: https://snort.org/faq/what-is-the-mailing-list-etiquette 
> > <https://snort.org/faq/what-is-the-mailing-list-etiquette>
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs () lists snort org <mailto:Snort-sigs () lists snort org>
> https://lists.snort.org/mailman/listinfo/snort-sigs <https://lists.snort.org/mailman/listinfo/snort-sigs>
>
> Please visit http://blog.snort.org <http://blog.snort.org/> for the latest news about Snort!
>
> Please follow these rules: https://snort.org/faq/what-is-the-mailing-list-etiquette 
> <https://snort.org/faq/what-is-the-mailing-list-etiquette>
>
> Visit the Snort.org to subscribe to the official Snort ruleset, make sure to stay up to date to catch the most <a 
> href=" https://snort.org/downloads/#rule-downloads <https://snort.org/downloads/#rule-downloads>">emerging 
> threats</a>!
>
>
> -- 
> Dave Killion

Attachment: smime.p7s
Description:

_______________________________________________
Snort-users mailing list
Snort-users () lists snort org
Go to this URL to change user options or unsubscribe:
https://lists.snort.org/mailman/listinfo/snort-users

        To unsubscribe, send an email to:
        snort-users-leave () lists snort org

Please visit http://blog.snort.org to stay current on all the latest Snort news!

Please follow these rules: https://snort.org/faq/what-is-the-mailing-list-etiquette