Re: [Snort-sigs] False Positive on SMTP HELO Overflow

From: Erik Alexander Løkken <eal(at)mnemonic.no>
Date: Tue Apr 29 2003 - 20:10:31 EDT

On 28.04 15:10, Ron Shuck wrote:
> Hi All,

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@.........
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

---

This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven.
http://thinkgeek.com/sf

---

Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs Received on Tue Apr 29 20:56:47 2003