For all the viruses, malware, and exploits that crawl around the web, fundamental flaws in the system are supposed to be few and far between, but the last two months have proven to be an exception to the rule. In July, Dan Kaminsky revealed his discovery of a DNS flaw that could be exploited to direct unwitting users to malicious web addresses, Now, practically on the heels of that announcement, a hacker team that presented at DEFCON has demonstrated how a fundamental design error in the Internet's border gateway protocol (BGP) can be used to invisibly eavesdrop on all traffic originating from a particular set of IP blocks.
Neither of these attack vectors are hacks in the typical sense of the word, as Wired's own report explains. Instead of injecting malicious code into a system or systems, the DNS and BGP assaults take advantage of inherent structural weaknesses in the Internet itself. When the ARPANET was under development in the late 60s and early 70s, its designers chose to implement trust-based protocols. At the time, this made sense; ARPANET was a communications network between a relative handful of university and government institutions. The Internet of today has grown beyond the projected size of ARPANET by multiple orders of magnitude. The fact that it has scaled as well as it has is a testament to the engineers who built its foundation as well as those that came later, but the trust-based protocols that made sense in the 1970s don't make sense today.
The flaw in BGP's "trust everyone" system isn't new. In 1998, hacker-turned-security-expert Peiter Zatko (aka Mudge) testified to Congress that the entire 'Net could be brought down via an attack on BGP, but the issue received no serious attention, and development of a safer replacement to BGP that won't break the 'Net has been slow. Earlier this month, Anton Kapela (data center/network director for 5Nines Data) and Alex Pilsov (CEO, Pilosoft) demonstrated an attack that Zatko told Ars is "similar" to his, though some of the particulars differ. In both cases, the fundamental assumptions BGP makes regarding trust are exploited to snoop data within a given range of IP addresses. The first part of their attack is a standard IP hijack, but before we talk about that, let's look at how the BGP system is supposed to function, if everyone plays by the rules.
BGP and IP hijacking
When a router receives a request for information, it responds with an IP address—that's DNS in action. Once the IP address has been received, the router is tasked with finding the best route to that particular location. In order to do this, the router scans its BGP table, where information on routes is stored. The "best" route is the one that corresponds as closely as possible to the address the router is actually looking for.
For example, say that a router is looking for IP address 123.255.189.25 It might find a dozen routers advertising that they connect to 123.xxx.xxx.xx, but that's a very broad location. Presented with its options, the router will choose to send its data to the ISP or other network that's advertising itself as connecting to 123.255.xxx.xxx over sending it to an ISP that just advertises itself as 123. Once the data reaches 123.255, the new router checks its BGP table, and forwards the packets along to the closest address it can find.
This system only works as long as trust is maintained. The router that's requesting information from its BGP table has no way of verifying that the address its forwarding data to is actually the best path. It assumes that it is, because it assumes that the announcements its receiving (ASes) are valid. The first step in an IP hijack is to break that trust, and advertise false information. If a hacker wants to see all of the traffic that's headed towards 123.255.189.25 (or towards that block of addresses), he advertises himself as a router specifically aimed at those addresses. His announcement is picked up, retransmitted, and presto, he's now receiving the information that he wants.
The reason IP hijacking isn't more common is because its pretty darned noticeable. When Pakistan attempted to block YouTube from its citizens, it did so by routing the YouTube addresses into a black hole—a nondestination destination. Unfortunately, that routing information got out into the Internet, circled the globe, and left the entire world without YouTube access. YouTube itself was still there, but no one could see it. This, perhaps, is the most obvious case of (unintentional) IP hijacking ever, but smaller attempts are typically just as obvious to the companies or organizations affected by them. Up until now, interception was easy, but so was detection.
Pilosov and Kapela, however, have found and demonstrated a way to intercept communication and then forward it back along to its original intended recipient. This is normally impossible; having established himself as the most direct router for a given address, any data the hijacker attempts to follow is promptly returned. Pilosov and Kapela bypass this issue by prepending the IP address they feed to certain routers. Prepending refers to attaching additional numbers to their own advertised route, in order to ensure that certain routers reject it. Once a router has rejected their address, the hacker feeds the data to be forwarded on to it. The data is processed and sent to where the router thinks it should go, which means it ends up forwarded on to its intended recipient.
The result? The end-user has no idea anything is happening—and neither does anyone else. According to the team, the redirect method they use leaves virtually no evidence, and would require expert analysis to find. The only way to solve the problem is to develop a system that would allow each step in the process to be signed and certified. There are several different working groups that have tried to develop such a system, and at least one of them, Secure BGP (S-BGP), has been demonstrated as a proof-of-concept solution. Processing the additional certificates, and validating their authenticity, however, would require current-generation routers to devote a significant amount of horsepower to that task, and would impact their ability to handle traffic (assuming they could even handle both tasks simultaneously). Cisco and the various other networking vendors would love to sell new equipment to customers, but first that equipment has to be developed and tested, the new protocol has to be adopted, and the businesses and companies in question have to shoulder the burden of replacing a significant chunk of their own network infrastructure.
Ars spoke to Zatko regarding the seriousness of the BGP vulnerability, and asked whether or not this issue was being blown out of proportion. "I'd put the BGP and DNS attacks at least on par with each other," Zatko told us. "You really need both protocols and infrastructure for everyday use of the Internet. But without DNS, packets can still get from IP address to IP address. The converse does not hold. My friend Dan Kaminsky recently made the well-known DNS cache poisoning trick very easy to pull off. So on that aspect I think the DNS attack might be a bit more accessible to many people."
Unfortunately, Kaminsky's DNS flaw and the BGP exploit Zatko, Pilosov, and Kapela have worked on are different in one very important way. Kaminsky's flaw was not revealed to the public until July, by which point a solution had already been devised and patches were being pushed out to those that needed them. This BGP attack vector, on the other hand, has no hope of an immediate patch, and, as yet, no vendor agreement on which secure protocol to back. SBGP is one option, but Cisco has proposed its own solution (soBGP), and there are several others. Until a protocol is agreed upon, there's no chance of fixing the problem, which means this is one hole that's going to stay open for the foreseeable future.
No comments:
Post a Comment