[Snort-users] Re: [Snort-devel] Detecting TCP Timestamp PAWS DoS from tracefile

J.Smith lbalbalba at ...125...
Sun Aug 7 05:43:29 EDT 2005


Thanks, again.

"rmkml" <rmkml at ...953...> 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 at ...953...>
To: "J.Smith" <lbalbalba at ...125...>
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 at ...953...>
>> To: J.Smith <lbalbalba at ...125...>
>> 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 at ...125...>
>>> To: rmkml <rmkml at ...953...>, snort-users at lists.sourceforge.net,
>>>     snort-devel at 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 at ...953...>
>>> To: "J.Smith" <lbalbalba at ...125...>
>>> 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 at ...1935...>
>>>> ...
>>>>     * 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 at ...125...>
>>>>> To: snort-users at lists.sourceforge.net, 
>>>>> snort-devel at 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.
>>>>>
>>>>>




More information about the Snort-users mailing list