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

Gary_Portnoy at ...2451... Gary_Portnoy at ...2451...
Thu May 6 06:02:00 EDT 2004


That's a great explanation.  It finally makes sense what this rule is 
looking for, however erroneously.  Can we confirm that this rule was 
written to address this particular exploit: 
http://www.k-otik.com/exploits/04142004.sslbomb.c.php and not numerous 
others dealing with recent MS SSL vulnerability like this one: 
http://www.k-otik.com/exploits/04212004.THCIISSLame.c.php or this one: 
http://www.k-otik.com/exploits/04242004.iis5x_ssl_pct.pm.php  It's a lot 
harder to fin

Either way, I sent my pcaps to Snort developers as well and they said that 
the solution will be out soon.

Gary Portnoy

Chris Keladis <Chris.Keladis at ...2461...>
05/06/2004 12:41 AM

        To:     Gary_Portnoy at ...2451..., snort-sigs at lists.sourceforge.net
        cc:     "adam.w.hogan" <adam.w.hogan at ...1605...>
        Subject:        RE: [Snort-sigs] False Positives with SIDs 2505 and 2506?

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

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 
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 :)



This message is for the named person's use only. This communication is for 
informational purposes only and has been obtained from sources believed to 
be reliable, but it is not necessarily complete and its accuracy cannot be 
guaranteed. It is not intended as an offer or solicitation for the purchase
or sale of any financial instrument or as an official confirmation of any
transaction. Moreover, this material should not be construed to contain any
recommendation regarding, or opinion concerning, any security. It may
contain confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute, 
print, or copy any part of this message if you are not the intended 
recipient.  Any views expressed in this message are those of the individual
sender, except where the message states otherwise and the sender is 
authorized to state them to be the views of any such entity.

ITG Inc. reserves the right to monitor and archive all electronic 
communications through its network. 

ITG Inc. Member NASD, SIPC

More information about the Snort-sigs mailing list