The Internet's Biggest Security Hole Revealed

At DEFCON, Tony Kapela and Alex Pilosov demonstrated a drastic weakness in the Internet's infrastructure that had long been rumored, but wasn't believed practical. They showed how to hijack BGP (the border gateway protocol) in order to eavesdrop on Net traffic in a way that wouldn't be simple to detect. Quoting: "'It's at least as big an issue as the DNS issue, if not bigger,' said Peiter 'Mudge' Zatko, noted computer security expert and former member of the L0pht hacking group, who testified to Congress in 1998 that he could bring down the internet in 30 minutes using a similar BGP attack, and disclosed privately to government agents how BGP could also be exploited to eavesdrop. 'I went around screaming my head about this about ten or twelve years ago... We described this to intelligence agencies and to the National Security Council, in detail.' The man-in-the-middle attack exploits BGP to fool routers into re-directing data to an eavesdropper's network." Here's the PDF of Kapela and Pilosov's presentation.

Comments

Re:Fun fun fud

[QuantumG]

Let's put it this way. Email right? It's delivered between hosts completely unencrypted. Imagine you could sniff all the email passing into, say, the white house.. would that be worth something?

Note, I've also given you the hint to prevent this bullshit from being a problem.

Re:SSL

[Free the Cowards]

I don't think anyone thinks that self-signed certs should be blindly accepted.

What should be done is that self-signed certs should be acceptable, with the right handling. The way ssh does this is a good one; it alerts you when you initially connect, and throws up an extremely loud and nasty warning if the host's cert has changed from the last time you connect. This gives you the opportunity to verify the cert out of band if you should care to, and forces an attacker to hit you on your very first access to a given site.

Properly signed certs should be given higher priority, but a self -signed cert is still vastly better than nothing. The problem is that current browsers treat self-signed certs as being the worst of the three, when in reality they're much better than a naked HTTP connection.

I'd trust Mudge on this.

[kwabbles]

The guy's been involved in many of security's moments in history.

If you have BGP peering...

[mbone]

There is a lot of harm you can do, least for a short while. But I have to say, this seems like a lot of FUD to me.

It is not trivial to get BGP peering, or to keep it if you are doing bad things. You will need one or more peers, and they will have to do this for you manually, not automatically. And (as I can attest) the AS prepending this attack relies on is a very blunt instrument.

Here are the troubles I see

- You need to be able to offer a better path from Point A to Point B than the existing Internet topology

- Unless you are Dr. Evil and can afford infinite bandwidth, this better path had better not also apply to a large chunk of the Internet, or you will get hosed with a lot of bandwidth (and, also, instantly stick up on the screens of NOCs all over the place) and

- If you are relying on AS prepends, these affect the path from you, but not directly the path to you. They are notoriously tricky and may stop working (because of changes in other people's advertisements) at any time.

So, to me, this is a might work sometimes for some people in some places, but probably not that well on a general basis.

The DNS cache poisoning sounds a lot worse, frankly.

Re:If you have BGP peering...

[CodeBuster]

You need to be able to offer a better path from Point A to Point B than the existing Internet topology.

It has been done before. In fact for many decades during and after the Cold War the United States offerred some of the best quality data services at the highest speeds for cheap prices (subsidized by your tax dollars) merely to ensure that the majority of the international telephone and non-satellite data traffic passed through the United States somewhere along the way from Point A to Point B.

Unless you are Dr. Evil and can afford infinite bandwidth, this better path had better not also apply to a large chunk of the Internet, or you will get hosed with a lot of bandwidth.

As I mentioned above the US Government can afford a lot of bandwidth when they want to and they want to ensure that as many ISPs around the world chose our fast subsidized fiber backbones (I say backbones because last-mile service for consumers in the US still sucks hard core compared to Korea, Japan, and even Europe) to route their traffic across the globe (i.e. they lease bandwidth from US companies and the data passes through US borders). If some people don't think that US companies are complicit in this, *cough* AT&T *cough*, then the whole telecom immunity debate just went over their heads.

So, to me, this is a might work sometimes for some people in some places, but probably not that well on a general basis.

Better than none of the time so why not try and make the best of it if you can (NSA's point of view).

Re:You can bet good money...

[jd]

If that's the British DHS, the American counterpart is Home Depot, and it should be obvious why they'd want to spy on people. This isn't really a security issue in the same sense broken encryption or the loss of unencrypted data is a security issue, though, so can someone icon and section to "mindless stupidity in protocol design" and/or add "Stone De Croze" to the tags?

A design: X says Y=Z.

[Animats]

I looked at this problem back in the early 1980s, when I was doing some work on TCP. I was trying to come up with a routing protocol that didn't require passing the same information around repeatedly, because backbone networks had very low bandwidth back then, and the existing routing protocols had either O(N^2) traffic or the "hop count to infinity" problem.

I came up with something called "Gateway Database Protocol", which was a scheme for passing tuples of the form "X says Y=Z" around. The idea was that any node seeing inconsistencies in "X says ..." would propagate the tuple back to X, revealing the problem to X.

This is enough to detect hijacking, but not enough to stop it. I'd worked out a scheme good enough to automatically correct erroneous data, but not one good enough to deal with the insertion of hostile data. The design goal back then was to guarantee that if the hostile site was removed from the network (perhaps forcibly), the system would then stabilize into a valid state.

That's not enough any more. But it is worthwhile considering that a routing protocol should have the property that if X's info is being faked anywhere in the network, X hears about it. BGP doesn't do that.

Re:Fun fun fud

[jd]

Let's see. MPLS, SCTP, STP (Scheduled Transfer Protocol), UDP-over-v4, TCP-over-v4, MPLS, UDP-over-v6, TCP-over-V6, IP-over-ATM, IP-over-SCSI, IP-over-IB, IP-over-power, IP-over-carrier-pidgeon, V6-over-V4, V4-over-V6, V6-over-V6, optional recognition of TOS, optional handling of ECN, scalable reliable multicast, anycast, optional recognition of source-based routing, optional recognition of TCP cookies, optional support for packet dropping (RED, GRED, WRED, BLUE, Stochastic Blue, GREEN, BLACK, PURPLE, WHITE), optional support for enhanced authentication packets, IPv6 extended headers, support for unidirectional links, optional support for transitory addressing schemes, optional support for Mobile IP, optional support within Mobile IP for routing realignment, optional support for NEMO, optional use of any of the experimental protocols defined under the names of TUBA, IPv5 and IPv7, anything-over-IPSEC (tunnel or host), anything-over-SKIP -- I've not bothered to keep count, but my Internet link hasn't fallen over yet from diversity. Pity to hear about yours.