In the past few months, we’ve witnessed a sudden increase in the number of compromised domain registrars and registries, allowing hackers to takeover the domains of popular Web sites.
Domains such as Twitter, Google, Facebook, The New York Times, and Microsoft have all been victims of name server hijacks where millions of users are redirected to servers under the control of bad actors.

Yesterday, we saw evidence of another attack on a Google domain. But we detected it and helped to fix it so quickly, few people even noticed.

Because these attacks seem to be gaining in frequency, we built a system to monitor the records large set of popular domain names. We wrote massresolver, a simple tool leveraging libunbound to quickly and securely resolve a massive list of domain names, even with an empty cache.
Now, each time an unexpected name server is detected for a domain in the output, an email is sent to our team, and we can immediately take action to protect our users.
We don’t provide authoritative DNS services, so we can’t prevent changes to the actual records hosted on name servers, but we can prevent Umbrella users worldwide from being directed to the malicious IPs via our recursive DNS services.

Last night, our monitoring system fired up an alert: the name servers were not Google’s any more. They were served by a free hosting service named 000webhost.
We saw the same name servers a couple days ago: these were used by the Syrian Electronic Army when they took control of the .qa (Qatar) zone, and redirected a lot of domains to their own servers in order to spread a political message.

Each DNS record has a time-to-live, i.e. the minimum amount of time resolvers should cache it and serve it unmodified to clients before asking for an update. The attackers wanted to take advantage of this: they set up an unusually high time-to-live for the malicious IP. The very same TTL was observed last week during the .qa zone hijack by the Syrian Electronic Army. Can you spot the malicious IP among Google’s legitimate ones?

Screen Shot 2013-10-25 at 12.01.25 PM

Because the hackers chose a free hosting service that couldn’t keep up with the amount of queries received for, we couldn’t see if the hackers had posted a message or were serving malware. We did, however, immediately block the related IP addresses.

We detected the hijacking less than 5 minutes after the records had been changed and before any of our resolvers had any chance to fetch the malicious records.
Around the same time, we tweeted about this event:

Screen Shot 2013-10-25 at 11.24.02 AM

Stephane Bortzmeyer of the .FR registry immediately saw the tweet and jumped on his phone to contact the .RW registry.

Screen Shot 2013-10-25 at 11.38.16 AM

10 minutes later, the .RW registry acknowledged the hack, and restored the original DNS records.

In just 10 minutes, this name server hijack against Google was defeated even before the attackers started to brag about their achievement. Thanks to our monitoring systems, and to very reactive friends!

These kinds of attacks are very powerful. Even if a Web site is extremely secure, the content that users load also depends on name server records whose security depends on a third-party. Nothing happened to the servers of the targeted companies, but attackers were able to change DNS records so that users accessing these domains were redirected to a totally different set of machines. Furthermore, controlling a domain name also allows attackers to potentially read private email sent to this domain.

Every time we notice a major name server hijack, we immediately block the relevant IP addresses, if only to prevent our users from sending emails that would be intercepted by attackers. With our new monitoring tool, we’re making sure that our users will be protected from these hijacks before they have time to notice.

This post is categorized in: