Revealed: The Internet's Biggest Security Hole

Gadi Evron ge at
Wed Aug 27 19:54:26 CDT 2008

"new". hehe

Maybe something will change now' though, it was a great and impressive 
presentation, hijacking the defcon network and tweaking TTL to hide it.

On Thu, 28 Aug 2008, Frank wrote:

> Two security researchers have demonstrated a new technique to stealthily
> intercept internet traffic on a scale previously presumed to be unavailable
> to anyone outside of intelligence agencies like the National Security
> Agency.
> The tactic exploits the internet routing protocol BGP (Border Gateway
> Protocol) to let an attacker surreptitiously monitor unencrypted internet
> traffic anywhere in the world, and even modify it before it reaches its
> destination.
> The demonstration is only the latest attack to highlight fundamental
> security weaknesses in some of the internet's core protocols. Those
> protocols were largely developed in the 1970s with the assumption that every
> node on the then-nascent network would be trustworthy.  The world was
> reminded of the quaintness of that assumption in July, when researcher Dan
> Kaminsky disclosed<>a
> serious vulnerability in the DNS system. Experts say the new
> demonstration
> targets a potentially larger weakness.
> "It's a huge issue. 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.
> Anyone with a BGP router (ISPs, large corporations or anyone with space at a
> carrier hotel<>)
> could intercept data headed to a target IP address or group of addresses.
> The attack intercepts only traffic headed *to* target addresses, not from
> them, and it can't always vacuum in traffic within a network -- say, from
> one AT&T customer to another.
> The method conceivably could be used for corporate espionage, nation-state
> spying or even by intelligence agencies looking to mine internet data
> without needing the cooperation of ISPs.
> BGP eavesdropping has long been a theoretical weakness, but no one is known
> to have publicly demonstrated it until Anton "Tony" Kapela, data center and
> network director at 5Nines Data <>, and Alex
> Pilosov, CEO of Pilosoft <>, showed their technique
> at the recent DefCon hacker conference. The pair successfully intercepted
> traffic bound for the conference network and redirected it to a system they
> controlled in New York before routing it back to DefCon in Las Vegas.
> The technique, devised by Pilosov, doesn't exploit a bug or flaw in BGP. It
> simply exploits the natural way BGP works.
> "We're not doing anything out of the ordinary," Kapela told
> "There's no vulnerabilities, no protocol errors, there are no software
> problems. The problem arises (from) the level of interconnectivity that's
> needed to maintain this mess, to keep it all working."
> The issue exists because BGP's architecture is based on trust. To make it
> easy, say, for e-mail from Sprint customers in California to reach
> Telefonica customers in Spain, networks for these companies and others
> communicate through BGP routers to indicate when they're the quickest, most
> efficient route for the data to reach its destination. But BGP assumes that
> when a router says it's the best path, it's telling the truth. That
> gullibility makes it easy for eavesdroppers to fool routers into sending
> them traffic.
> Here's how it works. When a user types a website name into his browser or
> clicks "send" to launch an e-mail, a Domain Name System server produces an
> IP address for the destination. A router belonging to the user's ISP then
> consults a BGP table for the best route. That table is built from
> announcements, or "advertisements," issued by ISPs and other networks --
> also known as Autonomous Systems, or ASes -- declaring the range of IP
> addresses, or IP prefixes, to which they'll deliver traffic.
> The routing table searches for the destination IP address among those
> prefixes. If two ASes deliver to the address, the one with the more specific
> prefix "wins" the traffic. For example, one AS may advertise that it
> delivers to a group of 90,000 IP addresses, while another delivers to a
> subset of 24,000 of those addresses. If the destination IP address falls
> within both announcements, BGP will send data to the narrower, more specific
> one.
> To intercept data, an eavesdropper would advertise a range of IP addresses
> he wished to target that was narrower than the chunk advertised by other
> networks. The advertisement would take just minutes to propagate worldwide,
> before data headed to those addresses would begin arriving to his network.
> The attack is called an IP hijack and, on its face, isn't new.
> But in the past, known IP hijacks have created outages, which, because they
> were so obvious, were quickly noticed and fixed. That's what occurred
> earlier this year when Pakistan Telecom
> inadvertently<>hijacked
> YouTube traffic from around the world. The traffic hit a dead-end
> in Pakistan, so it was apparent to everyone trying to visit YouTube that
> something was amiss.
> Pilosov's innovation is to forward the intercepted data silently to the
> actual destination, so that no outage occurs.
> Ordinarily, this shouldn't work -- the data would boomerang back to the
> eavesdropper. But Pilosov and Kapela use a method called AS path prepending
> that causes a select number of BGP routers to reject their deceptive
> advertisement. They then use these ASes to forward the stolen data to its
> rightful recipients.
> "Everyone ... has assumed until now that you have to break something for a
> hijack to be useful," Kapela said. "But what we showed here is that you
> don't have to break anything. And if nothing breaks, who notices?"
> Stephen Kent, chief scientist for information security at BBN Technologies,
> who has been working on solutions to fix the issue, said he demonstrated a
> similar BGP interception privately for the Departments of Defense and
> Homeland Security a few years ago.
> Kapela said network engineers might notice an interception if they knew how
> to read BGP routing tables, but it would take expertise to interpret the
> data.
> A handful of academic groups <> collect BGP
> routing information <> from
> cooperating ASes to monitor BGP updates that change traffic's path. But
> without context, it can be difficult to distinguish a legitimate change from
> a malicious hijacking. There are reasons traffic that ordinarily travels one
> path could suddenly switch to another -- say, if companies with separate
> ASes merged, or if a natural disaster put one network out of commission and
> another AS adopted its traffic. On good days, routing paths can remain
> fairly static. But "when the internet has a bad hair day," Kent said, "the
> rate of (BGP path) updates goes up by a factor of 200 to 400."
> Kapela said eavesdropping could be thwarted if ISPs aggressively filtered to
> allow only authorized peers to draw traffic from their routers, and only for
> specific IP prefixes. But filtering is labor intensive, and if just one ISP
> declines to participate, it "breaks it for the rest of us," he said.
> "Providers can prevent our attack absolutely 100 percent," Kapela said.
> "They simply don't because it takes work, and to do sufficient filtering to
> prevent these kinds of attacks on a global scale is cost prohibitive."
> Filtering also requires ISPs to disclose the address space for all their
> customers, which is not information they want to hand competitors.
> Filtering isn't the only solution, though. Kent and others are devising
> processes to authenticate ownership of IP blocks, and validate the
> advertisements that ASes send to routers so they don't just send traffic to
> whoever requests it.
> Under the scheme, the five regional internet address registries would issue
> signed certificates to ISPs attesting to their address space and AS numbers.
> The ASes would then sign an authorization to initiate routes for their
> address space, which would be stored with the certificates in a repository
> accessible to all ISPs. If an AS advertised a new route for an IP prefix, it
> would be easy to verify if it had the right to do so.
> The solution would authenticate only the first hop in a route to prevent
> unintentional hijacks, like Pakistan Telecom's, but wouldn't stop an
> eavesdropper from hijacking the second or third hop.
> For this, Kent and BBN colleagues developed Secure BGP (SBGP), which would
> require BGP routers to digitally sign with a private key any prefix
> advertisement they propagated. An ISP would give peer routers certificates
> authorizing them to route its traffic; each peer on a route would sign a
> route advertisement and forward it to the next authorized hop.
> "That means that nobody could put themselves into the chain, into the path,
> unless they had been authorized to do so by the preceding AS router in the
> path," Kent said.
> The drawback to this solution is that current routers lack the memory and
> processing power to generate and validate signatures. And router vendors
> have resisted upgrading them because their clients, ISPs, haven't demanded
> it, due to the cost and man hours involved in swapping out routers.
> Douglas Maughan, cybersecurity research program manager for the DHS's
> Science and Technology Directorate, has helped fund research at BBN and
> elsewhere to resolve the BGP issue. But he's had little luck convincing ISPs
> and router vendors to take steps to secure BGP.
> "We haven't seen the attacks, and so a lot of times people don't start
> working on things and trying to fix them until they get attacked," Maughan
> said. "(But) the YouTube (case) is the perfect example of an attack where
> somebody could have done much worse than what they did."
> ISPs, he said, have been holding their breath, "hoping that people don't
> discover (this) and exploit it."
> "The only thing that can force them (to fix BGP) is if their customers ...
> start to demand security solutions," Maughan said.

More information about the NANOG mailing list