[Snort-sigs] False Positive on SMTP HELO Overflow

Erik Alexander Løkken eal at ...835...
Tue Apr 29 17:11:31 EDT 2003


On 28.04 15:10, Ron Shuck wrote:
> Hi All,
> 
> I have been getting a lot of false positives on this SID if the connect
> terminates. What would be bad about adding a dsize value? Can't be an
> overflow if the payload isn't a least 500. I have added a "dsize: >499;"
> to my rule.
> 

Are you sure the connect terminates?

We've been experienced a lot of false positives related to this rule
after upgrading to Snort 2.0. But there does not seem to be anything
wrong with the rule itself. The problem actually seems to be within 
one of the snort preprocessors. After debugging this issue a little bit
closer it actually seems to be the stream preprocessor that is causing
the problem. Since this seems to be a bug within some of the code in 
snort we will follow up on this issue on the snort-devel list. I'm 
not able to do that before tomorrow....(have to get some sleep, it's 
late in Norway:). 

But since others may experience some of the same problems I would like 
to fill in on some of our experiences.

We're running several Snort sensors and some of them is reporting false 
positives that seems to be related to bugs within the snort code and not 
the signatures. One of our discoverings so far is that some packets seems
to be modified somewhere inside snort before it is processed by the 
rulebase. We've not been able to isolate the issue where this actually 
happens yet, but so far everything seems to point to the stream preprocessor.
We have several sensors (machines) that is able to see the same traffic, so 
we've been able to do some testing to isolate the problem. We've been
running one machine with snort and one with tcpdump to verifiy the traffic
that snort reports. 

What we see is that some packets that is logged by Snort is actually modified.
The reason we discovered this is that after the 2.0 upgrade we suddenly 
received a lot of messages regarding outgoing HELO overflows from some
mail servers. After snooping the packages at the mailserever we where not
able to see that the packets logged by snort was actually sent from 
the mail-server. To verify that the Snort sensor did see that packets reported
we used tcpdump both on the snort sensor itself and on a machine that 
collects the same traffic. The packet logs from the tcpdump does not
contain the same packets that snort logs. 

Here is the packets (anonymous off course:) :
Packet logged by snort:
=======================
   
$ tcpdump -r helo-snort.log -vvv -X -x -s 0 -n port 40227 and host SERVER
16:26:35.361570 CLIENT.40227 > SERVER.25: P [bad tcp cksum a237!] 3059831023:3059831032(9) ack 2672294989
win 24840 [tos 0x10]  (ttl 240, id 0, len 49, bad cksum 0!)
0x0000   4510 0031 0000 0000 f006 0000 *CLI ENT*        E..1............
0x0010   *SER VER* 9d23 0019 b661 50ef 9f47 fc4d        .....#...aP..G.M
0x0020   5018 6108 0000 0000 4845 4c4f 20** ****        P.a.....HELO.abc
0x0030   **                                             d 
   
Packet logged by tcpdump:
=========================
   
$ tcpdump -r helo-tcpdump-snort.log -vvv -X -x -s 0 -n port 40227 and host CLIENT
16:26:35.134816 CLIENT.40227 > SERVER.25: P [tcp sum ok] 1:18(17) ack 38 win 9660 (DF) (ttl 255, id 44122,
len 57)
0x0000   4500 0039 ac5a 4000 ff06 90d7 *CLI ENT*        E..9.Z at ...1488...
0x0010   *SER VER* 9d23 0019 9f47 e734 b661 5085        .....#...G.4.aP.
0x0020   5018 25bc 7b0b 0000 4845 4c4f 20** ****        P.%.{...HELO.abc
0x0030   **** **** **** **0d 0a                         defghij..

Both of these packets is supposed to be the same one. The first one is 
logged by snort in binary mode. As you can see it is not the same packet
that is actually sent from the mail-server. The packetdumps shown above 
is both from the same machine during the same period of time. 

Since we also have verified this on other machines and on the actual mail-server
we are certain that the problem lies within snort. The interesting things
about the packet is that the one logged by snort (which actually never was 
logged on the network), contains some modifications; the type of service 
bit is set, it seems like ack/seq numbers are switched?, and the end of the 
package is missing. Since the signature is waiting for the "|0a|", which 
is missing in the packet logged by snort, the signatures fire. The signature
actually do what it is supposed to do in this case. But snort does not 
do what it is supposed to do....We've also ran snort without any preprocessors
at all and with only this signatures = 0 false positives.

We are running Snort with the -b -L -o and -D........the config file
contain logging to syslog......and the following preprocessors;

preprocessor frag2: ttl_limit 0, memcap 33554432, timeout 240, detect_state_problems
preprocessor stream4: memcap 536870912, ttl_limit 0, detect_scans, disable_evasion_alerts, log_flushed_streams
preprocessor stream4_reassemble: both, ports all
preprocessor http_decode: 80 3128 8080 8000 unicode iis_alt_unicode double_encode iis_flip_slash full_whitespace
preprocessor rpc_decode: 111 32771
preprocessor telnet_decode

As I metioned above we will follow up on this on the snort-devel list tomorrow.
I'm not sure if this information helps anyone, but we do not believe that this 
signature should cause a large amount of false positives if there are nothing 
wrong with the packages. In this case we believe that it is something wrong
with the packages and that is caused by snort. The errors does not occur
if you run the signature without the stream processor (off course you would have 
to make modifications related to the flow options). 

> Any thoughts?

the signature seems to be correct... I would not change it if I was not 
certain that it is causing false errors in the environment I where
using it. 


/erik

> 
> alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"SMTP HELO overflow
> attempt"; flow:to_server,established; content:"HELO "; dsize: >499;
> offset:0; depth:5; content:!"|0a|"; within:500;
> reference:cve,CVE-2000-0042; reference:nessus,10324;
> classtype:attempted-admin; sid:1549; rev:9;)
> 
> 
> Thanks,
> 
> 
> Ron Shuck, CISSP, GCIA - Managing Consultant 
> Buchanan Associates - A Technology Company in the People Business 
> http://www.buchanan.com 
> http://www.isc2.org
> http://www.giac.org
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> 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