TCP RST attack (the cause of all that MD5-o-rama)
http://www.uniras.gov.uk/vuls/2004/236929/index.htm -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
now let me take a bite at this :P i can see this 'attack' operational against a multihop bgp session that's not md5'd. now the question is... would this also affect single-hop bgp sessions? my understanding would be no, as single-hops require ttl set to 1. -J On Tue, Apr 20, 2004 at 01:36:09PM -0400, Mike Tancsa wrote:
http://www.uniras.gov.uk/vuls/2004/236929/index.htm
-------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
-- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
How do you tell an adjacent TTL set to 1 from a TTL set to 5 four hops away? Owen --On Tuesday, April 20, 2004 14:54 -0400 James <haesu@towardex.com> wrote:
now let me take a bite at this :P
i can see this 'attack' operational against a multihop bgp session that's not md5'd.
now the question is... would this also affect single-hop bgp sessions? my understanding would be no, as single-hops require ttl set to 1.
-J
On Tue, Apr 20, 2004 at 01:36:09PM -0400, Mike Tancsa wrote:
http://www.uniras.gov.uk/vuls/2004/236929/index.htm
-------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
-- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.
On Tue Apr 20, 2004 at 02:54:16PM -0400, James wrote:
now the question is... would this also affect single-hop bgp sessions? my understanding would be no, as single-hops require ttl set to 1.
All it requires is for the TTL to be 1 (or 0, I can't remember which) when it's received. Just launch your packets with a TTL of the number of hops between you and the victim, and that's that bit sorted... Simon
On Tue, 20 Apr 2004, James wrote:
i can see this 'attack' operational against a multihop bgp session that's not md5'd.
now the question is... would this also affect single-hop bgp sessions? my understanding would be no, as single-hops require ttl set to 1.
you can engineer packets to make sure they have the right ttl when they arrive, ie if your 10 hops away, set ttl to 10 and it will be 1 on arrival :) Steve
-J
On Tue, Apr 20, 2004 at 01:36:09PM -0400, Mike Tancsa wrote:
http://www.uniras.gov.uk/vuls/2004/236929/index.htm
-------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
ah yes.. forgot about that :) Thanks, -J On Tue, Apr 20, 2004 at 08:24:02PM +0100, Stephen J. Wilcox wrote:
On Tue, 20 Apr 2004, James wrote:
i can see this 'attack' operational against a multihop bgp session that's not md5'd.
now the question is... would this also affect single-hop bgp sessions? my understanding would be no, as single-hops require ttl set to 1.
you can engineer packets to make sure they have the right ttl when they arrive, ie if your 10 hops away, set ttl to 10 and it will be 1 on arrival :)
Steve
-J
On Tue, Apr 20, 2004 at 01:36:09PM -0400, Mike Tancsa wrote:
http://www.uniras.gov.uk/vuls/2004/236929/index.htm
-------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
-- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
On Apr 20, 2004, at 3:24 PM, Stephen J. Wilcox wrote:
On Tue, 20 Apr 2004, James wrote:
i can see this 'attack' operational against a multihop bgp session that's not md5'd.
now the question is... would this also affect single-hop bgp sessions? my understanding would be no, as single-hops require ttl set to 1.
you can engineer packets to make sure they have the right ttl when they arrive, ie if your 10 hops away, set ttl to 10 and it will be 1 on arrival :)
Not if you use the TTL hack. Seems like that would be much more useful, and less CPU intensive, and less prone to user error, etc., etc. than MD5 -- TTFN, patrick
Patrick W.Gilmore wrote:
On Apr 20, 2004, at 3:24 PM, Stephen J. Wilcox wrote:
On Tue, 20 Apr 2004, James wrote:
i can see this 'attack' operational against a multihop bgp session that's not md5'd.
now the question is... would this also affect single-hop bgp sessions? my understanding would be no, as single-hops require ttl set to 1.
you can engineer packets to make sure they have the right ttl when they arrive, ie if your 10 hops away, set ttl to 10 and it will be 1 on arrival :)
Not if you use the TTL hack.
Seems like that would be much more useful, and less CPU intensive, and less prone to user error, etc., etc. than MD5
But it has limited effectiveness for multi-hop sessions. There is the appeal of a solution that does not depend of the physical layout of the BGP peers. -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387
On Tue, 20 Apr 2004, Crist Clark wrote:
But it has limited effectiveness for multi-hop sessions. There is the appeal of a solution that does not depend of the physical layout of the BGP peers.
Does MD5 open the door to cpu DOS attacks on routers though? Eg can someone craft a DOS attack to take out the CPU on a router by forcing it to MD5 authenticate torrents of junk packets, using less bandwidth than it would take to DOS the links themselves? As has been pointed out, blind attacker needs to guess the source port as well, which would seem to multiply the search space blind attackers need to hit (the tcpsecure paper states as much - "assuming the attacker can accurately guess both ports") Are such attacks still practical in that light? -Dan
On Tue, Apr 20, 2004 at 02:11:02PM -0700, Dan Hollis wrote:
On Tue, 20 Apr 2004, Crist Clark wrote:
But it has limited effectiveness for multi-hop sessions. There is the appeal of a solution that does not depend of the physical layout of the BGP peers.
Does MD5 open the door to cpu DOS attacks on routers though? Eg can someone craft a DOS attack to take out the CPU on a router by forcing it to MD5 authenticate torrents of junk packets, using less bandwidth than it would take to DOS the links themselves?
Yes it does. About 5 mbit of md5 should peg a juniper at 100% according to my friend alex. I have not verified this in the lab. I suggest you try it out. Also, this is why the GTSM (ttl hack) was written up ;) /vijay
vijay gill wrote:
Yes it does. About 5 mbit of md5 should peg a juniper at 100% according to my friend alex. I have not verified this in the lab. I suggest you try it out.
Also, this is why the GTSM (ttl hack) was written up ;)
So then you're suggesting that the GTSM is the correct work-around? -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"(SM)
On Tue, Apr 20, 2004 at 02:42:07PM -0700, Rodney Joffe wrote:
vijay gill wrote:
Yes it does. About 5 mbit of md5 should peg a juniper at 100% according to my friend alex. I have not verified this in the lab. I suggest you try it out.
Also, this is why the GTSM (ttl hack) was written up ;)
So then you're suggesting that the GTSM is the correct work-around?
No, the correct workaround is the http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt draft. MD5 is also the correct workaround. However, neither of the two protect against what is the most vulnerable thing in the internet infrastructure today - a large amount of PPS at the _router_ (with or without md5 or tcpsecure) will blow it out of the water. A 10mbits/s of packets at the juniper without md5 will also destroy it. GTSM protects against that, the fact that it also works against this is just an unexpected side benefit. /vijay
On Tue, Apr 20, 2004 at 09:45:01PM +0000, vijay gill wrote:
infrastructure today - a large amount of PPS at the _router_ (with or without md5 or tcpsecure) will blow it out of the water. A 10mbits/s of packets at the juniper without md5 will also destroy it.
To be clear, I was just using jnx as an example. There are very few currently shipping boxes that will survive a large PPS attack. (also to be fair, been a while since I verified the above numbers) /vijay
On 20-apr-04, at 23:45, vijay gill wrote:
the correct workaround is the http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt draft. MD5 is also the correct workaround. However, neither of the two protect against what is the most vulnerable thing in the internet infrastructure today - a large amount of PPS at the _router_ (with or without md5 or tcpsecure) will blow it out of the water.
So all we have to do is apply strong crypto a bit smarter, such that we only burn CPU cycles for good packets rather than for all packets.
Dan Hollis wrote:
On Tue, 20 Apr 2004, Crist Clark wrote:
But it has limited effectiveness for multi-hop sessions. There is the appeal of a solution that does not depend of the physical layout of the BGP peers.
Does MD5 open the door to cpu DOS attacks on routers though? Eg can someone craft a DOS attack to take out the CPU on a router by forcing it to MD5 authenticate torrents of junk packets, using less bandwidth than it would take to DOS the links themselves?
A reasonable implementation of RFC2385 would only do the cryptographic MD5 check after matching the TCP 4-tuple and the sequence number. So, with respect to the attack under discussion, only the packets that would have succeded in reseting the session make it to MD5 processing where they then would be dropped. Still, hitting the TCP stack even without doing the MD5 checks can kill a router. That's what the TTL hack was suggested for in the first place.
As has been pointed out, blind attacker needs to guess the source port as well, which would seem to multiply the search space blind attackers need to hit (the tcpsecure paper states as much - "assuming the attacker can accurately guess both ports")
Are such attacks still practical in that light?
Yes. Most OSs do not randomize port numbers, but start at a fixed value at reboot. On top of that, many do not use much of the 16-bit space before wrapping. Now add that most BGP speakers don't initiate much TCP and fire up their long lived BGP sessions at boot time. The search space is not that big. Then there's always going to a looking glass and just looking one up. -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387
On Tue, 20 Apr 2004, Mike Tancsa wrote:
A huge round of applause for everyone not doing RPF and egress filtering where it is trivial to do so. You make everyones job that little bit harder. You know who you are. -Dan
On Apr 20, 2004, at 1:36 PM, Mike Tancsa wrote:
What is a typical receive window on a router? I have been told (have not confirmed) it was about 14 bits. Assuming a well randomized starting sequence number (just give me this one for the moment), and a source port range of ~4K (one of the router vendor's defaults), at 10K pps it would still take ~29 hours on average to guess the proper values for everything necessary to RST a BGP session. (You can see my math at the end. Feel free to correct me if I missed something.) Hitting a router for a full day at 10K pps is likely to be noticed by most networks. If you would not notice this, perhaps you should change your monitoring? :) And, if you twiddle the defaults on the router vendor mentioned above, or you use a different router vendor, substituting "2^16" for "4000" in the paragraph above leads you to ... 19 days? (Someone check my math. :) Of course, some of the reports say that ephemeral ports are not well randomized for some router vendors. :( So, while this is an interesting application of technology (if you are a h4x0r k1dd13 :), I think if the router vendors used well randomized ephemeral ports and sequence numbers, and used the full range of ports available to them, most routers will fall over long before someone could guess the proper values and reset a single BGP session. Or at least the owners would notice before the reset succeeded. It would be even better if the receive window was tuned downward for BGP - not like you need a huge window for data transfer when the hosts are directly connected. Then we could all stop frantically trying to synchronize thousands of keys between thousands of networks, an exercise which is destined to lose some data, and therefore some connectivity. -- TTFN, patrick Sequence numbers are 32 bits. Since the miscreant only needs to guess once every 14 bits, you get: 2^32 / 2^14 == 262144 There is a router vendor out there which defaults to source ports between 1024 and 5000, or so I have been told. (This router vendor does many things very well and should not be considered a Bad Vendor for this one minor error, which I hope they will fix ASAP.) We now have: (5000 - 1024) * 262144 == 1042284544 Let's assume a typical router can take 10K pps to the main CPU without falling over. I know some can take slightly more, and many cannot take anywhere near that, but it is a nice round number. Taking 10K pps, we get: 1042284544 / 10000 == 104228.4544 This means it will take about 29 hours to guess each possibility. Of course, you will not have to guess each possibility to find the answer, so you should divide by two to get the average time to guess correctly. But then you don't know which side is on port 179, so you have to multiply by two, which kinda cancels that out.
On Tue, 20 Apr 2004 15:40:38 EDT, "Patrick W.Gilmore" said:
Assuming a well randomized starting sequence number (just give me this one for the moment),
Nope. I won't give you that one, because that's a big chunk of the problem: http://lcamtuf.coredump.cx/newtcp/ (one year later) http://razor.bindview.com/publish/papers/tcpseq.html (original paper) It seems that Cisco has its act mostly together, but a *LOT* of other vendors don't, even a year after...
On Apr 20, 2004, at 4:49 PM, Valdis.Kletnieks@vt.edu wrote:
On Tue, 20 Apr 2004 15:40:38 EDT, "Patrick W.Gilmore" said:
Assuming a well randomized starting sequence number (just give me this one for the moment),
Nope. I won't give you that one, because that's a big chunk of the problem:
http://lcamtuf.coredump.cx/newtcp/ (one year later) http://razor.bindview.com/publish/papers/tcpseq.html (original paper)
It seems that Cisco has its act mostly together, but a *LOT* of other vendors don't, even a year after...
Well, we are talking about router vendors here, so let's limit it to cisco + Juniper. Even assuming the 4K range (1024 -> 5000), the numbers are essentially "random" for a non-recently-rebooted router. There is no way for you to know when the session started, or what number the router was at when it did start. Besides, in my original post, I said that the best way to defend against this is good randomization, and commented that we might not have that now. :) Speaking of good randomization, does anyone have a good algorithm to randomize ephemeral ports? Obviously "pick random number, see if port is open, if it is, repeat" is not a good idea, especially on a busy host with lots of connections. I was thinking something like "pick 65K random numbers on boot, store in file/array, cycle through". Perhaps just pick a random number on boot, start at that high port number, then sequentially cycle? The last one would not be good for hosts which accept connections (gives you a good idea of current port number), but would work for routers with BGP sessions which were weeks or months long. Does anyone know if / how modern OSes randomize ephemeral ports? -- TTFN, patrick
PWG> Date: Tue, 20 Apr 2004 19:24:37 -0400 PWG> From: Patrick W. Gilmore PWG> Speaking of good randomization, does anyone have a good PWG> algorithm to randomize ephemeral ports? Obviously "pick PWG> random number, see if port is open, if it is, repeat" is not PWG> a good idea, especially on a busy host with lots of PWG> connections. I was thinking something like "pick 65K PWG> random numbers on boot, store in file/array, cycle through". I don't think we're even that far along. If I'm reading FreeBSD 4.9 and NetBSD 1.6.2 source correctly, /usr/src/sys/netinet/in_pcb.c tells all. PWG> Does anyone know if / how modern OSes randomize ephemeral PWG> ports? AFAIK, sequential search is about it. Try a port number, verify that the src/dist ip+port combination is available, then go on to the next lport if the guessed one is in use. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita
E.B. Dreger wrote:
I don't think we're even that far along. If I'm reading FreeBSD 4.9 and NetBSD 1.6.2 source correctly,
/usr/src/sys/netinet/in_pcb.c
Should have stretched as far as OpenBSD then. Same file.
tells all.
AFAIK, sequential search is about it. Try a port number, verify that the src/dist ip+port combination is available, then go on to the next lport if the guessed one is in use.
As far as I can see - I have never read the code before, just the commit messages - the OpenBSD version does a circular, random search between high and low targets. Peter
PG> Date: Wed, 21 Apr 2004 07:45:36 +0100 PG> From: Peter Galbavy PG> E.B. Dreger wrote: PG> > I don't think we're even that far along. If I'm reading FreeBSD PG> > 4.9 and NetBSD 1.6.2 source correctly, PG> > PG> > /usr/src/sys/netinet/in_pcb.c PG> PG> Should have stretched as far as OpenBSD then. Same file. Didn't have it handy, too lazy to grab a tarball, and didn't want to overreach. :-) Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.
E.B. Dreger wrote:
PG> Date: Wed, 21 Apr 2004 07:45:36 +0100 PG> From: Peter Galbavy
PG> E.B. Dreger wrote: PG> > I don't think we're even that far along. If I'm reading FreeBSD PG> > 4.9 and NetBSD 1.6.2 source correctly, PG> > PG> > /usr/src/sys/netinet/in_pcb.c PG> PG> Should have stretched as far as OpenBSD then. Same file.
Didn't have it handy, too lazy to grab a tarball, and didn't want to overreach. :-)
CVS Web is da bomb. http://cvsweb.freebsd.org/ http://cvsweb.netbsd.org/ http://www.openbsd.org/cgi-bin/cvsweb/ -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com
On 20-apr-04, at 21:40, Patrick W.Gilmore wrote:
What is a typical receive window on a router? I have been told (have not confirmed) it was about 14 bits.
Cisco routers have a command that will show you this number. It's generally just under 16k. Unfortunately, some looking glasses allow anyone to execute this command...
(Someone check my math. :)
I think your math computes. I was worried for a moment that TCP might be tricked into emitting a packet when you hit the right port combo but the wrong sequence number. It does, and even helps out by sending back the right sequence number. But of course this packet goes to the real correspondent so this shouldn't help the attacker.
participants (15)
-
Crist Clark -
Dan Hollis -
E.B. Dreger -
Iljitsch van Beijnum -
James -
Mike Tancsa -
Owen DeLong -
Patrick W.Gilmore -
Paul Vixie -
Peter Galbavy -
Rodney Joffe -
Simon Lockhart -
Stephen J. Wilcox -
Valdis.Kletnieks＠vt.edu -
vijay gill