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
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:
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.
Sooooooooooooooooooooooooooooooooooo... 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 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.
<snip>
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
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.<snip>
I dont understand why the large differences in claimshttp://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.
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.
A significant number of BGP sessions will be with a source
port of 11000, 11001 or 11002; BGP sessions are generally
quite stable and Cisco routers start the source port at
11000. So attackers could cause enough disruption just
targeting these three source ports. The other thing the
attacker has to guess is which router established the BGP
session. As to IPs which sessions exist on, they can guess
from traceroute each inter-provider hop.
Answering another poster's concern about DoS risk...
TCP MD5 is not a significant DoS risk as you only MD5 once the
source, destination, sequence, etc are valid - ie. you only MD5
a packet which would already have broken your BGP session! [*]
Worse than breaking the session, I'm told by people who have
tested in labs that they could typically break BGP sessions
in under half an hour, which then caused flapping and dampening
of the routes if the attack was repeated. So the risk is not
just the occasional BGP session flap, it's a frequent enough
flap that your routes can be dampened.
So, you're best to implement TCP MD5 on your BGP sessions.
With an up to date IOS, if you both implement the password
within about a second, the BGP session doesn't even flap to
implement the password. Older IOS (12.1) resets the BGP
session as a password is set. Other vendors vary.
David.
[*] in any reasonable implementation. it is possible some old
implementation does this wrong, though.
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.A significant number of BGP sessions will be with a source
port of 11000, 11001 or 11002; BGP sessions are generally
quite stable and Cisco routers start the source port at
11000. So attackers could cause enough disruption just
targeting these three source ports. The other thing the
attacker has to guess is which router established the BGP
session. As to IPs which sessions exist on, they can guess
from traceroute each inter-provider hop.
Really? I certainly hope an attacker tries those three ports on a router I know about. Looking at a random cisco router at a random NAP with a significant number of peers, there are a total of zero session on those ports.
Wow, this attack is even easier to avoid than I thought!
Thanx for proving my point....
Answering another poster's concern about DoS risk...
TCP MD5 is not a significant DoS risk as you only MD5 once the
source, destination, sequence, etc are valid - ie. you only MD5
a packet which would already have broken your BGP session! [*]
Interestingly, cisco confirmed to me the sequence number was not checked until after the MD5 signature was checked.
Again, thanx for proving my point. You really must post more often.
Worse than breaking the session, I'm told by people who have
tested in labs that they could typically break BGP sessions
in under half an hour, which then caused flapping and dampening
of the routes if the attack was repeated. So the risk is not
just the occasional BGP session flap, it's a frequent enough
flap that your routes can be dampened.
I would love to see these results, as I am interested in the methodolofy. For instance, did they turn on a lab router, configure some new BGP sessions, then attack it? Notice that both Richard and I repeatedly say "for a router which has not recently been rebooted". Of *course* it will be easy when you set things up like that.
Even granting the results, flapping a BGP session once per half hour is far from the worst thing 10 Kpps can do on the Internet. In fact, it is probably the *least* damaging thing I have heard miscreants do with 10 Kpss.
So, you're best to implement TCP MD5 on your BGP sessions.
Many people also report taking entire routers down in far less than 30 minutes with 10 Kpps of MD5 signed packets if MD5 is turned on. So I am not sure why this is better - sorry, best - than flapping a session every half hour.
Guess we did not agree on this one. I really think flapping a session every 30 minutes (if it really only takes that long) is not better than killing a whole router in far less time.
With an up to date IOS, if you both implement the password
within about a second, the BGP session doesn't even flap to
implement the password. Older IOS (12.1) resets the BGP
session as a password is set. Other vendors vary.
And how do you track a thousand passwords? Okay, maybe that is not too hard. But how do you guarantee a thousand peers will never screw up and forget, lose, fat-finger, etc. a single one of them? This one I would really like to know, 'cause I sure as hell can't figure it out.
[*] in any reasonable implementation. it is possible some old
implementation does this wrong, though.
Guess IOS counts as both old and unreasonable. I buy that.
Again with the agreement! Well, three out of four ain't bad.
Hi, Patrick.
] Really? I certainly hope an attacker tries those three ports on a
] router I know about. Looking at a random cisco router at a random NAP
] with a significant number of peers, there are a total of zero session
] on those ports.
The ephemeral ports are used for active opens, not passive opens. In
other words there won't be a listener bound on the ephemeral ports.
Try nmap'ing the source port you use to SSH to TCP 22 on a remote
server, for example - same negative result. That doesn't mean it
isn't using the "closed" port as a source port.
Or did I misunderstand the post? I'm low on coffee tonight.
Thanks,
Rob.
And how do you track a thousand passwords? Okay, maybe that is not too hard.
Right
But how do you guarantee a thousand peers will never screw up and forget, lose, fat-finger, etc. a single one of them? This one I would really like to know, 'cause I sure as hell can't figure it out.
If someone forgets a password, you talk on the phone and agree a new one, and apply it to both sides. It's the same kind of procedure that I guess we would follow if peers spontaneously forgot our IP addresses or AS numbers. Or you could just tell them what their password is, since you have all the details in your peering database (see above).
(If the reaction to this is "hey, not everybody has a peering database you know" then people should let me know; we can tidy up and publish the postgres schema that we use if there is interest).
Joe
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> A significant number of BGP sessions will be with a source
> port of 11000, 11001 or 11002; BGP sessions are generally
> quite stable and Cisco routers start the source port at
> 11000. So attackers could cause enough disruption just
> targeting these three source ports. The other thing the
> attacker has to guess is which router established the BGP
> session. As to IPs which sessions exist on, they can guess
> from traceroute each inter-provider hop.Really? I certainly hope an attacker tries those three ports on a
router I know about. Looking at a random cisco router at a random NAP
with a significant number of peers, there are a total of zero session
on those ports.Wow, this attack is even easier to avoid than I thought!
Thanx for proving my point....
OK, if you look at half a dozen routers from vendor C, do a
'sh ip bgp nei | in port', depending on the stability of your
network and peering sessions I would expect at least 1 in 4
will be in the 11000 to 11099 range based on some slightly wider
searching. Granted it's not "the port is always X", but it's
also not true randomization, and most OSs have some constrained
range of ports which will be used (eg. Linux which has a sysctl
tunable "ip_local_port_range") and sequential scanning.
Admittedly, on one large looking glass, I couldn't find any peers
in the 11000 to 11099 range; however that range has been quite
popular in stable production networks I have looked at.
My initial scan covered routers with _very_ stable BGP sessions
(up for months) - for non-multihop BGP, the sessions often come
up just after router reboot and stay up for a very long time.
A few sessions had numbers nowhere near this - which would imply
that once you've killed the existing BGP sessions once, the new
session is likely to use a harder to predict port number if the router
has been up a long time. Unless you can also extract the current
port numbers from the router somehow (remembering that most routers
use sequential allocation); there are some cases where you may be
able to trick a router into making an outbound tcp connection and
look at the source port (if rsh is enabled or there's any other way
to trigger an outbound connection).
Also if the router is a looking glass or is connected to a looking
glass you can find the port number of the looking glass session and
you can then attempt to kill the looking glass session and see what port
number it comes back at, giving you a couple of hints as to the port
number other sessions may be at.
And how do you track a thousand passwords? Okay, maybe that is not too
hard. But how do you guarantee a thousand peers will never screw up
and forget, lose, fat-finger, etc. a single one of them? This one I
would really like to know, 'cause I sure as hell can't figure it out.
The passwords are saved in your router config CVS repository.
They are not encrypted, they are only encoded or stored in plain
text, so you can recover (decode) them if you need to move between
platforms. You can also store them in your tracking system or
wherever else you store such data. Or in the worst case you can
negotiate new passwords if you've lost your records.
And if you're thinking of customer passwords, worried about saving
passwords in your config repository and don't want to augment your
customer information systems with the data -- then you can make
some kind of non-reversible hash (eg. md5-based) to generate the
passwords based on the two BGP peers' IP addresses.
> [*] in any reasonable implementation. it is possible some old
> implementation does this wrong, though.Guess IOS counts as both old and unreasonable. I buy that.
Again with the agreement! Well, three out of four ain't bad.
If this is true, and more CPU is used in checking a MD5 signature
than in checking the ports and sequence number, then I'm sure it
won't be long until someone logs a bug with Cisco to change the
situation.
David.
[...]
Answering another poster's concern about DoS risk... TCP MD5 is not
a significant DoS risk as you only MD5 once the source, destination,
sequence, etc are valid - ie. you only MD5 a packet which would
already have broken your BGP session! [*]
[...]
If only this were true.
Fact of the matter is, MD5 computation/verification is not cheap, and
many Cisco and Juniper platforms aren't designed to handle a barrage
of MD5-hashed TCP packets. We've found that ower-end Cisco gear, like
the kind your customers would use for DS1/DS3 CPE, is particularly
flaky in this regard, though even a Juniper RE2-333-768 could be made
to fall over with < 20mb/s of traffic, as was pointed out earlier.
All things considered, I think MD5 authentication will lower the bar
for attackers, not raise it. I'm sure code optimizations could fix
things to some degree, but that's just not the case today.
Which begs the question, what is one to do, shy of moving (private)
peering/transit/customer /31's and /30's into non-routable IP space,
which opens up an entirely new can of worms? Differentiating between
legitimate "directly connected" and spoofed traffic is a Good
Thing(tm), and the TTL hack sounds great on paper, but isn't exactly
easy to implement when you consider that vendor J and others can't
filter based upon TTL... yet.
[*] in any reasonable implementation. it is possible some old
implementation does this wrong, though.
Try IOS 12.0S, JunOS 6.2, etc... the kind of stuff still in wide
deployment.
-a
Date: Wed, 21 Apr 2004 06:44:14 -0400
From: Adam Rothschild
[T]he TTL hack sounds great on paper, but isn't exactly easy
to implement when you consider that vendor J and others
can't filter based upon TTL... yet.
This is more appropriate for cisco-nsp, where it's already been
covered, but the TTL 255 hack was introduced in 12.0(22)S and
12.3(7)T if memory serves me. Pretty sparse pickings, but I
guess it's a start.
Eddy
How about:
access-list 123 deny tcp any any eq bgp rst log-input
access-list 123 deny tcp any eq bgp any rst log-input
Unfortunately, not all vendors are able to look at the RST bit when filtering...
The general ignorance to the fact that SYN works as well is
astonishing.
What are you talking about?
http://www.uniras.gov.uk/vuls/2004/236929/index.htm
First paragraph of the summary:
"The 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."
You can break TCP sessions not only be injecting harmfully crafted
RST packets, but also with SYN packets.
All talk I see going on is always about harmful RST packets only. Seems
like noone realized that the thread is equally intense with SYN packets.
And:
"It is also possible to perform the same attack with SYN (synchronise)
packets. An established connection will abort by sending a RST if it
receives a duplicate SYN packet with initial sequence number within the
TCP window."
So the attacker sends a spoofed SYN to router A, and router A sends an
RST to router B and router B terminates the BGP session.
I don't see anything in RFC 793 that suggests that "connections in a
synchronized state" should be terminated because of a SYN. Hopefully our
favorite vendors didn't either...
The good part here is that filtering RSTs should still work. The
advantage of that approach is that it moves the problem from the control
plane to the data plane.
> "The 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."And:
"It is also possible to perform the same attack with SYN (synchronise)
packets. An established connection will abort by sending a RST if it
receives a duplicate SYN packet with initial sequence number within the
TCP window."So the attacker sends a spoofed SYN to router A, and router A sends an
RST to router B and router B terminates the BGP session.
Correct.
The good part here is that filtering RSTs should still work.
It doesn't. The RST are then being sent by the authorized sender and
your edge anti-spoof filtering for RST doesn't help a single millimeter.
Now it's your time to overlook something: the filters I listed in my earlier message simply filter RSTs to/from the BGP port without looking at the address fields. Filtering ALL RSTs is probably a bad idea as broken sessions will then have to time out, possibly inconveniencing users (and thereby generating support calls). But for BGP this isn't much of an issue as the BGP hold timer takes care of business here anyway. So I believe filtering out all BGP RSTs on all edges is probably a good idea.