Over the weekend there were extremely disturbing reports out of Turkey of escalations in the attempts by the Turkish government to block social media sites such as Twitter and YouTube. The steps now being taken appear to have the Turkish Internet service providers (ISPs) hijacking the routes to public DNS servers such as those operated by Google and masquerading as those DNS servers to provide answers back to their citizens.
Effectively, the Turkish ISPs, operating to comply with a Turkish government ban, are performing a “man-in-the-middle” (MiTM) attack against their citizens and giving them false information.
The Internet Society made a statement on the subject yesterday, explaining its “deep concern” for the situation, and our Chief Internet Technology Officer Leslie Daigle has described how these recent moves “represent an attack not just on DNS infrastructure, but on the global Internet routing system itself.”
Background
As we noted ten days ago, ISPs in Turkey started out attempting to implement the government’s ban by simply blocking those sites in DNS. When Turkish citizens tried to go to those social media sites, their device would query DNS to get the correct IP address to connect to. The Turkish ISPs who were providing the DNS servers used by the Turkish citizens simply failed to give back a response for Twitter and YouTube.
Turkish citizens found they could get around this block by simply changing their devices’ DNS settings to point to open public DNS resolvers such as those operated by Google.
Predictably, the Turkish ISPs then attempted to block the addresses for Google Public DNS servers and other similar servers. The ISPs then started to engage in the typical kind of “whac-a-mole” game with their citizens where the citizens would find new ways to get around the censorship… and the ISPs would then try to shut down those.
BGP Hijacking
Starting this past Saturday, March 29, though, reports started coming in that the Turkish ISPs were taking this to a whole new level by hijacking routing of the Border Gateway Protocol (BGP) and pretending to be Google’s Public DNS servers (and the servers of other similar services).
In other words, the devices operated by Turkish citizens on Turkish networks were connecting to what they thought were Google’s Public DNS servers (and other services) and were getting back answers from those services.
The answers the Turkish citizens were receiving were just the wrong answers.
Instead of going to Twitter or YouTube they were being redirected to sites operated by Turkish ISPs. Google confirmed this in a post on their Online Security Blog that included in part:
A DNS server tells your computer the address of a server it’s looking for, in the same way that you might look up a phone number in a phone book. Google operates DNS servers because we believe that you should be able to quickly and securely make your way to whatever host you’re looking for, be it YouTube, Twitter, or any other.
But imagine if someone had changed out your phone book with another one, which looks pretty much the same as before, except that the listings for a few people showed the wrong phone number. That’s essentially what’s happened: Turkish ISPs have set up servers that masquerade as Google’s DNS service.
Writing over on the BGPMon blog, Andree Toonk detailed the specifics of the BGP route hijack that took place. Essentially, the Turkish ISPs started “advertising” a more specific route for Google’s Public DNS servers. The way BGP works, Google advertises a route for traffic to get to its servers on its network. As the BGPMon blog post indicates, that is normally a “8.8.8.0/24″ route directing people to AS 15169. However, the Turkish ISPs advertised a specific route for “8.8.8.8/32″ that went to their own network.
In BGP, a router typically selects the most specific route as the one to use to connect to a given IP address. So all the routers on networks connected to Turkish ISPs would use this very specific route instead of the one advertised by Google.
They apparently did this for all of Google’s Public DNS addresses as well as those of other open public DNS providers as well. Over on the Renesys Blog, Earl Zmijewski shared their observations including showing precisely when the hijacking occurred:
The Turkish ISPs are pretending to be Google’s specific DNS servers to everyone who is connected to their network.
Delivering False DNS Information
The Turkish ISPs went a step further, though, in that they set up their own DNS servers that answered as if they were Google’s Public DNS servers. As Andree Toonk wrote on the BGPmon blog:
Turk Telekom went one step further, instead of null routing this IP address they brought up servers with the IP addresses of the hijacked DNS servers and are now pretending to be these DNS servers. These new fake servers are receiving traffic for 8.8.8.8 and other popular DNS providers and are answering DNS queries for the incoming DNS requests.
Stéphane Bortzmeyer also documented this in a lengthy post on his blog where he used the RIPE NCC’s Atlas probe network to show that DNS answers in Turkey are different from those in other areas. The Renesys blog post also confirmed this, as did many posts on social media services and other online sites. A good number of tech media sites have weighed in on the matter as well.
The Need To Secure BGP
From our Deploy360 point of view, this kind of attack against the Internet provides a great case study of why we need to better secure BGP and why we need to get DNSSEC validation more widely deployed.
With BGP, the fact that anyone can advertise a route for any other network means that ISPs can do precisely what the Turkish ISPs have done and hijack routes to masquerade as anyone else. Clearly this is unacceptable. As we talk about on our “Securing BGP” page, and is also detailed more deeply in the BGP Operations And Security Internet-Draft, there are efforts underway to deploy “secure origin validation” so that routers in the network know which advertised routes to trust and which ones not to trust.
If the routers on networks in Turkey had secure origin validation in place, when they received the more specific route from the Turkish ISPs they could have checked the origin, realized that the route advertisement was not coming from the operator of the original network and simply disregarded the more specific route. They would have continued to use the original routes that were advertised by the original network operators.
Now, granted, if the ONLY routes from the networks inside of Turkey out to the rest of the Internet are through a small number of large Turkish ISPs who work with the government to enforce banned sites, then this kind of origin validation will not help the “downstream” networks. While they may disregard the announced specific route because of origin validation, their traffic using the original route will still have to travel through the networks of the small number of large ISPs who can then - within the large ISP networks – perform the BGP hijacking. However, if any of the downstream networks have alternate Internet connections (and this may not be possible within Turkey) they may be able to use routes going out those connections.
It is also useful to note that secure origin validation could help networks outside of Turkey. When a government is causing network operators to mess around with the routing tables that make up the fundamental architecture of the Internet, they are playing with fire. One mistake could have a very large impact on the rest of the Internet, such as the time when a Pakistani ISP rerouted global YouTube traffic to a network in Pakistan back in 2008! In their escalating attempts to block access for Turkish users, it is entirely possible that someone at one of the Turkish ISPs could leak incorrect routes out into the larger Internet. Secure origin validation running on other networks around the Internet would prevent these incorrect routes from being taken seriously.
Where DNSSEC Would Help
On the DNSSEC side, if the Turkish citizens had DNSSEC-validating DNS resolvers running on their local networks or even better on their actual devices, and if, for instance, Google had DNSSEC-signed the DNS records for their Public DNS servers, then Turkish users would be able to know that they were not getting to the correct servers. Note that this would not help them get to new servers… but they would know that they were not getting the correct information. Applications that validated the DNSSEC signatures on information retrieved from DNS could then discard the invalid information and try other ways to get that information.
DNSSEC helps ensure that you are getting to the correct site and not to a site set up by, for example, a spammer or phisher trying to steal your identity. Similarly it could protect you from going to sites set up by a government (or via a government mandate) that are pretending to be a site that they are not. For this to work, of course, the original sites (such as Twitter and YouTube) need to have their DNS information signed with DNSSEC, and users out on the Internet need to have DNSSEC validation happening in their local DNS resolvers.
Which is why we need to get DNSSEC deployed as fast as possible – to ensure that the information that we all get out of DNS is the same information that was put in to DNS by the operators of a given domain… and not the information put in by an attacker, which, in this case, could be ISPs acting on behalf of a government.
Again, this would not necessarily help a Turkish user get to Twitter or YouTube, but would prevent them from going to spoofed sites. Additionally, if the operating system were validating the DNSSEC signatures on name server records the system could have noticed that the information it was getting back from, for instance, Google’s Public DNS, did not validate with the “global chain of trust” and so could have warned that the DNS information was suspicious (or perhaps chosen to try to use additional DNS servers that did validate correctly).
How To Help
The question now is what we do to strengthen the Internet against these kind of attacks on the Internet’s infrastructure. Within our area of focus, we have three requests:
1. Understand how to secure BGP, and do so! - Please visit our “Securing BGP” section of the site, read the BGP Operations and Security Internet Draft, look at our BGP content roadmap and see if there are any documents there that you can contribute to help us build out our content and get more people taking these steps to secure their routers. If you are a network operator, any steps you can take to make your routers more secure will go far.
2. Deploy DNSSEC validation - Wherever you can, turn on DNSSEC validation in any DNS recursive resolvers. The steps to do so are very simple for the common DNS resolvers.
3. Sign your domains with DNSSEC – If you have a domain registered, see if you can sign it with DNSSEC (here are the steps you need) and if you encounter any issues please raise the issue with your domain name registrar, DNS hosting operator, IT department or whomever is blocking the process.
These steps will make attacks on the Internet’s infrastructure such as those happening in Turkey today more difficult and raise the complexity needed by the attackers.
Beyond these steps, this situation clearly points out the need for a wider diversity of Internet access methods. Even with these steps above implemented, Turkish users who are limited to only the specific Turkish ISPs have no choice in receiving their default routes and connections. If more options were to be available in the region, the ability of those users to have access to the information on the Internet would not be restricted.
The Internet needs to be hardened against attacks such as these. Please help make the Internet stronger!
I’ve made a couple of updates recently to our DNSSEC Deployment Maps section of the site.
