A Researcher’s Hijack Exposes Weaknesses in Country-Code Top-Level Domains
A security researcher has managed to hijack several of the authoritative nameservers for the .io top-level domain (TLD), allowing him to potentially redirect computers to rogue websites. The incident highlights the fragility of the Domain Name System (DNS) and why it’s important for website owners to implement additional security measures such as HTTP Strict Transport Security (HSTS).
The unusual hack was pulled off by Matthew Bryant, a security researcher who was investigating potential DNS weaknesses that could affect entire TLDs. As part of that effort, he ran an automated script that checked if any of the nameservers hosting DNS zones for various TLDs became available for public registration, possibly due to misconfigurations or other reasons.
Last week Bryant received a notification from his script that the domain names for four of the seven authoritative nameservers for the .io TLD were available for purchase. Sometimes such alerts can be bogus, the domain names being listed as available for registration, but having a lock flag on them that prevents users from actually buying them.
In this case, however, Bryant’s attempt to register one of the .io nameserver domain names went through successfully and he was able to point it to his own DNS server. He immediately started receiving DNS queries for various .io domains from computers around the world.
“Yikes! I quickly SSHed into my DNS testing server that was now hosting this domain and quickly killed the BIND server that was running,” the researcher said in a blog post describing the incident. “If I was starting to receive DNS traffic I certainly didn’t want to serve up bad responses for people trying to legitimately access their .io domain names. With the BIND server no longer responding to queries on port 53 all DNS queries would automatically fail over to the other nameservers for the TLD and it wouldn’t greatly affect the traffic (other than a slight delay in resolution time while DNS clients failed over to working nameservers).”
The researcher immediately notified the administrators of NIC.IO, the registry in charge of the TLD, and also registered the other three .io nameserver domain names that were listed as available to prevent potentially malicious attackers from taking advantage of this oversight. The registry subsequently took back control of the domains from Bryant and refunded him.
To understand why nameservers are important, one has to understand how the DNS works. Often described as the Internet’s phone book, the DNS translates domain names that are easy for people to remember into Internet Protocol (IP) addresses that machines use to communicate with each other.
Every time an application or a browser tries to access a resource on a domain name, the computer needs to find the IP address of the server hosting that domain name. In DNS this is called an A record for IPv4 addresses and AAAA record for IPv6.
First, the application asks the system’s DNS resolver for the answer, which in turn ask its configured DNS servers, which then go higher up in the DNS hierarchy until the query reaches the authoritative nameservers for the requested domain.
This is a simplification because, in reality, the DNS is a complex system made up of recursive, caching, forwarding, authoritative and other types of servers. Sometimes the answer can already be found in the browser’s own DNS cache or can be served from the cache of one of the intermediary servers. However, cached DNS records have a time-to-live (TTL) value and when they expire, a new query will have to go through to the authoritative nameservers to obtain a fresh result.
If attackers get into a position to control DNS responses for a domain name or an entire TLD, they can redirect users to fake versions of the websites they’re trying to reach. This can enable powerful phishing attacks or can result in data leaks if various applications start sending sensitive information to the attacker’s server instead of the legitimate server hosting the domain.
The .io nameserver domain registration weakness seems to have been introduced in June, during the migration of the .io registry from NIC.IO, which was operated by a U.K.-based company called the Internet Computer Bureau (ICB), to Afilias, a company that provides registry services and managed DNS solutions for many other TLDs.
“Ordinarily, when a TLD transitions to the Afilias system, 100% of the DNS is also moved to Afilias nameservers,” said Roland LaPlante, senior vice president and chief marketing officer at Afilias, in an emailed statement. “Last week, Afilias discovered that some of the nameservers associated with the .IO TLD were not blocked when the TLD was transitioned to Afilias’ systems in June. In this special case, ICB is continuing to operate its .IO nameservers after the transition. Upon discovery, Afilias promptly reassigned and blocked the domains associated with ICBs nameservers, and the DNS for .IO is now working as expected.”
According to LaPlante, the company is not aware of any issues that arose from the brief nameserver exposure and the company’s TLD transition procedures have been updated to prevent similar situations in the future.
Matthew Pounsett, a senior DNS engineer at TLD registry operator Rightside, disputed Bryant’s claims that computers looking for .io domains would have actually reached his rogue DNS server.
“The author assumes that because he’s able to register a domain name that matches several of the authoritative name server names for the .io TLD that it is ‘likely that clients will randomly select our hijacked nameservers over any of the legitimate nameservers…’ This is wrong,” Pounsett said in a technical analysis on his personal blog.
However, Bryant is sure that his server received gigabytes-worth of DNS queries for .io domains during the brief time before he shut it down. The researcher even claims that he ran a packet capture, but he deleted the resulting file because it quickly filled up the limited storage of his virtual private server and because he didn’t want to be accused of violating people’s privacy.
During a discussion on Hacker News about the recent .io incident, some people expressed their belief that most of the registries for country-code top-level domains (ccTLDs) have weaker security practices and are not as well-run as the registries that manage generic TLDs.
Another concern is that ccTLD registries receive less oversight from the Internet Corporation for Assigned Names and Numbers (ICANN), possibly because ccTLDs are often under the direct control of governments that enforce their own policies and regulations. And since many ccTLD registries are operated by government-mandated organizations, their resources and technical expertise vary widely.
It’s worth pointing out that while the .io TLD has gained a lot of popularity in the development community in recent years, it is ultimately a ccTLD that corresponds to the British Indian Ocean Territory. Maybe the registry switchover to Afilias, which has a lot of experience managing TLDs, will bring more stability and better security practices, but some people are definitely not happy about how the migration was handled.
“Think choosing a cute TLD like .io for your business is a good idea? May want to think again,” Matthew Prince, the CEO of CloudFlare, said on Twitter in relation to the .io nameserver hijacking incident. After some people pointed out that the availability of domain names is very limited for traditional generic TLDs, he replied: “I’d rather be sprnklr.com than sprinkler.io.”
It’s important to understand though that having a .com, .net or other generic TLD domain doesn’t mean that DNS hijacking is mitigated. Security breaches can happen at different points in the DNS trust chain since there are so many parties that have power over a domain name’s DNS records: the TLD registry, the domain provider or registrar, the domain owner, any third-party DNS management service the domain owner uses and so on.
“This is a great example of where HTTPS is essential and along with it, features such as HSTS preload which ensure a site can never be loaded without serving a valid certificate,” said Troy Hunt, a Microsoft Regional Director for Australia and a Microsoft Most Valuable Professional (MVP) for Developer Security.
The HTTP Strict Transport Security (HSTS) is a server-side security policy designed to prevent protocol downgrade attacks. It is honored by all modern browsers and can be used by websites to tell clients to always access them over an encrypted connection (HTTPS) on recurring visits.
This means that in the case of a DNS hijacking attack, trying to direct visitors to a fake version of a website over plain HTTP will fail if visitors’ browsers have recorded an HSTS policy for that website during previous visits. To bypass this, attackers would have to also obtain a legitimate SSL/TLS certificate for the targeted website so they could set up an HTTPS-enabled clone. This is significantly harder to achieve, as it requires tricking or hacking into a public certificate authority to issue a certificate to someone who is not the domain owner.
There are also other defenses against DNS hijacking, such as domain locks and Domain Name System Security Extensions (DNSSEC) and you can read more about them and other mitigation options in this article.