[Snort-sigs] False Positives with SIDs 2505 and 2506?

Chris Keladis Chris.Keladis at ...2461...
Mon May 10 10:21:06 EDT 2004

At 08:41 AM 4/05/2004 -0400, Gary_Portnoy at ...2451... wrote:

Hi Gary,

>I just turned those two on last night, and saw a ton of false positives.
>We have a fair amount of SSL traffic to begin with, but so far all of the
>alerts i've seen are false positives.  I saw about 549 of 2506 and 6 of
>2505 before i suppressed them.  Something is not quite right.
> > Yeah, I'm seeing false positives on both of those.  A lot more on 2506
> > than 2505.  I have not been able to figure out what the cause is yet
> > though - looks like normal ssl traffic at first glance.  But my
> > network's pretty big and messy, so we see false positives on just about
> > everything.

SID 2505 is falsely firing due to a bug in Snort. I've sent a pcap to the 
Snort developers and there should be a solution soon.

SID 2506 however is a bit weird (for me anyway). It alerts if the 
client_hello.timestamp bytes are > 2147483647 (a 32bit signed int).

I've skimmed the exploit this rule detects and i couldn't find any 
tomfoolery with the client_hello.timestamp field. In fact, it's a fixed value.

ssl_hello.timestamp = htonl(0x407babc0);

Which translates to 1081846720 seconds, which is less than the rule tests 
for and wouldn't fire. (Unless i'm looking at the wrong exploit i guess!) :-)

And then sets the 28 "random bytes" (which aren't really random in this 
exploit) :-)

memset((void *) ssl_hello.random_bytes, 0x66, 28);

To add to the weirdness, the most recent SSL 3.0 draft defines 
gmt_unix_timestamp in the client hello message, as a u_int32:

The client hello message includes a random structure, which is used later 
in the protocol.

    struct {
        uint32 gmt_unix_time;
        opaque random_bytes[28];
    } Random;
Could this phenomenon be caused simply by machines with the wrong date set? 
Signed or unsigned, the epoch is at 1 billion seconds, which will be 
covered by both an int32 and a u_int32, i just cant figure out why the 
timestamp peaks as it does, to cause the rule to fire so often, and also 
have doubts as to the accuracy of the rule in general?

Time for a coffee :)



More information about the Snort-sigs mailing list