[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.
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:
>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
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.
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