The Risks of DNS Hijacking Are Serious and You Should Take Countermeasures
Over the years hackers have hijacked many domain names by manipulating their DNS records to redirect visitors to malicious servers. While there’s no perfect solution to prevent such security breaches, there are actions that domain owners can take to limit the impact of these attacks on their Web services and users.
Just last Friday, attackers managed to change the DNS records for 751 domain names that had been registered and managed through Gandi.net, a large domain registrar. Visitors to the affected domains were redirected to an attacker-controlled server that launched browser-based exploits to infect computers with malware.
Also last week, a security researcher hijacked the domain names used by four of the seven nameservers for the entire .io top-level domain (TLD). He claims that the test DNS server he temporarily set up was flooded with DNS queries from computers looking for .io domains. Had he wanted to, he could have served back rogue responses.
The way in which domain names and their DNS records are managed is complex. Organizations called registries manage the DNS zones for specific TLDs, but the records in those zones come from domain registrars — the companies that have agreements with registries to sell domain names. The registrars themselves can have other resellers or can work with third-party companies that manage DNS operations for them.
For example, according to Gandi, the rogue DNS modifications last week happened through an unauthorized connection at a technical provider that the company uses to manage geographic TLDs.
Domain owners also have the power to change the nameservers for their domain names from their accounts on the registrar’s website. And they too sometimes delegate DNS management to third-party companies.
It’s easy to see how this complex system might offer many potential entry points for hackers. And depending on which link in the chain gets compromised, attackers could get access to one or thousands of domains as a result of a single breach.
Breaches at the registry level are obviously the most serious ones because they can have a widespread impact. Such compromises have happened in the past, especially at registries that manage country-code top-level domains (ccTLDs).
In 2012, hackers exploited a vulnerability in the website of the .IE Domain Registry (IEDR) and hijacked the Google.ie and Yahoo.ie domain names. That same month, similar breaches and domain hijackings have hit PKNIC and RoTLD, the registries for the .pk and .ro ccTLDs, respectively.
Registrars and their resellers have also been hit by hackers over the years. In 2013, a hacker group hijacked several high-profile domains, including nytimes.com, sharethis.com, huffingtonpost.co.uk, twitter.co.uk and twimg.com after phishing the credentials for a reseller account at Melbourne IT, an Australian domain registrar and IT services company.
A single compromised domain account can also have serious consequences, especially if the domain names in that account belong to a large company or service provider. In 2013 hackers obtained the domain administrator password for leaseweb.com, a large provider of cloud hosting, colocation and content delivery services.
The attackers redirected LeaseWeb visitors to a web page claiming that the company had no security and that all of its hosted sites had been compromised. Even if those claims weren’t actually true, that’s not a message that any company would want its customers to see when visiting its website.
What Attackers Can Do
DNS hijacking is a powerful type of attack that offers many opportunities for hackers, but the end result will often depend on the domain names they manage to compromise. If, for example, the victim is a mainstream news website, attackers might choose to redirect visitors to a page with a politically-motivated message. Whereas, if the domain belongs to a popular online service, they might decide to steal account credentials by redirecting victims to a fake log-in form. This method could even be used to bypass two-factor authentication by tricking users to disclose their short-lived one-time-use codes.
When attackers gain access to a large number of domain names at once, they are more likely to launch a mass scale malware distribution attack like in the recent Gandi incident. That’s easier than profiling the affected websites and devising separate attack strategies for each of them.
It’s also worth noting that DNS hijacking doesn’t impact only web traffic. Email and other kinds of connections to services on the hijacked domain can be intercepted as well, potentially leading to sensitive data leaks.
DNS hijacking can also indirectly affect websites that load scripts and other resources from external services or content delivery networks. If the domain names of such third-party services get hijacked, attackers could inject malicious code into thousands of websites.
What Domain Owners Can Do
Enabling HTTPS for all web apps and services hosted on a domain name should be a top priority. This will protect users from man-in-the-middle attacks in general and has many other benefits, like the ability to turn on HTTP/2 and gain a significant performance boost. However, to mitigate the effects of DNS hijacking, HTTPS needs to be combined with a security mechanism called HSTS.
The HTTP Strict Transport Security (HSTS) is a security policy expressed through a server header that is honored by all modern browsers. It was designed to prevent protocol downgrade attacks and cookie hijacking and can be used to instruct browsers to always access a website over encrypted connections (HTTPS).
Without it, an attacker who hijacks the DNS records of an HTTPS-enabled website can still pull off a phishing attack by directing visitors to a fake version of that site that doesn’t use HTTPS. The success of this attack would then depend on whether visitors will notice the absence of the green SSL/TLS padlock in their browser’s address bar, something that users don’t check very often.
With an active HSTS policy on top of HTTPS browsers will simply refuse to load the website if served over an unencrypted connection. To bypass this defense the attacker would have to obtain a valid certificate for the domain name from a certificate authority and install it on his rogue server. While this is not impossible — there have been cases of CAs being hacked or tricked to issue fraudulent certificates — it requires a lot of effort on the attacker’s part and their chance of success is pretty low.
A website’s HSTS policy is recorded by the browser when the user visits the website for the first time, so there’s technically an opportunity for a man-in-the-middle attacker to prevent the HSTS policy from being received by the client during this first visit. To close this attack window, Google Chrome, Mozilla Firefox, Internet Explorer and Microsoft Edge come with a preloaded list of websites for which HSTS is always enforced and webmasters can submit their websites for inclusion on this list.
Another mechanism that can partially mitigate DNS hijacking attacks is the Domain Name System Security Extensions (DNSSEC). This is a suite of extensions for the DNS protocol that allow the origin of DNS responses to be verified through cryptographic signatures.
For this to work, the root zone for the domain TLD, the domain nameservers and the user’s DNS resolver must all support DNSSEC. And that’s a problem, because the use of this protocol is not yet widespread, especially on the resolver side. So while enabling DNSSEC has the potential to protect some users from DNS hijacking — those who use DNSSEC-aware resolvers — it won’t protect them all.
Another important mitigation mechanism is a set of locks or codes that can be set for domain names by the registrar or the registry. These are: clientDeleteProhibited, clientUpdateProhibited and clientTransferProhibited at the registrar level and serverDeleteProhibited, serverUpdateProhibited and serverTransferProhibited at the registry level.
As their names imply, these flags will prevent domain names from being deleted, transferred or updated — including having their nameservers changed — without an additional out-of-band confirmation from their owners. The registry-level locks offer better protection, being higher up in the chain.
In 2014, a group of hackers gained access to an administrative account at MarkMonitor, a San Francisco-based company that manages domain names for large enterprises and brands. The attackers managed to change the contact address information for facebook.com, but couldn’t change the domain’s nameservers because it had a registry lock in place.
Finally, to mitigate the risk of malicious code injection through third-party scripts websites can use a mechanism called Subresource Integrity (SRI). This works by calculating and specifying a cryptographic hash for every external script loaded into the website. Browsers will compare every downloaded script’s hash with the hash specified by the website and if they don’t match, the external resource will not be loaded.
