TCP Vulnerability Published 676
Bob Slidell writes "According to Yahoo!, there is a critical flaw in TCP that affects everyone and everything. The article is scant on details and long on fear, hopefully someone will post more details on this." The advisory has more information, and is long on details but only moderate on fear.
OpenBSD is safe? (Score:5, Informative)
This just hit the misc@openbsd mail list:It sounds (again) like proactive security auditting saves the day!
OSVDB (Score:5, Informative)
TCP Reset Spoofing
OSVDB ID: 4030
Rating: TBD
Disclosure Date: Apr 20, 2004
Description:
The TCP stack implementation of numerous vendors contains a flaw that may allow a remote denial of service. The issue is triggered when spoofed TCP Reset packets are received by the targeted TCP stack, and will result in loss of availability for the the attacked TCP services.
Implementation issue (Score:5, Informative)
Move along, little to see here.
John.
More FUD? (Score:2, Informative)
The Border Gateway Protocol (BGP) is judged to be potentially most affected by this vulnerability.
Run IPSEC the advisory says..o.k so what else is new? IPv4 is inhernetly insecure, we all know that - that's why there is such a thing as packet sniffing, DoS attacks and all the other crap that net admins gotta deal with each and every day.
Re:Mostly Related to BGP? (Score:4, Informative)
Anyway, the way I read it you basically run the TCP attack against a BGP peering router, causing it to drop one or more of it's peering relationships. Do that enough and you can cause the routes being advertised by that router (and also TO that router from the peering connections you're breaking) to be 'dampened' - a protective mechanism in BGP to prevent a flapping route from making all the peers recalculate their routes nonstop.
It's kind of like one peer putting the other one's routes in "time-out" until he plays nice.
NYTIMES ARTICLE (Score:1, Informative)
The flaw affecting the Internet's "tranmission control protocol," or TCP, was discovered late last year by a computer researcher in Milwaukee, Paul ``Tony'' Watson, 36, who said he identified a method to reliably trick personal computers and routers into shutting down electronic conversations by resetting the machines remotely
respect to the hometown hero in finding this...
http://nytimes.com/aponline/technology/AP-Inter
Re:Good (Score:5, Informative)
I wouldn't say TCP is broken or that some other solution would be much better; it would be tough to design a transport protocol that is still simple (and doesnt use CPU burning hashing/encryption techniques) that wouldn't have these sorts of vulnerabilities (especially since it's so easy to spoof IP packets); calling this vulnerability severe is like screaming that highways are fundamentally unsafe because someone could point their car the wrong way and start smashing into oncoming traffic.
-fren
Impact moderate for users, serious for providers (Score:5, Informative)
Service providers on the other hands, must protect their routers because the BGP protocol used to distribute Internet routes between them, massively uses TCP. And when routes go missing, it is hundreds if not thousands of routes to your favourite places that go unreacheable.
The problem in the case of BGP is made worse by dampening [cisco.com], i.e. keeping the flapping routes out of the routing table for a certain amount of time (up to several hours). BGP routes dampening is not always configured. A determined attacker with this knowlege would be able to knock large portions of the Internet offline for hours.
BGP vulnerable (Score:5, Informative)
Empherial source ports (Score:4, Informative)
Of course it is a pure "D'oh" that large TCP windows increase exposure to the older known weakness of TCP RST attacks (Steve Bellovin, wrote a paper [att.com] on it in 1989).
Known issue (Score:5, Informative)
3.2.1.4. TCP RST/FIN/FIN-ACK
RFC3360 (Score:5, Informative)
Re:Mostly Related to BGP? (Score:3, Informative)
Here is what to do... (Score:5, Informative)
NANOG members are talking about it, and several regional Tier-1 players have already issued customer notifications.
This exploit goes up against TCP connections that have been established for long periods of time. i.e. not web connections. The most prevalent would be BGP peer connections, which can be up for days on end easily. Without having read details, or the paper itself, by forging packets of BGP peers with adjusted window sizes, you can cause a router to reset (possibly hang, depending on IOS or JunoOS version, not sure about this) it's BGP peer connection. If you were doing eBGP and had your own AS, a directed attack against your gateway routers could force flapping, which would cause route dampening, and lead to denial of service.
What you need to do, is contact your ISP if you are an enterprise network admin, and establish MD5 authentication on your BGP sessions. Check with Cisco or Juniper and find out if your code will drop non-MD5 BGP packets directed at it. An ACL won't do, the attacker would forge the src-ip of a known peer.
This is a completely non-trivial attack to coordinate. You need to know the IP address of the BGP peer of a customer, or the route reflector, and then get the IP address right in an attempt to bypass ACLs and get the BGP session to hang. eBGP multihop means that IP could be any number of routers, and unless you have inside info, you don't know what it is.
Potentially, looking glasses could be used to mount attacks at NAPs or other peering points, but again, I think the major players will be ready for it very shortly, and will spend most of today (if they are any good) coordinating with legal teams to slam the shit out of any forged sessions they see, and start cooperating to run traces with other providers.
If I could editorialize one moment, none of this would be an issue if providers took better care to implement anti-spoofing techniques. Forged src-ip addresses are the bane of security. Most of these attacks don't care about 2-way communcations, they just want to reset connections. Spoofed src-ip lets them do that. Rant off.
Re:Good (Score:2, Informative)
Re:OpenBSD is safe? (Score:5, Informative)
The Internet BGP tables are ricketey enough these days - they don't need every other route to "flap"!
Re:Good (Score:1, Informative)
This is the authoritative answer to your question.
Slashdotted (Score:2, Informative)
Re:He plans to show the exploit this Thursday! (Score:5, Informative)
- It mainly affects the Border Gateway Protocol (BGP) that occurs at a high level in the net. Few computers are involved.
- The issue was first publicized about a month ago at CanSecWest [cansecwest.com], so those in the know have had a month to work on this.
- The steps to mitigate the problem are a matter of tweaking settings (like window size) or setting up protocols (like encryption). This is not a matter of rewriting the entire protocol.
The article is interesting in that it shows how the bits and pieces of the Internet fit together, but I won't be losing any sleep over this one.BGP is a big deal... (Score:3, Informative)
Re:It's Al Gore's fault... (Score:5, Informative)
Real quote.
What details, the info is already out (Score:5, Informative)
Link to US-CERT TA04-111A (Score:5, Informative)
Re:OpenBSD is safe? (Score:3, Informative)
Unless your business really doesn't care if most of the "internet's routers" are having trouble. My workplace can live very well with reduced internet access/functionality. When they get their troubles sorted out, we'll still be here (and be quite "un-screwed").
Let's get a little acdemic here (Score:2, Informative)
Suppose the TCP Window size is 64K, then the probability of guessing valid ack number is 64K/2^32=1/64K
It means if I spoof 65536 packets, I'll probably bring down a TCP link, if no router ingress filtering is involved.
I guess the solution is also simple: for RST packet, restrict the receiving window size to be much smaller. Because larger window size is only for high speed data transfer and we do not restrict common packets, we are fine.
Re:Stupid (Score:4, Informative)
Re:OpenBSD is safe? (Score:2, Informative)
Re:Known issue (Score:3, Informative)
Known and Old (Score:2, Informative)
See here [internetwk.com] and here [go.com].
- Space Rogue
Simple BGP solution has been around since 1998 (Score:5, Informative)
This has been supported in Cisco IOS way back since ~1998 in IOS 11.2 [cisco.com]
Read the BGP "Bible": Internet Routing Architectures [bookpool.com] or look at any best-practices guides [google.com] which will state that TCP MD5 sigs should always be used with BGP.
Or search CCO [cisco.com]:
router bgp 109
neighbor 145.2.2.2 password v61ne0qkel33&
It's just a single line that has to be added to both peer sides.
Re:Mostly Related to BGP? (Score:2, Informative)
Some BGP sessions would come back up automagically (some might require a manual reset (in Cisco IOS this is known as "clear ip bgp "). However, the attack could just bring them down again (every 4 minutes). BGP dampening would take effect depending on how it is configured upstream or downstream of your router(s). This would cause parts of the Internet to stay down for a long time (at least hours). Attackers could then concentrate on other targets during that time.
OSPF and BGP are not comparable. They work together. Often, BGP requires OSPF (for building a table of valid next-hops) -- but once BGP is used -- there is generally no replacement for it. OSPF would carry routes from router addresses (point-to-point links), and BGP would carry customer and ISP routes. BGP on the Internet carries the necessary 130k routes to allow the Internet to work. OSPF can only carry about 10k routes, and it hurts to even do that. IOW, OSPF does not scale to large networks such as the Internet, but BGP does.
There are many workarounds to this problem, most are identified in the advisory. People who lag behind the times could get hit [hard?] with this vulnerability, so it's always good to check and make sure your network is up to spec.
NISCC slowing, here is the meat summary of article (Score:5, Informative)
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
The real danger. From DoS to remote root. (Score:2, Informative)
2) Think about it.
3) How many of you would notice if your box was down, then when you ssh'd into it because your boss was upset, would keep going inspite of the warning that the SSH key changed.
Pwned!
Re:He plans to show the exploit this Thursday! (Score:3, Informative)
Neither forgotten nor stupid (Score:5, Informative)
A recently published I-D (here [ietf.org]) claims 200 seconds is sufficient time for a broadband sub to successfully attack a TCP session, provided their ISP doesn't use egress filtering (and way too few do so).
This is rather serious. Whether you personally aren't susceptible is irrelevant if your upstreams are.
Re:Protecting routers (Re:Mostly Related to BGP?) (Score:2, Informative)
Find a large network, determine it's topology, hope they're using iBGP for announcing the routes internally to the edge peering routers. Then it's a matter of finding which one to disrupt. Find the right one and a
Wait. Let it come back. Route gets advertised to external peer again.
Repeat 3-4 times until the route is dampened by your victim's peers. Repeat 3-4 more times to get the default maximum 60 minute time-out.
MORE INFO ON VULN (Score:2, Informative)
Looks like MD5 Can save your router...
Re:OpenBSD is safe? (Score:2, Informative)
I didn't run out and check before writing this, so I apologize if things have changed since the last time I looked into OpenBSD.
Re:Neither forgotten nor stupid (Score:5, Informative)
I do realize this likely isn't the case on many networks, but perhaps this will push such sanity (and very simple) filtering to become more widespread.
Re:This is new?? (Score:5, Informative)
You did.
The news here is that you no longer require the sniffer, because you don't have to know the exact sequence number. Now you just have to be kind of close. How close apparently varies in size amongst vendor implementations.
Re:Good (Score:5, Informative)
This exploit along with many others could be made significatly harder to do if more ISP would just turn on anti spoofing rules. I cant think of a router that dosent support at least manual anti spoofing setups. The only time antispoofing might be a problem would be people that are utilizing multiple connections and trying to agrigate them together for outgoing bandwith.
Re:Good (Score:2, Informative)
> unrelated to IP?
The problem stems from the fact that certain TCP state is too easy to guess,
at least partly because TCP stuff is transmitted in the clear over IP. If
you encrypt the traffic at the network (IP) layer, it will help a great deal.
(No, I don't know whether IPv6 does this inherently, though of course it could
be done with IPv6 just as easily as with IP.)
Re:This is new?? (Score:4, Informative)
Previously you had to have a packet sniffer in the middle to sniff the sequence and spoof it. Watson has pointed out a technique that allows you to guess the sequence in practical number of tries for connections that are long-lived (a few days).
Re:NISCC slowing, here is the meat summary of arti (Score:5, Informative)
That took long enough (Score:5, Informative)
This post [google.com] from Alan Cox covers it nicely. Also see the rest of the thread.
Re:Mostly Related to BGP? (Score:2, Informative)
> OSPF inside your own AS. Doesn't that mean, that
> OSPF could never be considered a replacement for
BGP?
BGP is "an" exterior routing protocol, tho its more accurate to say that BGP is "the" exterior routing protocol
OSPF won't scale anywhere near what is needed for the internet. The BGP routing tables have O(100000) routes, and those are summarized to hell and back.
OSFP would so quickly fill up with external routes that your router would fall over quicker than a teenager at spring break.
This is an attack on sequence number, not ports/IP (Score:5, Informative)
This is old news.
For the insanely paranoid use a hardware entropy generator (TRNG) [peertech.org] for choosing ISN's.
There are all sorts of attacks against network protocols when poor random number sources are used. This is but one example...
Re:It's Al Gore's fault... (Score:3, Informative)
Newt Gingrich, 9/1/00:Gore is the person who, in the Congress, most systematically worked to make sure that we got to an Internet.
Al Gore and the Internet
By Robert Kahn and Vinton Cerf
Al Gore was the first political leader to recognize the importance of the Internet and to promote and support its development.
No one person or even small group of persons exclusively "invented" the Internet. It is the result of many years of ongoing collaboration among people in government and the university community. But as the two people who designed the basic architecture and the core protocols that make the Internet work, we would like to acknowledge VP Gore's contributions as a Congressman, Senator and as Vice President. No other elected official, to our knowledge, has made a greater contribution over a longer period of time.
Last year the Vice President made a straightforward statement on his role. He said: "During my service in the United States Congress I took the initiative in creating the Internet." We don't think, as some people have argued, that Gore intended to claim he "invented" the Internet. Moreover, there is no question in our minds that while serving as Senator, Gore's initiatives had a significant and beneficial effect on the still-evolving Internet. The fact of the matter is that Gore was talking about and promoting the Internet long before most people were listening. We feel it is timely to offer our perspective.
As far back as the 1970s Congressman Gore promoted the idea of high speed telecommunications as an engine for both economic growth and the improvement of our educational system. He was the first elected official to grasp the potential of computer communications to have a broader impact than just improving the conduct of science and scholarship. Though easily forgotten, now, at the time this was an unproven and controversial concept. Our work on the Internet started in 1973 and was based on even earlier work that took place in the mid-late 1960s. But the Internet, as we know it today, was not deployed until 1983. When the Internet was still in the early stages of its deployment, Congressman Gore provided intellectual leadership by helping create the vision of the potential benefits of high speed computing and communication. As an example, he sponsored hearings on how advanced technologies might be put to use in areas like coordinating the response of government agencies to natural disasters and other crises.
But, being blinded by ideology is so much MORE fun!
Juniper NetScreen Security Advisory 58784 (Score:5, Informative)
Date: 21 April 2004
Version: 1
Impact:
A design flaw in the RFC specification of TCP may allow a blind attacker to successfully close a TCP connection.
Affected Products:
Juniper NetScreen Firewalls (all versions)
NISCC Reference: Vul/236929
http://www.uniras.gov.uk/vuls/2004/236929/tcp.htm
Max Risk: Medium
Summary:
A blind attacker with limited knowledge of a TCP connection may be able to successfully brute force the TCP Sequence number space and thereby cause a connection endpoint or firewall stateful filter to process a spoofed RST packet and close the connection.
Details:
The TCP Sequence number is one of the mechanisms that TCP uses to prevent a third party from inserting forged packets into the data-stream between two other hosts. While such an attack has always been known to be theoretically possible against TCP, it is was believed that the range of over four billion possible TCP Sequence numbers was large enough to prevent a successful attack. However, recently such an attack has been proven to be feasible in certain situations.
Specifically, if two hosts are known to talk to each other on a regular basis and/or for long periods of time over known port(s) then it may be possible for an attacker to brute force the TCP Sequence number space and successfully inject a forged packet into the connection and possibly disrupt communications. Certain connections, such as BGP4, which are long lived between two devices are especially vulnerable.
While all TCP connections are potentially vulnerable, NetScreen believes that NetScreen firewalls running BGP4 or with TCP Syn-Check enabled are likely to be vulnerable in practice. Other protocols such as SSH, HTTP and SMTP which usually have shorter connection times are less vulnerable.
Recommended Actions:
NetScreen firewall customers should do one or more of the following:
1) Configure Anti-Spoof protection as appropriate.
2) Use secure protocols such as ssh, HTTPS, BGP4 w/ MD5 Authentication
and IPSec which are more resistant to attack.
3) Limit management to dedicated and/or internal interfaces
4) Upgrade to ScreenOS 5.0r6 which enhances the stateful firewall
functionality to protect devices on the network.
Patch Availability:
ScreenOS version 5.0r6 is currently available for Juniper NetScreen firewalls.
How to get ScreenOS:
Customers with a valid product warranty or a support contract may download the software from the Juniper NetScreen CSO web portal:
http://www.juniper.net/support/
For all other customers, including those with expired support contracts, please call your regional Juniper NetScreen TAC center at one of the numbers listed in:
http://www.juniper.net/support/nscn_support/
Select option 2 from the telephone menu and be sure to select the correct product from the phone tree. Once connected with an engineer state that you are calling in regards to a Security Advisory and provide the title of this notice as evidence of your entitlement to the specified release.
As with any new software installation, NetScreen customers planning to upgrade to any version of ScreenOS should carefully read the release notes and other relevant documentation before beginning any upgrade.
Re:It's Al Gore's fault... (Score:2, Informative)
BLITZER: I want to get to some of the substance of domestic and international issues in a minute, but let's just wrap up a little bit of the politics right now.
Why should Democrats, looking at the Democratic nomination process, support you instead of Bill Bradley, a friend of yours, a former colleague in the Senate? What do you have to bring to this that he doesn't necessarily bring to this process?
GORE: Well, I will be offering -- I'll be offering my vision when my campaign begins. And it will be comprehensive and sweeping. And I hope that it will be compelling enough to draw people toward it. I feel that it will be.
But it will emerge from my dialogue with the American people. I've traveled to every part of this country during the last six years. During my service in the United States Congress, I took the initiative in creating the Internet. I took the initiative in moving forward a whole range of initiatives that have proven to be important to our country's economic growth and environmental protection, improvements in our educational system.
OK, this isn't the greatest phraseology, but the gist is that he supported the development of the Internet through legislative initiatives. If you doubt this, there's a nice summary [sethf.com] at Seth Finkelstein's website.
Y'know, I saw this interview when it happened, and I certainly didn't come away with the impression that Al was grandstanding. (This said as an early Bradley supporter... I certainly don't agree with his implication that Bradley *didn't* produce important legislation.) I mean, it's not like he put on a flight suit and strutted around while US soldiers were getting blown to sh*t or anything.
Re:OpenBSD SMP (Score:5, Informative)
Wrong. Very wrong. Are you anaware of this field called "banking"? What about "financial trading"? These firms have huge portfolios and run and re-run various models on them. At night, the systems have to run various "end-of-day" scripts and reports, which take CPU-hours to complete. Most of this things run on Unix...
There is also on-the-fly image manipulation, and the scene-rendering done by fleets of Unix machines. The more CPUs each such Unix machine can fit, the better.
Then come databases -- depending on the queries (with joins and orderings), DB-servers can be CPU bound and appreciate multiple processors when available.
What about PVM [ornl.gov]? What was it -- and similar packages both free and commercial -- written for? What about this proverbial "beowulf clusters"? Of course, it is much better to have several CPUs inside the box, rather than in separate machines.
Until which time, the OpenBSD zealots will continue to deny the issue exists or is of any importance. I see...
IPv6? (Score:2, Informative)
happy 4/20
Re:Server exploit, not router (Score:4, Informative)
Routers from different AS's talk to each other using BGP4. This protocol uses TCP.
The "exploit" uses spoofed packets, so the router will process them as if it came from their neighbour.
So yes, while the router is mostly "shoveling packets", it learns the direction in which to shovel these packets via the exploitable method.
If you want to disagree, feel free to let all the major tier 1 ISPs who have been busily implementing MD5 authentication on their BGP sessions know their wrong.
NYT has an article too (Score:3, Informative)
In the article Watson is quoted as saying that any hacker can figure out this exploit in five minutes from the vaguest explanation. If that's true, why reveal the exploit until someone has figured out how to completely patch it? Or has the fix already been figured out? I couldn't tell from the article.
Re:NISCC slowing, here is the meat summary of arti (Score:4, Informative)
Actually, this is just a variation on an old attack with sequence number guessing. Some OSes have a very poor generator for these numbers (even though the vulnerability is known for ages) and it is possible to exploit it. Probably the most famous attack of this sort was Mitnick's break-in into Shimomura's machine ten years ago.
In practice, these attacks are quite tricky to perform, because they require good timing and quite a bit of skills, so they are quite rare. It is far easier to just exploit some common buffer overflow than this.
The impact could be not only DOS (by resetting the connection), but you can do also packet injection with potential for total system compromise. However, if the protocol used is encrypted (in Shimomura's case it wasn't, if I am not mistaken, Mitnick attacked rsh or rlogin), then the DOS is probably the worst thing that could happen to you. The encryption will reject the bogus packets, if properly implemented.
So, keep calm - this was here since at least 80-ties and there isn't much that you can do against it, except to use encryption. You can only hope, that your system vendor will decide to make their TCP stack less vulnerable (not likely to happen, since many systems still ship with the crappy sequence number generator!). Full fix is not possible anyway, unless you want to break the protocol.
Regards, JanRe:OpenBSD is safe? (Score:4, Informative)
It's actually quite trivial to do. ebgp-multihop and using the remote host loopback address as the neighbor IP, along with a few small architectural configuration tricks are all that's needed to completely prevent this kind of attack, or, at the very least, minimize it significantly.
Are _you_ going to scan, not only the entire range of source ports, but all those ports times the entire RFC1918 address space? Good luck killing my systems, buddy, 'cause that's what you're in for.
Oh, even with the large window sizes, once you've found all the above, you've still got to find my sequence numbers.
Re:OpenBSD is safe? (Score:3, Informative)
What it means is that OpenBSD's tcp stack by default has some of the neccesary protections to slow down or stop this attack, like randomized source ports, randomized TCP ISNs, etc.
Visualizations of OS's TCP seq numbers (Score:4, Informative)
Strange Attractors and TCP/IP Sequence Number Analysis [bindview.com]
Re:OpenBSD is safe? (Score:5, Informative)
Let me be more clear.
This entire thing is being "sold" as `cross-vendor problem'. Sure.
Some vendors have a few small issues to solve in this area. Minor
issues. For us, those issues are 1/50000 smaller than they are for
other vendors. Post-3.5, we have fixes which make the problem even
smaller.
But one vendor -- Cisco -- has an *UTTERLY GIGANTIC HUGE* issue in
this regard, and as you can see, they have not yet made an
announcement see..
You are being told "lots of people have a problem". By not seperating
out the various problems combined in their notice, or the impact of
those problems, you are not being told the whole truth.
More Theo:
OpenBSD (and I am sure other systems too) have for some time contained
partial countermeasures against these things.
OpenBSD has one other thing. The target port numbers have been random
for quite some time. Instead of the Unix/Windows way of
1024,1025,1026,... adding 1 to the port number each time a new local
socket is established... we have been doing random for quite some
time. That means a random selection between 1024 and 49151. This
makes both these attacks 48,000 times harder; unless you already know
the remote port number in question, you must now send 48,000 more
packets to effect a change.
At least one other free operating system incorporated our random port
selection code today..
We've made a few post-3.5 changes of our own, since we are
uncomfortable with the ACK-storm potention of the solutions being
proposed by the UK and Cisco people; in-the window SYN or RST's cause
ACK replies which are rate limited.
At least one other free operating system today incorporated the same
changes......
RFC 2385 (Score:5, Informative)
The primary motivation for this option is to allow BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. Of particular concern are TCP resets.
The date of publishing - August 1998, which makes it about 6 years old.
However the proposed option was primarily meant as a quick BGP fixup, which should've got depricated as soon as IPsec got RFC'ed and deployed. It did went standard few months later, but IPsec implementations enjoyed full share of cross-vendor compatibility problems.
With time Authenticated Header (AH) IPsec protocol didn't see much use or acceptance and IPsec slowly evolved (and keeps evolving) into confidentiality rather than authentication layer.
Besides it's an IP security after all, while the RST spoofing is a TCP problem. And one can quite rightfully percieve authenticating TCP with IPsec as an overkill.
Anyhow, long story short - it's a known and rather old problem with handful of existing and equally unattractive solutions. Perhaps this time around it will be addressed better due to the amount of the publicity it's aimed to get.
Old News... (Score:1, Informative)
Nice try, but no. (Score:3, Informative)
Your solution causes anyone using multiple pipes to transmit at a higher speed to be stopped short and forced through one incoming interface, even though you might have actually been able to handle the traffic.
Re:BGP vulnerable (Score:3, Informative)
It's not MD5 applied higer up in the OSi stack thant TCP, it's a modification to TCP itself that uses MD5: http://www.ietf.org/rfc/rfc2385.txt
Briefly, here's what the sender does: take the usual IP packet, add a secret key, and a checksum of the above, and send that. It's amazing that an electronic Pearl Harbor hasn't happened yet.
Cisco's advisory, workaround & update informat (Score:4, Informative)
Re:Good (Score:2, Informative)
The MD5 protection happens at the TCP layer. Each TCP segment is verified. TCP MD5 could be used for other things than BGP. So yes, TCP MD5 would mitigate the attack sufficiently for now.
THIS ATTACK DOES NOT RELY ON POOR RNG! (Score:3, Informative)
This attack is based on TCP accepting a RANGE of numbers. This range can be artifically widened using forged messages. As a result, it does not matter how good you RNG is, this exploit is about making it easy to search the entire space of possible numbers.
Even if your RNG (Random Number Generator) was perfect, you could still be vulnerable to this attack.
Re:OpenBSD is safe? (Score:4, Informative)
Re:OpenBSD is safe? (Score:2, Informative)
Re:OpenBSD is safe? (Score:2, Informative)
http://www.cisco.com/warp/public/707/cisco-sa-200
and
http://www.cisco.com/en/US/products/products_secu
Re:OpenBSD is safe? (Score:2, Informative)
The Exploit (Score:3, Informative)
linverse@KOS-MOS:~/blackhat/hping2-linv erse$ hping2 [victim.ipaddy] --spoof
[server.ipaddy] --rst --baseport [server.port] --destport [rand()%65536] --setseq
[rand()%((2^32)-1)] --sign "TCP RST Attack"
Each packet sent in this manor has a 1/2^32 chance of succeeding. You need to guess two (effectively) 16 bit numbers: the victim's unknown open port, and the tcp sequence number (within ~16 of its 32 bits, depending on the windowsize) This requires something on the order of 4 billion packets to have a reasonable expectation of closing the connection. There is really no way of knowing if or when a given connection is closed, unless you're taking down routers with it, or some othe observable scenario.
I modified hping2 to spam a victim with these packets. Attempting to reset a local connection with a remote machine takes approximately 20 hours to send the requisite ~4 billion packets. Were these packets to actually travel over a network, it should slow things down significantly.
If one had an army of zombies, then obviously the 20 hour figure can become a 20 minute, or even 20 second figure. But flooding a computer with 4 billion packets in 20 seconds will likely be at least as destructive as the actual payload, except perhaps in the case of major routers communicating over BGP.
Interestingly enough, however, one can still cause massive damage without flooding a single router. Instead, have each of your thousands of zombies try to take down arbitrary routers (perhaps each one sends packets randomly to each known major router). This algorithm allows one to make huge amounts of guesses without saturating the connection to any given router.
If my calculations are correct, then 10000 zombies armed with my exploit and a list of major routers could take them down at a rate of one per 7.2 seconds. At this point, we're talking about serious problems.
Has anybody else done any field testing / analysis?
Re:OpenBSD is safe? (Score:2, Informative)
(In fact, as far as I know, the MD5 option was added to TCP specifically to get round this vulnerability in BGP!)
Patrick
Re:OpenBSD is safe? (Score:2, Informative)
This feature is not very easy to use - both ends of the TCP connection need to know (and configure) a shared secret; this is the major reason why a lot of ISPs haven't set this up already - the router configuration is fairly trivial, what's complicated is co-ordinating with all the ISPs you peer with and arranging a different shared secret with each one (and then getting them to configure the option at exactly the same time that you do!)