Re: Massive stupidity (Was: Re: TCP vulnerability)
Assuming that he do not know port number and must try 20 - 40 ports, it takes 200 * 10 = 2000 seconds to resert a single session... Useless except a very special cases 9such as a big community decided to knock down SCO, for example). > > At 05:09 PM 20/04/2004, Richard A Steenbergen wrote: > > >party to know which side won the collision handling. Therefore you need > >262144 packets * 3976 ephemeral ports (assuming both sides are jnpr, again > >worst case) * 2 (to figure out who was the connecter and who was the > >accepter) = 2084569088 packets to exhaustively search all space on this > >one single Juniper to Juniper session. Now, lets just for the sake of > >argument say that the router is capable of actively processing 10,000 > >packets/sec of rst (a fairly exagerated number) and still have this be > >considered a tcp attack instead of a straight DoS against the routing > >engine. This will still take 208456 seconds, or 57.9 hours. > > I dont understand why the large differences in claims > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt > > says > Modern operating > systems normally default the RCV.WND to about 32,768 bytes. This > means that a blind attacker need only guess 65,535 RST segments > (2^^32/(RCV.WND*2)) in order to reset a connection. At DSL speeds > this means that most connections (assuming the attacker can > accurately guess both ports) can be reset in under 200 seconds > (usually far less). With the rise of broadband availability and > increasing available bandwidth, many Operating Systems have raised > their default RCV.WND to as much as 64k, thus making these attacks > even easier. > > > Also, with the various 'bots' at peoples disposal, why the assumption the > attack would not be distributed. > > ---Mike >
Re: Massive stupidity (Was: Re: TCP vulnerability)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2004-04-20, at 23.09, Richard A Steenbergen wrote: > but the massive amount of confusion, > rumor, and worry which the major router vendors (Cisco and Juniper) > created by essentially rediscovering the god damn spec and then telling > only their major customers about so that only rumors could filter down > to > the rest of the industry is absolutely pathetic. If you have a support > contract and were not told about this "attack" (if you could call it > that) > or were blatantly misinformed as many people seem to have been, you > should > demand to know why you didn't receive better treatment. this was to the best of my knowledge not handled by Cisco and Juniper and also to the best of my knowledge they did not pre-warn any customer. But I might be mistaken. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.3 iQA/AwUBQIYJ1qarNKXTPFCVEQIFVACfdbhaVD3lHDhKZvtHUd1ugUUFeToAn1Us FpSX+E9RmmezY4liEiInxYCR =hEOv -END PGP SIGNATURE-
Re: Massive stupidity (Was: Re: TCP vulnerability)
On Apr 20, 2004, at 9:23 PM, Mike Tancsa wrote: At 05:09 PM 20/04/2004, Richard A Steenbergen wrote: party to know which side won the collision handling. Therefore you need 262144 packets * 3976 ephemeral ports (assuming both sides are jnpr, again worst case) * 2 (to figure out who was the connecter and who was the accepter) = 2084569088 packets to exhaustively search all space on this one single Juniper to Juniper session. Now, lets just for the sake of argument say that the router is capable of actively processing 10,000 packets/sec of rst (a fairly exagerated number) and still have this be considered a tcp attack instead of a straight DoS against the routing engine. This will still take 208456 seconds, or 57.9 hours. I dont understand why the large differences in claims http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt says Modern operating systems normally default the RCV.WND to about 32,768 bytes. This means that a blind attacker need only guess 65,535 RST segments (2^^32/(RCV.WND*2)) in order to reset a connection. At DSL speeds this means that most connections (assuming the attacker can accurately guess both ports) can be reset in under 200 seconds (usually far less). With the rise of broadband availability and increasing available bandwidth, many Operating Systems have raised their default RCV.WND to as much as 64k, thus making these attacks even easier. You missed the "(assuming the attacker can accurately guess both ports)" part. This is BY NO MEANS a given. In fact, it is pretty much guaranteed to not be a given on any router which has not recently been rebooted. (Or at least that the attacker doesn't know has been recently rebooted. :) Also, with the various 'bots' at peoples disposal, why the assumption the attack would not be distributed. Who made that assumption? I do not see it above. Also, if you have a 'bot army at your disposal, it is trivial to packet a router off the 'Net - orders of magnitude easier than guessing sequence / port number - and faster too. In fact, you can probably do it in far less than 200 seconds, more or less 59 hours. And then you take down *all* BGP sessions, not just the one in question. Since miscreants are at least as lazy as you and I, would someone explain to me why they would bother trying to guess the sequence & port numbers, even with this new "vulnerability", rather just just packet the router off the 'Net? Especially now that we have made it easier by forcing the router to calculate MD5 signatures on each packet Honestly, once the hysteria dies down, I think we will be going to all our peers and asking to take the MD5 stuff off. I honestly believe we will suffer more downtime - and longer downtime - from MD5 keys going out of sync than any RST style attack. If people are really worried about this, then they should ingress filter at the leaf nodes. If they did, no one could spoof the source IP of your neighbor router and life would be good. Add on things like the TTL hack and you have at least as good a protection as the MD5 gives you without any issues of higher CPU, 1000s upon 1000s of keys to manage, and all the other associated risks. But we all know people will not bother source filtering leaf nodes. Everyone will clamor about MD5 keys and how you should be protecting BGP sessions. Kinda like guarding the windows while the doors are open and unattended. -- TTFN, patrick
Re: Massive stupidity (Was: Re: TCP vulnerability)
At 05:09 PM 20/04/2004, Richard A Steenbergen wrote: party to know which side won the collision handling. Therefore you need 262144 packets * 3976 ephemeral ports (assuming both sides are jnpr, again worst case) * 2 (to figure out who was the connecter and who was the accepter) = 2084569088 packets to exhaustively search all space on this one single Juniper to Juniper session. Now, lets just for the sake of argument say that the router is capable of actively processing 10,000 packets/sec of rst (a fairly exagerated number) and still have this be considered a tcp attack instead of a straight DoS against the routing engine. This will still take 208456 seconds, or 57.9 hours. I dont understand why the large differences in claims http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt says Modern operating systems normally default the RCV.WND to about 32,768 bytes. This means that a blind attacker need only guess 65,535 RST segments (2^^32/(RCV.WND*2)) in order to reset a connection. At DSL speeds this means that most connections (assuming the attacker can accurately guess both ports) can be reset in under 200 seconds (usually far less). With the rise of broadband availability and increasing available bandwidth, many Operating Systems have raised their default RCV.WND to as much as 64k, thus making these attacks even easier. Also, with the various 'bots' at peoples disposal, why the assumption the attack would not be distributed. ---Mike
Re: TCP vulnerability
On Tue, 20 Apr 2004, Joe Abley wrote: > I suggest an extensive late-night BOF in San Francisco in the bar to > discuss the mechanics of adding MD5 keys to all your sessions in 48 > hours. Zeitgeist at 7pm or the Toronado at 9pm?
Re: TCP vulnerability
> > I suggest an extensive late-night BOF in San Francisco in the bar to > > discuss the mechanics of adding MD5 keys to all your sessions in 48 > > hours. Evidence of RSI and eyesight failure will be mandatory > > for those who prefer to be keyboard monkeys all their lives instead > of building tools to configure and manage networks Tools were used, some built specifically to minimize the RSI and eyestrain impact of this last round of config changes. Not the tools that one gets to build and use when one has the resources of a tier-1 provider at one's disposal (one set in particular I hear it quite excellent, and I wish it would be made available to the community), but it was by no means a tools-free effort on Joe's part. Stephen
Re: TCP vulnerability
On 20 Apr 2004, at 17:37, Randy Bush wrote: I suggest an extensive late-night BOF in San Francisco in the bar to discuss the mechanics of adding MD5 keys to all your sessions in 48 hours. Evidence of RSI and eyesight failure will be mandatory for those who prefer to be keyboard monkeys all their lives instead of building tools to configure and manage networks I considered that, but I figured it would take longer to make a tool which could deal with the ten thousand ways that people want to coordinate this change (*and* speak to them over the phone) than it would to just get on and do it. The passwords were generated, the databases were populated and the rt2 tickets were opened using a magnificent lump of awk though, if I do say so myself. Joe
Re: Massive stupidity (Was: Re: TCP vulnerability)
On Tue, 20 Apr 2004, Richard A Steenbergen wrote: > Anyone who seriously wanted to protect against this attack could easily > deploy RST rate limits against their management interfaces, rather than > run around trying to set up MD5 with every peer. As a long term > improvement, a random ephemeral port selection process could be used. Insufficient to completely protect against the identified vulnerabilities. Please continue reading.
Re: TCP vulnerability
> I suggest an extensive late-night BOF in San Francisco in the bar to > discuss the mechanics of adding MD5 keys to all your sessions in 48 > hours. Evidence of RSI and eyesight failure will be mandatory for those who prefer to be keyboard monkeys all their lives instead of building tools to configure and manage networks randy
Massive stupidity (Was: Re: TCP vulnerability)
On Tue, Apr 20, 2004 at 10:36:48AM -0700, Grant A. Kirkwood wrote: > > Since no one's mentioned it yet, apparently there was a change in plans. > It was just released a day early. > > http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_on_hi_te/internet_threat > > And the official one: > > http://www.uniras.gov.uk/vuls/2004/236929/index.htm Allow me to quote some of my favorite parts for a second: > Although denial of service using crafted TCP packets is a well known > weakness of TCP, until recently it was believed that a successful denial > of service attack was not achievable in practice. The reason for this is > that the receiving TCP implementation checks the sequence number of the > RST or SYN packet, which is a 32 bit number, giving a probability of > 1/232 of guessing the sequence number correctly (assuming a random > distribution). > > The discoverer of the practicability of the RST attack was Paul A. > Watson, who describes his research in his paper Slipping In The Windo: > TCP Reset Attacks, presented at the CanSecWest 2004 conference. He > noticed that the probability of guessing an acceptable sequence number > is much higher than 1/232 because the receiving TCP implementation will > accept any sequence number in a certain range (or window) of the > expected sequence number. The window makes TCP reset attacks > practicable. Sooo... This begs the question... Exactly how much research DID it take to read RFC793 page 37, which clearly states: Reset Processing In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields. A reset is valid if its sequence number is in the window. In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN. The receiver of a RST first validates it, then changes state. If the receiver was in the LISTEN state, it ignores it. If the receiver was in SYN-RECEIVED state and had previously been in the LISTEN state, then the receiver returns to the LISTEN state, otherwise the receiver aborts the connection and goes to the CLOSED state. If the receiver was in any other state, it aborts the connection and advises the user and goes to the CLOSED state. This is not rocket science, every TCP stack in existance implements this exactly this way. The fact that ANYONE ever thought it was 2^32 packets to hit upon the sequence number for a forged reset shows pure ignorance and an inability to read on their part, but the massive amount of confusion, rumor, and worry which the major router vendors (Cisco and Juniper) created by essentially rediscovering the god damn spec and then telling only their major customers about so that only rumors could filter down to the rest of the industry is absolutely pathetic. If you have a support contract and were not told about this "attack" (if you could call it that) or were blatantly misinformed as many people seem to have been, you should demand to know why you didn't receive better treatment. Bottom line, this attack is no more practical now than it was yesterday. Let's run some numbers for a second shall we. First off, as I'm sure everyone knows, BGP sessions are formed when one side establishes a tcp connection from a high numbered ephemeral port to port 179. Both sides actively attempt to connect to each other on and off through an alternating series of Connect and Active states, but eventually one side will connect to the other and only one session will survive the collision handling process. Now, let us just use Juniper as a worst case example, since they seem to have a very very restricted set of ephemeral ports for some reason or another (low 1024 high 5000, 3976 possible ports). Given the default settings of a recvsockbuf size 16384, the maximum advertised receive window will be 16384. This cuts the total sequence space to be scanned down from 2^32 to 2^32 / 2^14 = 262144 packets. Now, even though the outbound port is a simple incrementation, an outside party has no way to know what the current number is (and in the case of long lived connections it may not do them any good at all, though theoretically routers just rebooted could be more vulnerable). It is also impossible for an outside party to know which side won the collision handling. Therefore you need 262144 packets * 3976 ephemeral ports (assuming both sides are jnpr, again worst case) * 2 (to figure out who was the connecter and who was the accepter) = 2084569088 packets to exhaustively search all space on this one single Juniper to Juniper session. Now, lets just for the sake of argument say that the router is capable of actively processing 10,000 packets/sec of rst (a fairly exagerated number) and still have this be considered a tcp attack instead of a straight DoS against the routing engine. This will still take 208456 seconds, or 57.9 hours. Anyone wh
re: TCP vulnerability
Hi, For those not helped too much the MD5 Signature Option, this i-d addresses the attacks in the Watson paper (it was meant to come out just when the advisory came out, but they jumped the gun). There are implementations in *xes and router OSes - more info from those sources. Allison Forwarded Message A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Transmission Control Protocol security considerations Author(s) : R. Stewart Filename: draft-ietf-tcpm-tcpsecure-00.txt Pages : 10 Date: 2004-4-20 TCP (RFC793 [1]) is widely deployed and one of the most often used reliable end to end protocols for data communication. Yet when it was defined over 20 years ago the internet, as we know it, was a different place lacking many of the threats that are now common. Recently several rather serious threats have been detailed that can pose new methods for both denial of service and possibly data injection by blind attackers. This document details those threats and also proposes some small changes to the way TCP handles inbound segments that either eliminate the threats or at least minimize them to a more acceptable level. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt - --4737358894.1082487684/segue.merit.edu-- --- End of Forwarded Message
Re: TCP vulnerability
On 20 Apr 2004, at 13:59, Aviva Garrett wrote: In message <[EMAIL PROTECTED]>you write: Since no one's mentioned it yet, apparently there was a change in plans. It was just released a day early. This is because of the story at http://www.washingtonpost.com/, in the Technology section. I suggest an extensive late-night BOF in San Francisco in the bar to discuss the mechanics of adding MD5 keys to all your sessions in 48 hours. Evidence of RSI and eyesight failure will be mandatory, along with battle stories about rt2 mail-loops and rancid-scraping awk scripts gone mad. Joe
Re: TCP Vulnerability makes case for authenticated BGP
On Tue, 20 Apr 2004, tad pedley wrote: > Although denial of service using crafted TCP packets is a well known > weakness of TCP, until recently it was believed that a successful > denial of service attack was not achievable in practice. The reason > for this is that the receiving TCP implementation checks the > sequence number of the RST or SYN packet, which is a 32 bit number, > giving a probability of 1/232 of guessing the sequence number > correctly (assuming a random distribution). > > The discoverer of the practicability of the RST attack was Paul A. > Watson, who describes his research in his paper Slipping In The > Window: TCP Reset Attacks, presented at the CanSecWest 2004 > conference. He noticed that the probability of guessing an > acceptable sequence number is much higher than 1/232 because the > receiving TCP implementation will accept any sequence number in a > certain range (or window) of the expected sequence number. The > window makes TCP reset attacks practicable. Believed by whom, is the question. It has been clearly documented for a long time now that such larger windows exist. They have even been documented specifically about BGP (draft-ietf-idr-bgp-vuln-00.txt). -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: TCP vulnerability
In message <[EMAIL PROTECTED]>you write: > > Since no one's mentioned it yet, apparently there was a change in plans. > It was just released a day early. This is because of the story at http://www.washingtonpost.com/, in the Technology section. Thanks, ..Aviva > > http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_on_ > hi_te/internet_threat > > And the official one: > > http://www.uniras.gov.uk/vuls/2004/236929/index.htm > > Grant > > -- > Grant A. Kirkwood - grant(at)tnarg.org > Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED
TCP Vulnerability makes case for authenticated BGP
NISCC Vulnerability Advisory 236929Vulnerability Issues in TCPVersion Information Advisory Reference 236929 Release Date 20 April 2004 Last Revision 20 April 2004 Version Number 1.0 What is Affected?The vulnerability described in this advisory affects implementations of the Transmission Control Protocol (TCP) that comply with the Internet Engineering Task Forces (IETFs) Requests For Comments (RFCs) for TCP, including RFC 793, the original specification, and RFC 1323, TCP Extensions for High Performance.TCP is a core network protocol used in the majority of networked computer systems today. Many vendors include support for this protocol in their products and may be impacted to varying degrees. Furthermore any network service or application that relies on a TCP connection will also be impacted, the severity depending primarily on the duration of the TCP session. SeverityThe impact of this vulnerability varies by vendor and application, but in some deployment scenarios it is rated critical. Please see the vendor section below for further information. Alternatively contact your vendor for product specific information.If exploited, the vulnerability could allow an attacker to create a Denial of Service condition against existing TCP connections, resulting in premature session termination. The resulting session termination will affect the application layer, the nature and severity of the effects being dependent on the application layer protocol. The primary dependency is on the duration of the TCP connection, with a further dependency on knowledge of the network (IP) addresses of the end points of the TCP connection.The Border Gateway Protocol (BGP) is judged to be potentially most affected by this vulnerability.BGP relies on a persistent TCP session between BGP peers. Resetting the connection can result in medium term unavailability due to the need to rebuild routing tables and route flapping. Route flapping may result in route dampening (suppression) if the route flaps occur frequently within a short time interval. The overall impact on BGP is likely to be moderate based on the likelihood of successful attack. If the TCP MD5 Signature Option and anti-spoofing measures are used then the impact will be low as these measures will successfully mitigate the vulnerability.There is a potential impact on other application protocols such as DNS (Domain Name System) and SSL (Secure Sockets Layer) in the case of zone transfers and ecommerce transactions respectively, but the duration of the sessions is relatively short and the sessions can be restarted without medium term unavailability problems. In the case of SSL it may be difficult to guess the source IP address.Data injection may be possible. However, this has not been demonstrated and appears to be problematic. SummaryThe issue described in this advisory is the practicability of resetting an established TCP connection by sending suitable TCP packets with the RST (Reset) or SYN (Synchronise) flags set.The packets need to have source and destination IP addresses that match the established connection as well as the same source and destination TCP ports.The fact that TCP sessions can be reset by sending suitable RST and SYN packets is a design feature of TCP according to RFC 793, but a reset attack is only possible at all because the source IP address and TCP port can be forged or spoofed.Although denial of service using crafted TCP packets is a well known weakness of TCP, until recently it was believed that a successful denial of service attack was not achievable in practice. The reason for this is that the receiving TCP implementation checks the sequence number of the RST or SYN packet, which is a 32 bit number, giving a probability of 1/232 of guessing the sequence number correctly (assuming a random distribution).The discoverer of the practicability of the RST attack was Paul A. Watson, who describes his research in his paper Slipping In The Window: TCP Reset Attacks, presented at the CanSecWest 2004 conference. He noticed that the probability of guessing an acceptable sequence number is much higher than 1/232 because the receiving TCP implementation will accept any sequence number in a certain range (or window) of the expected sequence number. The window makes TCP reset attacks practicable.Any application protocol which relies on long term TCP connections and for which the source and destination IP addresses and TCP ports are known or can be easily guessed will be vulnerable to at least denial of service attacks. DetailsTCP is the transport layer protocol designed to provide connection-oriented reliable delivery of IP packets. To do this TCP uses a mixture of flags, to indicate state, and sequence numbers, to identify the order in which the packets are to be reassembled.TCP also provides a number, called an acknowledgement number, that is used to indicate the sequence number of the next packet expected. The packets are reassembled by the receiving TCP
TCP vulnerability
Since no one's mentioned it yet, apparently there was a change in plans. It was just released a day early. http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_on_hi_te/internet_threat And the official one: http://www.uniras.gov.uk/vuls/2004/236929/index.htm Grant -- Grant A. Kirkwood - grant(at)tnarg.org Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED
