This is serious stuff. (Kim Zetter’s posts on the topic are excellent; read them.)
It’s a man-in-the-middle attack. “The Internet’s Biggest Security Hole” (the title of that first link) has been that interior relays have always been trusted even though they are not trustworthy.
EDITED TO ADD (9/12): This is worth reading.
Sparky • August 29, 2008 7:50 AM
I don’t fully understand the problem, but it looks like it’s a rather big deal, and, most importantly, it seems unfixable without some rather significant changes to the infrastructure (signing and validating the transactions).
Would there be any chance of detecting such an attack by comparing round-trip times from the old, known (and presumed legitimate) route, and the newly advertised one? I’d think the new route would likely have a higher latency. This of course would be far from airtight, but it might make the attack significantly more difficult.
I don’t really see how this would affect encrypted traffic, apart from leaking “you communicated with party X” information, and of course DoS attacks.
nevot • August 29, 2008 7:54 AM
No need to have crypto to be in the middle of a communication to do MITM. The basic MITM attacks are just ARP poisoning some machines on your local network to divert traffic to another machine, and sniffing it prior to divert this traffic to the original receiver.
MITM means that a foreign computer is actively diverting your traffic and passing it to the original receiver (is ‘in the middle’); that’s the difference with eavesdropping, you aren’t in the middle, only ‘listening to the air’. No matter if you are SSLing or not, they’re just in the middle.
Mike • August 29, 2008 7:54 AM
Color me nutty but I’m shrugging at this one. Any ISP or other provider accepting BGP routes from customers that isn’t applying strict whitelist filters to those route announcements is setting themselves up for all sorts of trouble. Additionally, ISPs that know what they’re doing already configure filters to reject announcements of routes they serve exclusively coming in from sources not downstream. Many also use BGP-community policies to ensure that multi-homed customers’ announcements are handled safely.
On the other hand, letting just anyone make routing announcements to you is nuts, and there’s enough in BGP4 plus vendor enhancements to make that extremely difficult. Control a major peering router, and obviously you can cause trouble. The Pakistan YouTube thing wasn’t so much a security snafu as it was a major ISP breaking the rules with shoddy engineering work. Combine that with their peers’ failure to implement decent filters and watch the fireworks.
From the first article: “Filtering also requires ISPs to disclose the address space for all their customers, which is not information they want to hand competitors.”
That’s just dippy. ISPs must disclose the address space for all their customers. That’s their business! It’s all in the registries and the routing tables anyway.
All that said, certificate-based route-origination authentication would be a welcome advance.
Paeniteo • August 29, 2008 8:23 AM
@Carlo Graziani: “no threat to properly-mutually-authenticated-and-keyed encrypted traffic, such as VPN traffic”
Apart from denial-of-service, that is.
neill • August 29, 2008 8:25 AM
unfortunately NONE of the now “classic” protocols was designed with security in mind, it was (understandibly in the 60s) more important to get data into a wire and have it come out again somewhere
wonder when OSPF comes next, re-routed as MITM attack (my router looks better that your banks, right?)
but even new inventions like DNSSEC won’t work unless we have a good PKI
i see ARPSEC, OSPFSEC, UPDSEC etc in the future somewhere someplace
comments on IPV6 anyone?
Sam Greenfield • August 29, 2008 8:31 AM
Dan Kaminsky has a fairly good discussion of this vulnerability as it relates to other Internet security flaws on his blog post entitled, The Emergence Of A Theme.
Sam Greenfield • August 29, 2008 8:32 AM
Sorry, the blog software stripped out the HTML. Dan Kaminsky’s blog post is at http://www.doxpara.com/?p=1231
vwm • August 29, 2008 8:48 AM
@Sparky, the round trip time will change whenever the route changes — that way you can not identify legitimate route changes from illegitimate ones.
The illegitimate route might even appear faster if the victim is closer to the hijacker than to the hijacked resource.
neill • August 29, 2008 8:55 AM
thanks, sam – really good and scary stuff there!
the biggest problems we face is that companies make more money selling products/connectivity etc so the economic pressure does not allow time for implementing/testing security, and we have billions of users/networks now out there, run for and by people that have no clue how they work (and how to protect themself!) and not only geeks/darpa people anymore!
David • August 29, 2008 9:09 AM
@Carlo,
Not necessarily. If you are establishing the tunnel, or SSL link, it can be proxied by the new “MIM”.
In theory it should be possible to act as the end point, and have the connection from you to to the MIM be encrypted, and from the MIM to the end-point be encrypted, but the thin slice in the middle be un-encrypted and fully readable.
It’s not as simple just saying “it’s encrypted”, and can’t be sniffed.
Student • August 29, 2008 9:23 AM
Most people working with BGP yawns. It’s a well known security problem, one that is solved by only peering with trusted people and using whitelists.
There are attempts to solve this problem using cryptography, for example sBGP. However, as far as I know all the current tries to secure BGP falls on the overhead. You simply can’t do PK cryptography fast enough on the limited hardware found in routers. Currently the global routing table has some 400’000 entries. Imagine verifying a signature for each entry on a 486 computer….
Even if they get sBGP fast enough the implementation is non-trivial in running networks. It requires cooperation from many sides and BGP is not something most organisations wants to mess with. So until this kind of attacks gets common enough, or distruptive enough, to make it infeasable to solve the problem simply by breaking peering with the offenders I doubt much will happen beyond better automatisation of the white lists.
Janet • August 29, 2008 9:37 AM
This is not news, the news is this: “that this is news.” I cannot believe how many people are surprised by this. This was solved, and then unsolved, 15 years ago. Look into NSFnet and NACR… then watch as it morphed into routing registries eg: IRR and RIPE. People hated NACRs and cursed the NSFnet for requiring them. When the NSFnet shut down in ’94 people were so happy to be released from the oppressive burden. Now we see this all over again. I am not trying to take anything any from Mr Kapela, he’s a hell of a guy and it’s good that he is getting the problem some press (it’s like full disclosure for the Internet), but I think that until the users have enough clue to demand clueful behaviour from their providers, this is just a homo sapiens urinat in ventum.
Anonymous • August 29, 2008 10:18 AM
@David
Of course I’m not saying anything like “it’s encrypted, and can’t be sniffed.” I’m saying that from the point of view of classic cryptological MITM, (1) shared secret-key authenticated/encrypted comms is not affected (it never is by MITM), and (2) PK encrypted/authenticated comms that are validated by some SSL-like chain-of-trust mechanism is also not affected, because even if you route my traffic through your evil router, you don’t have Verisign’s (say) secret key, so if you play SSL games my VPN app or my browser will bitch about your phony certificates.
That leaves ssh, which doesn’t do trusted third-party vouching, but does warn about changing host keys. This is a potential “wetware” weakness, to be sure, if users ignore those warnings, or don’t at least check that there’s a legit reason for the key change. Still, that seems a little thin to call this a MITM attack, with the cryptological freight that that term carries (which is more than just “someone in the middle looking at the data stream, @nevot).
Shane • August 29, 2008 10:29 AM
Just another perfect example of how the free market fails until the consumer base is educated enough to start demanding change.
This issue as as old as the internet itself and has been touted for at least a decade now, but until people start educating themselves about these vulnerabilities, our wonderfully greedy economic model (read: the corporations that run our country) won’t do a damn thing to fix it if it means lowering profit margins.
MikeA • August 29, 2008 10:29 AM
An awful lot of armchair routing experts here today. Yes, BGP can be “bent”. Yes, the attacks, and countermeasures, have been known for a while. Meanwhile, look into “port mirroring”. Yep, router (and switch) manufacturers have included the ability to wiretap on command from, well, those who command, for years. As for VPN/DOS, a major U.S. ISP apparently makes a practice of forging RST packets for connections that are encrypted and “last a while”. Presumably on the basis that “you must be guilty” (of copyright infringement) “or you wouldn’t try to hide.” All of which adds up to “Yawn, and the sun rose this morning, too”
BTW: a router with any business handling 400,000 routes has a lot better than 486 running its route-processing, and has a hierarchy of processing elements of varying speed/generality doing the grunt work. It’s not just your Grandma’s handmedown running Ubuntu and IP forwarding (well, for some ISPs it might be 🙂
SteveJ • August 29, 2008 10:39 AM
In terms of eavesdropping content, this is a big deal only for the moderately paranoid, as far as I can tell. The non-paranoid don’t care, and the truly paranoid don’t trust internet routers in the first place.
Like Bruce says, “interior relays have always been trusted even though they are not trustworthy”. But as far as I’m concerned, my ISP isn’t trustworthy either. The fact that it believes some route advertised from Pakistan is not substantially different from the fact that it lets government agencies install taps (with or without court order), or that it sells my traffic to spammers (Phorm, NebuAd, whoever), or keeps traffic logs that could in theory fall into malicious hands, or whatever else it does as part of running its business.
If I don’t trust my ISP, I don’t have to care who it in turn thinks is trustworthy.
@carlo: the other thing that an attacker could gain from hijacking routes used for VPN is traffic data – an eavesdropper would know what IP addresses you’re connecting to even though unable to see the data in the tunnel. It’s not a huge amount of information, but it’s more than an attacker outside your regular route would otherwise be able to see.
@David: properly-configured SSL or TLS cannot be eavesdropped by observing or manipulating the traffic between the endpoints. It’s as simple as saying “it’s encrypted and authenticated therefore it can’t be sniffed”.
Unfortunately, you do need users to know what they’re doing, and not to accept self-signed server certificates. For websites you also need servers which know what they’re doing, and don’t just redirect from an insecure landing page to an SSL-protected login page (or at least if they do that, you need the user to check the URL and/or cert, which is an unreliable assumption IMO). Finally, you need a decent PKI (which occasionally has gone wrong for SSL, but is usually easier for VPN because you copy the server certificate safely on to the client prior to your trip into the wild).
Furthermore, SSLv2 is weak and shouldn’t normally be used.
So you’re right that avoiding MITM isn’t quite as simple as it looks, but it is at least achievable with SSL/TLS/VPN. Same goes for SSH with port forwarding.
sooth sayer • August 29, 2008 10:43 AM
It’s man in the middle all-right; a stupid man who happens to be the programmer in this case.
(Luckily we will be free to call it woman-in-the middle soon .. thanks to Sarah Palin)
This sensationalism has to stop somewhere — Bruce you should stop highlighting some drivel.
This is NOT technology — but plain stupidity and there is no cure for it.
It’s akin to listening to a charlatan that your house is on fire and dousing it with water.
Anon Network Arch • August 29, 2008 11:05 AM
Even if they get sBGP fast enough the implementation is non-trivial in running networks.
sBGP is not going to solve the problem. The burden of a full cert verification on all BGP UPDATE messages is going to be too much. Even if it weren’t, the problem is not a technical one. As someone already hinted, the problem is that routes don’t have to be registered. There is no requirement to maintain a authorative database on who got what address space and can/is allowed to announce it. This is a fundamental requirement for all solutions, including sBGP. Once this exists, route filtering can take place at various positions in the chain. There are less resource intensive (technical as well as organisational) ways to ensure not everybody can announce everything. sBGP is ways overkill and is ignoring the real problem: a authorative source for the data required.
Carriers don’t see it as their responsibility. It’s not on the radar for most of them, and if it appears, it’s often seen as a cost factor that doesnt do anything positive to the bottom line. In that regard, it’s similiar to most IT security topics …
Jed Davis • August 29, 2008 11:15 AM
@neill: IPv6 replaces ARP with ICMPv6 Neighbor Discovery, and if I recall correctly the relevant RFC explicitly points out that this allows stacking it on top of IPsec.
Dealing with key management in that situation is left as an exercise for the reader….
David • August 29, 2008 11:38 AM
@Steve; @Anon
Yes, if you do the VPN, and/or SSL/SSH correctly then it is significantly more immune to attack.
You are, unfortunately, assuming a lot that most “end users” are not going to do especially the PKI, and authentication of the end points.
FYI: There are over 17,000 pages listed for “ssl mim attack” on google. I can’t find any references quick, but my memory tells me that it’s been done in the wild.
Anonymous • August 29, 2008 11:52 AM
@Janet
You said it Janet! I remember talking about this potential wwwaaaaayyyy back on NSFnet, I think it was 1987.
Student • August 29, 2008 12:18 PM
@MikeA
You would be shocked if you knew what kind of hardware some ISP’s have to use to keep their networks running. Not everybody can afford the latest Cisco branded equipment…
@Anon Network Arch
As I see it it’s a bit of a chicken-or-egg problem. No up to date db, then it’s no point implementing strict enforcement. No strict enforcement, then people don’t keep the DB up to date. I agree that sBGP might be overkill, and too computational intensive, but I have yet to see a better implementation of the enforcement. Perhaps lazy checking of updates would be the solution to keep BGP responsive (and withdraw routes that fail checks). But it’s generally a can of worms.
If we want to secure BGP it has to be as easy as turning it on sBGP and then just let things run, or most people will ignore it. Just like they don’t use whitlists or do any other filtering. Demanding that all your peers uses sBGP is a simple management solution, but then sBGP has to work (TM), which it doesn’t do yet.
David Donahue • August 29, 2008 12:40 PM
If ever there was a case that drives home the need for full disclosure in security vulnerabilities, this is it. Mudge pointed out to all the right people “screaming [his] head about this, about ten or twelve years ago….”
The parties responsible for fixing this knew 10-12 YEARS ago that this was broken and could be exploited to devastating effect, but because it was not public, it never became a priority to get fixed.
If one had the “secret knowledge”, you could monitor anyone’s traffic. A lot of bad guys, hostile governments and intelligence folks had this knowledge but because they don’t publicly release their tricks (they exploit them instead) It never hit the news.
Without the threat of public embarrassment and / or a direct effect on the bottom line, almost nothing gets fixed.
Eoghan • August 29, 2008 1:43 PM
@David Donahue
It wasn’t necessarily “broken” back then, nor on NSFnet as anon says, because back then, a simpler time, levels of trust were greater and expectations of behaviors existed… “back then”.
But now its anyone’s game and no part of portion of the network is safe. This problem goes back to ASNs and ES-ES, IS-IS routing, which BGP was created to aid with. One expected back then that the BGP and IGP routers would be fairly well protected.
Consider the complexity now compared with the complexity 15 – 20 (yes, 15-20) years ago.
Antonio Varni • August 29, 2008 1:49 PM
SSL won’t save you. If you can DNS poison any link in the chain of mail servers involved in the issuance of a ‘domain only validation’ SSL cert – you can get an SSL cert for the target and use the BGP attack to proxy the encrypted SSL traffic.
Anon Network Arch • August 29, 2008 1:57 PM
@Student
sBGP won’t help the enforcement. This was already tried by a few responsible networks who cared, but most didn’t. So what happened is that some larger carriers created proxy entries for clueless customers. Since there are many organisations without a clue what they’re doing running BGP, some of their upstreams created proxy entries in RADB for example. This can theoretically be avoided with a propper chain of certs but unless it comes from the address assigning authorities it won’t solve the problem. The address assigning authorities can do this without certs already. At RIPE you can not just create a route: object without having been assigned the corresponding inetnum: object.
The main problem here is not a technical one. It’s a administrative/operational one. I’d say at least 80% of all organisations and people participating in the Default Free Zone simply don’t care about the security of it.
grin • August 29, 2008 2:18 PM
For example BIX (Budapest Internet Exchange, but I guess many others) use RIPE routing db for filtering. If you don’t keep your data fresh you cannot communicate, period. Makes people update their data, it seems somehow.
But I guess it doesn’t yet work planetwide. It Should. These records are authenticated (from average up to pretty good level, and if people would use ’em seriously it could be make secure enough), so it’s not easy to fake them, and would make it really futile to try to poison the whole ‘Net when backbone providers would filter it automagically.
jason • August 30, 2008 12:57 AM
Tony and Alex never claimed that this attack was new. In fact, they’ve stated a number of times during their presentation and in other public forums that it was not new and that it would not be surprising to anyone that groks BGP.
What was new according to them was using AS-prepending to complete the MITM circuit, and TTL tricks to hide the hops. The importance of these is due to the fact that, until now, BGP hijacks caused outages which were noticed (see the aforementioned YouTube vs. Pakistan for a perfect example).
Now they won’t need to. Like most clever hacks, now that it has been made known, it seems obvious; but as far as I know, nobody has discussed prepending the original AS path to a hijacked route to avoid detection prior to the talk Tony and Alex gave.
That is why this is such big news.
SteveJ • August 30, 2008 8:15 AM
@David: “There are over 17,000 pages listed for “ssl mim attack” on google”
Sure, and there are 127,000 for ‘magic pink unicorn’, but that doesn’t necessarily mean they exist 😉
I totally agree though that SSL has a serious flaw as a security measure, that it is simply too difficult to use reliably. Self-signed certs, domain-only certs, insecure content on secure pages, insecure redirects, homoglyph URLS with IDN, tricking users into installing root certificates: all these things are defended against only if the user has sophisticated knowledge of the protocol and the PKI that supports it. That’s even before “core” problems like inadequate identity checking by CAs.
Getting public keys from the server out-of-channel is much safer, but obviously has limited applicability.
My original point really was just supposed to be that if you are able to use SSL/TLS/VPN safely, then that usage isn’t endangered by malicious BGP routers (aside from DoS). Carlo said there was no threat to ‘properly-mutually-authenticated-and-keyed encrypted traffic’, which is correct. The problem is that SSL isn’t necessarily ‘properly mutually authenticated’.
Clive Robinson • August 31, 2008 2:21 PM
I’m not sure that sBGP will solve the problem. It’s a question of “rotten apples” and “garbage in garbage out”.
Further PKI has problems in that first of not everybody trusts a particular root and for other commercial/operational reasons would not chose to use a particular root.
We have seen problems with users and browsers with built in root certificates and automaticaly accepting a chain of certificates.
I’m not sure just how many BGP routers there are out there nor how many could be considered authorative. However it is going to be in the tens of thousands.
If you take a country like the U.K. It has 85,000 currentl “criminals” locked up for a population of around 60 million. On a lose assumption that only 1 in 7 criminals are locked up at any one time then the U.K. Has something like 595,000 criminals or 1% of the population.
If there are only 10,000 BGP routers with authority then potentialy there are 100 “rotten apples” sBGP is not going to solve this problem.
Further as seen by the U-tube issue, it can be seen that human error is a considerably bigger threat than criminal activity. When you then consider some of the very small organisations running BGP and their bare minimum (or less) skill level what are the chances that they are going to be able to do the job properly or reliably?
I think that perhaps after 20 odd years of ignoring the issue it is time we re thought the whole problem from the ground up afterall BGP was brought in to solve other problems with earlier protocols, perhaps it has outlived it’s usefulness entirley.
Why should I care?
Whenever sending anything over the Internet, you already have to assume that the data will be read by someone you do not trust. This only adds the risk of the data being read by some more people you do not trust. Not much worse.
Kim Zetter’s post also show lack of understanding of BGP:
If the destination IP address falls within both announcements, BGP will send data to the narrower, more specific one.'' --- BGP, of course, only chooses between advertisements for the same prefixFiltering also requires ISPs to disclose the address space for all their customers, which is not information they want to hand competitors.” — well, letting others know what your address space is and where to route is is exactly the point of BGP.
All in all, I think the panic is slightly unnecessary.
Peter Maxwell • September 18, 2008 2:29 PM
Eh, as far I know Mike’s on 29th August is nearer the truth… any decent ISP’s border routers shouldn’t accept any olde BGP advertisement. I’m slightly surprised the attack actually worked in the demonstration.
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
Carlo Graziani • August 29, 2008 7:43 AM
“It’s a man-in-the-middle attack.”
Hm, I thought that MITM was a cryptological term of art. If I read this right, there is no threat to properly-mutually-authenticated-and-keyed encrypted traffic, such as VPN traffic. The route that the traffic takes is warped to pass through an attacker’s router for analysis, but Alice and Bob have nothing to fear about leaks from their VPN tunnel, or their ssh connection, or even their SSL-encrypted web commerce session (assuming Alice takes the browser’s certificate warnings seriously). Or am I missing something?