[Snort-sigs] Proposed change to the Virus Rule

Matthew Jonkman matt at ...2436...
Sat Jul 3 09:13:05 EDT 2004


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






More information about the Snort-sigs mailing list