To clarify what Stream4 currently does:
Before adding a packet to the list of those included in
reassembly, it checks for a TCP Timestamp option that is set to 0.
Some Win32 systems use 0 on SYN packets, so that is allowed.
This is only done on Sessions for which Stream4 is doing
reassembly, so for any other traffic, Snort won't make a peep.
Based on the information on the web for this DoS, it would be
pretty trivial to ensure any TCP Timestamps fall within a certain
window. If one is outside the window, the packet would be ignored,
dropped, etc.
As we work on the next Stream engine, we will take this DoS into
consideration and attempt to provide some means of detection.
Cheers.
-steve
-----Original Message-----
From: snort-devel-admin@lists.sourceforge.net
[mailto:snort-devel-admin@lists.sourceforge.net] On Behalf Of J.Smith
Sent: Sunday, August 07, 2005 8:43 AM
To: snort-users@lists.sourceforge.net;
snort-devel@lists.sourceforge.net; snort-sigs@lists.sourceforge.net
Subject: Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS
from tracefile
Thanks, again.
"rmkml" <rmkml@free.fr> wrote:
Snort support PAWS but possible not detect DoS
Yeah, that was my guess as well. If snort doesn't detect this
issue, would it be possible/feasible/easy to add a ruleset
that would allow snort to detect it ?
Im detected PAWS discard (linux stack) with firestorm nids product :
Im not a developer myself, so im not quite sure what it is
that firestorm is supposed to check, but ... it looks like it
triggers an alert if any supplied TCP timestamp in a given
tcp session is set more than 24 hours into the future or past ?
Sincerely,
John Smith
PS:
Just in case, Im adding the snort-sigs list to the thread. In
summary, the question is whether snort allows for the
detection of the following issue :
Multiple Vendor TCP Timestamp PAWS Remote Denial Of Service
Vulnerability
http://www.securityfocus.com/bid/13676
TCP does not adequately validate segments before updating
timestamp value
http://www.kb.cert.org/vuls/id/637934
CAN-2005-0356
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0356
----- Original Message -----
From: "rmkml" <rmkml@free.fr>
To: "J.Smith" <lbalbalba@hotmail.com>
Sent: Sunday, August 07, 2005 2:15 PM
Subject: Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS
from tracefile
Snort support PAWS but possible not detect DoS (same Bro nids),
Im detected PAWS discard (linux stack) with firestorm nids product :
firestorm-0.5.5/decode_plugins/tcpstream.c :
* o PAWS (rfc1323) evasion
...
static struct alert alert_tcp3={
.alert="PAWS discard",
...
/* rfc1323: H1. Apply PAWS checks first */
if ( rcv->flags & TF_TSTAMP_OK &&
(tp->saw_tstamp=tcp_fast_options(tcph, &tp->tsval)) ) {
if ( (int32_t)(rcv->ts_recent - tp->tsval) >
TCP_PAWS_WINDOW &&
(u_int32_t)p->time.tv_sec < rcv->ts_recent_stamp
+ TCP_PAWS_24DAYS ) {
alert_tag(cur.pkt, &alert_tcp3, -1);
return;
}
Regards
Rmkml
On Sun, 7 Aug 2005, rmkml wrote:
Date: Sun, 7 Aug 2005 13:52:59 +0200 (CEST)
From: rmkml <rmkml@free.fr>
To: J.Smith <lbalbalba@hotmail.com>
Subject: Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS from
tracefile
Possible send (anonymazing ip) tracefile/pcapfile to the list ?
On Sun, 7 Aug 2005, J.Smith wrote:
Date: Sun, 7 Aug 2005 13:29:29 +0200
From: J.Smith <lbalbalba@hotmail.com>
To: rmkml <rmkml@free.fr>, snort-users@lists.sourceforge.net,
snort-devel@lists.sourceforge.net
Subject: Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS from
tracefile
Hi.
Thanks for the information, but from the limited
information in the
changelog I cannot actually determine if this is really
referring to the
same ddos attack as the one that I am referring to.
If I understand the issue I originally mentioned
correctly, then the
attacker injects a forged packet into the stream that has a TCP
timestamp that lies somewhere into the future, causing
all subsequent
packets to be dropped because they are deemed to be too
old or invalid,
effectively 'stalling' the connection.
So if I understand correctly, then any relevant snort
ruleset would have
to verify that at least all timestamps in a given tcp session are
somewhat 'consecutive' ? Or if the timestamp value was
set to a large
value by the attacker, then it will likely be larger than
the timestamp
values in any subsequent incoming segments that belong to
the same tcp
session - does any snort ruleset detect this ?
Thanks,
Sincerely,
John Smith.
----- Original Message ----- From: "rmkml" <rmkml@free.fr>
To: "J.Smith" <lbalbalba@hotmail.com>
Sent: Sunday, August 07, 2005 1:19 PM
Subject: Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS from
tracefile
Hi,
Found PAWS on src snort 240 : (ChangeLog)
2005-03-15 Jeremy Hewlett <jh@sourcefire.com>
...
* etc/snort.conf:
Stream4 fixes - Handle PAWS, NULL TCP Flags in established
session,
limit overlaps in established session, update ACK
when server
sends
RST. Performance changes for cleaning up session
cache. Thanks
Steve Sturges and Andy Mullican for the patches.
src/preprocessors/spp_stream4.c :
* 04 Feb 2005: SAS Updated to handle favor_old and
favor_new options.
* favor_new traverses the tree in the opposite
* direction and builds the stream using newer
packets.
* Also added checks for:
* - PAWS (Timestamp option is set and 0) on an
* establiahed session and ACK in the
packet. Win32
* uses 0 Timestamp on Syn-only packets.
Regards
Rmkml
On Sun, 7 Aug 2005, J.Smith wrote:
Date: Sun, 7 Aug 2005 12:43:23 +0200
From: J.Smith <lbalbalba@hotmail.com>
To: snort-users@lists.sourceforge.net,
snort-devel@lists.sourceforge.net
Subject: [Snort-devel] Detecting TCP Timestamp PAWS DoS
from tracefile
Hi.
At our site, we have the impression that we might have
been hit by the
following issue :
Multiple Vendor TCP Timestamp PAWS Remote Denial Of Service
Vulnerability
http://www.securityfocus.com/bid/13676
TCP does not adequately validate segments before
updating timestamp
value
http://www.kb.cert.org/vuls/id/637934
In a nutshell, the issue manifests if an attacker transmits a
sufficient TCP PAWS packet to a vulnerable computer. A
large value is
set by the attacker as the tcp packet timestamp. When
the target
computer processes this packet, the internal timer is
updated to the
large attacker supplied value. This causes all other
valid packets
that are received subsequent to an attack to be dropped
as they are
deemed to be too old, or invalid. This effectively 'stalls' the
connection, which will deny service for a target connection.
Fortunately, we have a tracefile of some of the traffic
that hit our
site at the time. I was wondering how easy it would be
to 'proof' that
we did indeed experience this issue with the use of
snort ? I did a
quick scan of the snort ruleset database, but it appears that
detection of this issue is not included in the snort
database yet ?
Thanks,
John Smith.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Snort-devel mailing list
Snort-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-devel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
