[Snort-sigs] [Fwd: Proposed change to the Virus Rule]

nnposter at ...592... nnposter at ...592...
Tue Jul 6 17:34:08 EDT 2004


From: "Matthew Jonkman" <matt at ...2436...>
> Lots of rule changes got incorporated today, thanks Brian. Any idea when 
> an updated tarball will be available for the changes you've made?
> 
> Side note, would it be possible to have the tarballs updated from cvs by 
> a cron job? CVS is a pain for scripted sensor managers.
> 
> On the post I made last week (below) I'm more concerned that there's a 
> pcre issue in snort. Several people have responded off list and we've 
> not got an answer yet. Should I shoot this over to snort-devel?

I cannot reproduce your results. I have repackaged your packet snippet
into a full new packet. It does not trigger modified[1] 721.7 on my test
system[2]. I have then changed the file name extension to ".dot" and the 
rule did match.

[1] converted into UDP to remove any state issues
[2] snort 2.1.2, built from source

Cheers,
nnposter


> -------- Original Message --------
> Subject: Proposed change to the Virus Rule
> Date: Sat, 03 Jul 2004 11:12:22 -0500
> From: Matthew Jonkman <matt at ...2436...>
> To: snort-sigs mailinglist <snort-sigs at lists.sourceforge.net>
> 
> I'd like to propose a change to the virus attachment rule. One change I
> have made, the other I'm not sure how to handle.
> 
> First, the rule is supposed to hit on .xls files. I'm not aware of any
> current threats in this file type, the false positives are making the
> rule useless.
> 
> The following rule drops the xls match:
> 
> alert tcp $HOME_NET any -> $EXTERNAL_NET 25 (msg:"VIRUS OUTBOUND bad
> file attachment"; flow:to_server,established;
> content:"Content-Disposition|3A|"; nocase;
> pcre:"/filename\s*=\s*.*?\.(?=[abcdehijlmnoprsvwx])(a(d[ep]|s[dfx])|c([ho]m|li|md|pp)|d(iz|ll|ot)|e(m[fl]|xe)|h(lp|sq|ta)|jse?|m(d[abew]|s[ip])|p(p[st]|if|[lm]|ot)|r(eg|tf)|s(cr|[hy]s|wf)|v(b[es]?|cf|xd)|w(m[dfsz]|p[dmsz]|s[cfh])|xl[tw]|bat|ini|lnk|nws|ocx)[\x27\x22\n\r\s]/iR"; 
> 
> classtype:suspicious-filename-detect; sid:721; rev:7;)
> 
> The second issue with the rule is that it *does* match on doc
> attachments, which we certainly don't want. It's not supposed to, but it
> is, reliably and consistently. Here's an example:
> 
> 3b0 : 2D 2D 2D 2D 2D 2D 5F 3D 5F 4E 65 78 74 50 61 72   ------_=_NextPar
> 3c0 : 74 5F 30 30 31 5F 30 31 43 34 36 31 30 46 2E 36   t_001_01C4610F.6
> 3d0 : 39 39 33 33 33 46 38 0D 0A 43 6F 6E 74 65 6E 74   99333F8..Content
> 3e0 : 2D 54 79 70 65 3A 20 61 70 70 6C 69 63 61 74 69   -Type: applicati
> 3f0 : 6F 6E 2F 6D 73 77 6F 72 64 3B 0D 0A 09 6E 61 6D   on/msword;...nam
> 400 : 65 3D 22 41 49 43 20 4D 6F 6E 74 68 6C 79 20 43   e="XXX Monthly C
> 410 : 50 45 20 69 6E 76 65 6E 74 6F 72 79 30 37 30 33   PE inventory0703
> 420 : 30 34 2E 64 6F 63 22 0D 0A 43 6F 6E 74 65 6E 74   04.doc"..Content
> 430 : 2D 54 72 61 6E 73 66 65 72 2D 45 6E 63 6F 64 69   -Transfer-Encodi
> 440 : 6E 67 3A 20 62 61 73 65 36 34 0D 0A 43 6F 6E 74   ng: base64..Cont
> 450 : 65 6E 74 2D 44 65 73 63 72 69 70 74 69 6F 6E 3A   ent-Description:
> 460 : 20 41 49 43 20 4D 6F 6E 74 68 6C 79 20 43 50 45    XXX Monthly CPE
> 470 : 20 69 6E 76 65 6E 74 6F 72 79 30 37 30 33 30 34    inventory070304
> 480 : 2E 64 6F 63 0D 0A 43 6F 6E 74 65 6E 74 2D 44 69   .doc..Content-Di
> 490 : 73 70 6F 73 69 74 69 6F 6E 3A 20 61 74 74 61 63   sposition: attac
> 4a0 : 68 6D 65 6E 74 3B 0D 0A 09 66 69 6C 65 6E 61 6D   hment;...filenam
> 4b0 : 65 3D 22 41 49 43 20 4D 6F 6E 74 68 6C 79 20 43   e="XXX Monthly C
> 4c0 : 50 45 20 69 6E 76 65 6E 74 6F 72 79 30 37 30 33   PE inventory0703
> 4d0 : 30 34 2E 64 6F 63 22 0D 0A 0D 0A 30 4D 38 52 34   04.doc"....0M8R4
> 4e0 : 4B 47 78 47 75 45 41 41 41 41 41 41 41 41 41 41   KGxGuEAAAAAAAAAA
> 4f0 : 41 41 41 41 41 41 41 41 41 41 41 50 67 41 44 41   AAAAAAAAAAAPgADA
> 500 : 50 37 2F 43 51 41 47 41 41 41 41 41 41 41 41 41   P7/CQAGAAAAAAAAA
> 510 : 41 41 41 41 41 41 43 41 41 41 41 74 51 41 41 41   AAAAAACAAAAtQAAA
> 
> 
> It's strange that this hits, but if you take the pcre expression and
> evaluate it outside of snort it does not match. Could there be a bug in
> how snort is using pcre, or maybe a subtle difference?
> 
> This is the code I was using to evaluate the pcre:
> 
> ------------------
> 
> #!/usr/bin/php
> <?php
> $hdh = "filename=\"XXX Monthly CPE inventory070304.doc\"";
> print "\nString being checked:\n";
> print "$hdh\n";
> if ( preg_match(
> "/filename\s*=\s*.*?\.(?=[abcdehijlmnoprsvwx])(a(d[ep]|s[dfx])|c([ho]m|li|md|pp)|d(iz|ll|ot)|e(m[fl]|xe)|h(lp|sq|ta)|jse?|
> m(d[abew]|s[ip])|p(p[st]|if|[lm]|ot)|r(eg|tf)|s(cr|[hy]s|wf)|v(b[es]?|cf|xd)|w(m[dfsz]|p[dmsz]|s[cfh])|xl[tw]|bat|ini|lnk|nws|ocx)[\x27\x22
> \n\r\s]/i",$hdh,$array )) {
> print "\n It matches! \n";
> }
> else {
> print "\n No match..\n";
> }
> ?>
> 
> --------------------
> 
> (That pcre expression is the modified one above)
> 
> So, has anyone any experience with pcre that would suggest that it'll
> evaluate an expression differently in different situations, such as
> being called from php and from what's compiled into snort?
> 
> If there is a bug, is there a simple argument to add to this pcre
> that'll exclude the .doc for now, but not affect the other extensions
> matching?
> 
> Thanks for any advice here.
> 
> Matt
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> 
> 




More information about the Snort-sigs mailing list