[Snort-sigs] smtp rules + quicktime

Aaron Shelmire shelmire at ...3369...
Tue Jan 27 19:58:06 EST 2009

I have some modifications I've made to many of the supplied rules that
I'd like to share. Most of these are in SMTP.rules, (and older) but
still part of the bundle.
Any feedback is appreciated.


sid 3656
    returns false positives. Revision 4 of the rule will alert whenever
a packet on port 25 includes something like

"mail with more than.......246.......characters of text before the next
new line break, when it really shouldn't be alerting on this and only on
the mail keyword while it is being used for the SMTP protocol...but
really all the way out to 246 characters"

For a modification I propose the following...

alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"SMTP MAIL overflow
attempt"; flow:established,to_server; content:"MAIL"; nocase;
isdataat:246,relative; content:"|3A|";
pcre:"/^\s*MAIL\s+\.*?\s*\x3A\s*[^\n]{246}/smi"; metadata:service smtp;
reference:bugtraq,11238; reference:cve,2004-1546;
classtype:attempted-user; sid:3656; rev:5;)

This modification includes the MAIL directive, w/ content at 246
characters away, and must match the ":" character before entering the
regex. This loosely matches the attempted buffer overflow.

The regex looks for the MAIL directive,
some sort of white space characters,
non-greedy match some non-white-space-characters,
some optional whitespace characters,
Matches the ":" character,
then optional white space characters,
Finally attempts to match 246 characters worth of data for the overflow.

This will reduce the number of false-positives encountered with this rule.

sid 2741

The quicktime protocol allows for more than one directive to be placed
on a line. Therefore Revision 7 of this rule will alert whenever someone
has strung a lot of directives together onto one line. By looking for
another ":" on the line, these false positives can be removed

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"EXPLOIT Apple
Quicktime TCP RTSP sdp type buffer overflow attempt";
flow:to_client,established; content:"Content-Type|3A|"; nocase;
content:!"|0A|"; within:256; content:!"|3A|"; within:256;
isdataat:256,relative; pcre:"/^\s*Content/i"; metadata:policy
balanced-ips drop, policy security-ips drop, service rtsp;
reference:bugtraq,26549; reference:cve,2007-6166;
classtype:attempted-user; sid:2741; rev:8;)

sid 664
Revision 16 of this rule has false negatives that occur whenever the
"rcpt" and "to" portions are spread apart by more than a single
whitespace character.

alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"SMTP RCPT TO
decode attempt"; flow:to_server,established; content:"rcpt"; nocase;
content: "to"; nocase; content:"|3A|"; content:"decode"; nocase;
pcre:"/^rcpt\s+to\s*\x3a\s*decode/smi"; metadata:service smtp;
reference:arachnids,121; reference:bugtraq,2308;
reference:cve,1999-0203; classtype:attempted-admin; sid:664; rev:17;)
sid 654

Revision 16 of this rule suffers from the same faults as sid 664.

alert tcp any any -> $SMTP_SERVERS 25 (msg:"SMTP RCPT TO overflow";
flow:to_server,established; content:"rcpt"; nocase; content:" to";
nocase; content:"|3A|"; isdataat:300,relative;
pcre:"/^RCPT\s+TO\s*\x3a\s*[^\n]{300}/ism"; metadata:service smtp;
reference:bugtraq,2283; reference:bugtraq,9696; reference:cve,2001-0260;
classtype:attempted-admin; sid:2000654; rev:17;)
sid 2590

Revision 5 of this rule suffers from the same faults as sid 664 and 654,
but also falsely alerts whenever the two words "mail from" occur in an
email packet (which is often).

alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"SMTP MAIL FROM
overflow attempt"; flow:to_server,established; content:"MAIL";
content:"FROM"; nocase; isdataat:260; content:!"|0A|"; within:256;
pcre:"/^MAIL\s+FROM\s*\x3a[^\n]{256}/smi"; metadata:service smtp;
reference:bugtraq,10290; reference:bugtraq,7506;
reference:cve,2004-0399; reference:url,www.guninski.com/exim1.html;
classtype:attempted-admin; sid:2590; rev:2;)
sid 2183

Revision 7 of this rule creates false positives on DKI email. In this
sort of email it seems  the "content-transfer-encoding" string is very
regularly included on the same line as many other directives, creating a
situation in which more than 100 characters are present before a new
line. It also creates a false-negative situation when there is a space
between content-transfer-encoding and the ":" character.

alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"SMTP
Content-Transfer-Encoding overflow attempt"; flow:to_server,established;
content:"Content-Transfer-Encoding"; content:|3A|"; nocase;
isdataat:100,relative; content:!"|0A|"; within:100; content:!"|3A|";
within:100; metadata:service smtp; reference:cve,2003-0161;
classtype:attempted-admin; sid:2183; rev:8;)
sid 3462

The original rule creates false-positives on DKI email  A LOT. DKI
typically has the "content-encoding" string along with a lot of other
directive strings. By looking for another  ":" before the end of the
line  you can be sure to miss this case.
This rule also misses (false-negative) attempts which split the
"content-encoding" string with the ":" by white space (you can even
insert a newline if you wish).

alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"SMTP
Content-Encoding overflow attempt"; flow:to_server,established;
content:"Content-Encoding"; content:"|3A|"; content:!"|3A|"; within:300;
nocase; pcre:"/Content-Encoding\s*\x3A[^\r\n]{300,}/i"; metadata:service
smtp; reference:bugtraq,7419; reference:cve,2003-0113;
classtype:attempted-admin; sid:3462; rev:4;)

sid 3461
The original 3461 suffers from the same issues sid 3462 does.

alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"SMTP Content-Type
overflow attempt"; flow:to_server,established; content:"Content-Type";
content:"|3A|"; content:!"|3A|"; within:300; nocase;
pcre:"/Content-Type\s*\x3A[^\r\n]{300,}/i"; metadata:service smtp;
reference:bugtraq,7419; reference:cve,2003-0113;
classtype:attempted-admin; sid:3461; rev:4;)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20090127/934f58a7/attachment.html>

More information about the Snort-sigs mailing list