http://www.wired.com/threatlevel/2013/12/bgp-hijacking-belarus-iceland/ Someone’s Been Siphoning Data Through a Huge Security Hole in the Internet BY KIM ZETTER12.05.136:30 AM Hijacked traffic went all the way to Iceland, where it may have been copied before being released to its intended destination. The green arrows show the path the traffic should have traveled; the red arrows show the path it took. Map courtesy of Renesys In 2008, two security researchers at the DefCon hacker conference demonstrated a massive security vulnerability in the worldwide internet traffic-routing system — a vulnerability so severe that it could allow intelligence agencies, corporate spies or criminals to intercept massive amounts of data, or even tamper with it on the fly. The traffic hijack, they showed, could be done in such a way that no one would notice because the attackers could simply re-route the traffic to a router they controlled, then forward it to its intended destination once they were done with it, leaving no one the wiser about what had occurred. Now, five years later, this is exactly what has happened. Earlier this year, researchers say, someone mysteriously hijacked internet traffic headed to government agencies, corporate offices and other recipients in the U.S. and elsewhere and redirected it to Belarus and Iceland, before sending it on its way to its legitimate destinations. They did so repeatedly over several months. But luckily someone did notice. And this may not be the first time it has occurred — just the first time it got caught. Analysts at Renesys, a network monitoring firm, said that over several months earlier this year someone diverted the traffic using the same vulnerability in the so-called Border Gateway Protocol, or BGP, that the two security researchers demonstrated in 2008. The BGP attack, a version of the classic man-in-the-middle exploit, allows hijackers to fool other routers into re-directing data to a system they control. When they finally send it to its correct destination, neither the sender nor recipient is aware that their data has made an unscheduled stop. The stakes are potentially enormous, since once data is hijacked, the perpetrator can copy and then comb through any unencrypted data freely — reading email and spreadsheets, extracting credit card numbers, and capturing vast amounts of sensitive information. The attackers initiated the hijacks at least 38 times, grabbing traffic from about 1,500 individual IP blocks — sometimes for minutes, other times for days — and they did it in such a way that, researchers say, it couldn’t have been a mistake. Renesys Senior Analyst Doug Madory says initially he thought the motive was financial, since traffic destined for a large bank got sucked up in the diversion. But then the hijackers began diverting traffic intended for the foreign ministries of several countries he declined to name, as well as a large VoIP provider in the U.S., and ISPs that process the internet communications of thousands of customers. Although the intercepts originated from a number of different systems in Belarus and Iceland, Renesys believes the hijacks are all related, and that the hijackers may have altered the locations to obfuscate their activity. “What makes a man-in-the-middle routing attack different from a simple route hijack? Simply put, the traffic keeps flowing and everything looks fine to the recipient,…” Renesys wrote in a blog post about the hijacks. “It’s possible to drag specific internet traffic halfway around the world, inspect it, modify it if desired, and send it on its way. Who needs fiberoptic taps?” Earlier this year someone mysteriously hijacked internet traffic headed to government agencies, corporate offices and other recipients and redirected it to Belarus and Iceland (above). Photo: Image Source/Getty Renesys cautions that it doesn’t know who is behind the hijacks. Although systems in Belarus and Iceland initiated the hijacks, it’s possible that those systems were hijacked by a third party that simply used them as a proxy for the attacks. Either way, one thing is certain, Madory says: the characteristics of the hijacks indicate they were intentional. Some of the targets whose traffic was hijacked seemed hand-picked by the attackers, he says, especially the foreign ministry domains. “It’s a list [of targets] that you just wouldn’t come by mistake,” Madory told WIRED. The hijackers also appeared to tweak their attack over time to modify and refine it. “In the Belarus example, we saw an evolution of the technique of someone manipulating the attributes of the BGP messages to try to achieve this man-in-the-middle thing,” he said. “To us, that communicated some intention versus a mistake.” BGP eavesdropping has long been a known weakness, but no one is known to have intentionally exploited it like this until now. The technique doesn’t attack a bug or flaw in BGP, but simply takes advantage of the fact that BGP’s architecture is based on trust. To make it easy for e-mail traffic from an ISP in California to reach customers of an ISP in Spain, networks for these providers and others communicate through BGP routers. Each router distributes so-called announcements indicating which IP addresses they’re in the best position to deliver traffic to, for the quickest, most efficient route. But BGP routers assume that when another router says it’s the best path to a specific block of IP addresses, it’s telling the truth. That gullibility makes it easy for eavesdroppers to fool routers into sending them traffic they shouldn’t get. When a user types a website name into his browser or clicks “send” to launch an e-mail, a router belonging to the sender’s ISP consults a BGP table for the best route to the destination. That table is built from the announcements issued by ISPs and other networks 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, and if two systems deliver traffic for the address, the one with the narrower, more specific range of prefixes “wins” the traffic. For example, one ISP announces 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 of these, the e-mail will get sent to the narrower, more specific one. To intercept data, anyone with a BGP router or control of a BGP router could send out an announcement for a range of IP addresses he wished to target that was narrower than the chunk advertised by other network routers. The announcement would take just minutes to propagate worldwide and, just like that, data that should have headed to those networks would begin arriving to the eavesdropper’s router instead. Ordinarily, when an attacker tried to then forward the stolen traffic to its rightful destination, it would boomerang back to him, since other routers would still believe that his was the best destination for the traffic. But the technique demonstrated at DefCon, and now spotted in the wild, allows an attacker to send his announcement in such a way that it is delivered only to select routers. So, once the traffic passes through his router, it gets directed to its rightful destination through routers that never got the bogus announcement. The attack intercepts only traffic headed to target addresses, not from them. BGP hijacking happens in some form or fashion every day, but it’s usually unintentional — the result of a typo in a routing announcement or some other mistake. And when it does occur, it generally results in an outage, as the traffic being routed never reaches its destination. This was the case in 2008 when Pakistan Telecom inadvertently hijacked all of the world’s YouTube traffic when it attempted to prevent just Pakistan citizens from reaching video content the government deemed objectionable. The telecom and its upstream provider mistakenly advertised to routers around the world that it was the best route through which to send all YouTube traffic, and for nearly two hours browsers attempting to reach YouTube fell into a black hole in Pakistan until the problem was corrected. In April 2010, another outage occurred when China Telecom distributed an erroneous announcement for more than 50,000 blocks of IP addresses, and within minutes some of the traffic destined for these domains got sucked into China Telecom’s network for 20 minutes. After analyzing the details, Renesys concluded that this incident, too, was likely a mistake. But the incidents this year have all the characteristics of an intentional intercept, Renesys says. There are legitimate reasons to send out bogus BGP announcements intentionally. Some security firms do this as part of a DDoS protection service. If a victim is being hit with a lot of trash traffic in an effort to knock its servers offline, the security firms will send out bogus announcements to divert traffic away from the client, filter out the trash, and forward the legitimate traffic to the client. But Renesys ruled this out as an explanation for the suspected hijacks after speaking with victims whose IP traffic was hijacked. The first hijacks occurred last February, when an internet service provider called GlobalOneBel based in the Belarusian capital, Minsk, sent out a bogus BGP announcement. The intercepts occurred 21 times throughout the month, with different IP addresses re-routed each day. Some of the intercepts lasted a few minutes, others continued for hours. Countries whose traffic was intercepted included the U.S., Germany, South Korea and Iran. GlobalOneBel’s traffic gets routed through the state-run Bel Telecom, which is where Renesys saw the hijacked traffic go. In one case, traffic headed from New York to Los Angeles took a detour to Moscow and Belarus before being sent back through New York to its destination on the West Coast. In another case, traffic headed from Chicago to Iran, which normally passed through Germany, took a roundabout journey through Canada, London, Amsterdam, Moscow and Belarus before being sent to Iran via Poland, Germany, the UK and New York. The intercepts suddenly halted in March, but then resumed on May 21. This time the hijack appeared to be initiated by a system belonging to Elsat, another ISP in Belarus, whose traffic also gets routed through Belarus’s state-run telecom. The intercepts didn’t last long, though, before the hijackers appeared to change their tactics. The diversion to Belarus stopped, and instead Renesys saw traffic being diverted to a different location, this time in Iceland. The hijack now appeared to be initiated by Nyherji hf, a small internet provider in that country. That intercept lasted just five minutes before the hijack went silent. Nothing occurred again until July 31 when the intercepts resumed with a vengeance, this time appearing to come from Opin Kerfi, another ISP in Iceland. The hijack intercepted 597 IP blocks belonging to a large company in the U.S. that provides VoIP and other services, as well as other IP blocks, most of them in the U.S. Renesys counted 17 intercepts between July 31 and August 19, with nine different ISPs or companies in Iceland initiating the intercepts — all of them downstream customers of Síminn, an internet backbone provider in Iceland. In one case, traffic headed from one location in Denver, Colorado, to another location in Denver flew off to Illinois, Virginia and New York before traveling overseas to London and Iceland. From there it was redirected back to Denver through Canada, Illinois, New York, Texas and Missouri before finally reaching its destination. The bogus BGP announcements that hijacked the traffic went to so-called peering partners of Síminn in London but not to its peering partners elsewhere. Peers are separate networks that have an established connection in order to easily pass traffic back and forth. Map showing the long and winding path taken by traffic headed from Chicago to Iran. The green route represents the normal route the traffic takes; the red route is the hijacked route it took through Belarus. Renesys contacted Síminn to inquire about the redirects and was told the cause was a bug that had since been patched. “A software malfunction in Síminn’s internet gateway in Montreal this summer resulted in the corruption of routing data,” a Síminn security manager wrote Renesys in an email. “The effect of the malfunction was that traffic which was not intended for Síminn or its customers passed through Síminn’s network en route to its intended destination. … The malfunction had the effect that the corrupt routing data appeared to originate from certain customers of Síminn, including Opin Kerfi and Nýherji.” The company said the malfunction was resolved with the assistance of the equipment vendor on August 22nd. Renesys, skeptical of the response, asked for details about the bug and the vendor so that others using the same system could fix it as well, but Síminn didn’t respond. The Síminn manager also did not respond to questions from WIRED. Madory says that if the hijacks to Iceland occurred in isolation, Siminn’s explanation might be plausible, though he still wouldn’t understand how a problem with a system in Montreal resulted in traffic being misrouted through London but then correctly routed through Montreal on its way back from Iceland. But the hijacks to Iceland weren’t isolated; they occurred around the same time as the Belarus attacks. He says he has no doubt that the Belarus hijacks were intentional, and the fact that the last Belarus hijack and the first hijack to Iceland occurred on the same day – May 21 – within minutes of one another appear to link them. “This is a one-in-a-million thing that this would just also happen [on the same day] with some similarities to it,” he says. Renesys discovered the hijacks because it uses an automated system to read global BGP tables daily and tag any that match suspicious parameters. But BGP tables don’t tell the whole story. So Renesys also sends about a quarter of a billion traceroutes a day around the world to measure the health of digital traffic – like a coronary angiography for the internet. This helps verify that the data in routing tables matches what is really happening to data in the stream, and helps them spot outages when undersea cables are cut or when countries like Iran or Syria block users from the internet. Judging by the BGP tables alone, the traffic that got hijacked to Belarus, for example, should have dead-ended there. But when Renesys sent traceroutes along the same path, it got sucked into the stream going to Belarus and then got spit out the other end to continue to its destination. “Which is alarming,” Madory says. BGP hijacking is an “exceedingly blunt instrument” to capture traffic, and is “about as subtle as a firecracker in a funeral home,” Renesys has noted in the past. In all the years Renesys has been monitoring internet traffic, analysts had never seen anything that looked intentional before. Generally, Madory says, mistakes look clumsy and show obvious signs of being mistakes. They also generally last minutes, not days as these did, and they also generally do not result in traffic being re-routed to its legitimate destination, as occurred in these cases. “To achieve this thing where you can get [hijacked] traffic back to its destination, . . . you have to craft your [BGP] messages in a way that you control how far it propagates or where it propagates,” he says. “And we can see these guys experiment over time, modifying different attributes to change the propagation until they’ve achieved the one that they want. We’ve never seen anything like that, that looks very deliberate where someone is tweaking the approach.” But Tony Kapela, VP of data center and network technology at 5Nines in Wisconsin and one of the researchers who exposed the BGP vulnerability in 2008, is shocked that no other signs of intentional hijacking have occurred since their talk five years ago and questions whether this is really the first case, or just the first one seen. Kapela says there are a number of ways that an attacker could hijack traffic so that even Renesys wouldn’t notice — specifically, if attackers wanted to grab a narrow slice of traffic going to a specific destination and did so in a way that prevented a bogus route announcement from being distributed to the entire internet. He gives the example of three networks that are traffic peers. One of the networks could siphon traffic passing between the other two by sending a route announcement that doesn’t get broadcast to the wider internet. The attacker would send an announcement to one of the others with a tag attached, indicating that the announcement should not be broadcast to any other systems. “If you have the ability to give a network route to another provider and say ‘don’t export this,’ and if that provider doesn’t give it to Renesys or the world, it will not be visible,” Kapela says. Renesys has monitoring systems set up throughout the internet in more than 400 networks, but doesn’t see all traffic movement. “Renesys sees whatever lands in the fly trap,” Kapela says. “But if you pick one that doesn’t give a route view to Renesys, you have a good chance of not having this get noticed.” Kapela notes that the first time he and his colleague demonstrated a BGP attack at a conference in Germany, the bogus announcements they sent out did not reach the internet at large, just the specific networks they wanted to affect. Kapela says the culprit doesn’t have to be one of the three entities in the attack scenario, but could actually be an outsider who simply seizes control of one of the systems and sends out the bogus announcement without the owner of the system knowing it. He imagines a scenario where an attacker gains physical access to a router belonging to one of the companies and installs a monitoring device to record data, then gains control of the router console to send out a bogus BGP announcement to redirect traffic through the router. If anyone discovers the redirect, the culprit would appear to be the company that owned the router. Kapela says this kind of attack could become a real risk as data centers and ISPs begin installing centralized router controls. Until now, many ISPs have used proprietary systems and decentralized models of control whereby routers were managed individually. But many are switching to new systems, where control for numerous routers is centralized. If someone can hijack the master control, he can distribute bogus announcements. There may also be ways to feed operators false data to blind them to this manipulation. Renesys and Kapela say that ISPs, credit-card processing companies, government agencies and others should all be monitoring the global routing of their advertised IP prefixes to make sure that someone isn’t hijacking their traffic or using their system to hijack someone else’s traffic. In other words, the future may hold more of these security breaches. As Renesys warned on its blog: “We believe that people are still attempting this because they believe (correctly, in most cases) that nobody is looking.” Kim Zetter is a senior reporter at Wired covering cybercrime, privacy, security and civil liberties. Read more by Kim Zetter Follow @KimZetter and @ThreatLevel on Twitter.