This is a brief blogpost on the news that has been sent to us by many people, namely that there is a suspected Iranian group that is “hijacking DNS”. I was about to be interviewed on this subject but sadly that fell through. I did however prepare notes already, so please find some possibly useful things on the subject here.
Briefly: the weakest part of your DNS security currently likely isn’t actually DNS. It is the login (and password reset mailbox) where you manage your domains & nameserver settings.
In general, if an attacker wants to take over a service you provide (a website, email or whatever), this requires them to change or redirect traffic between users and the targeted service.
There are four “gates” that determine how information flows from/to a named service:
- The nameserver configuration for a domain name (“the names of the nameservers”)
- What those configured nameserver names respond with.
- Which cables those IP addresses are routed to: the Border Gateway Protocol
- The actual servers and the software they run
Many attacks have historically focused on item 4, hacking either servers or software. For decades this was the easiest way. Recently however, the most used pieces of software have become more secure, and operators also update their software far more faithfully. Often this is done on their behalf by cloud providers.
Meanwhile, we are seeing a lot more attacks that involve BGP hijacks to route the (correct) IP addresses to incorrect locations.
The currently discussed attack involves items one and two. Why attack a server if you can reroute all traffic with a simple login? Once an attacker is logged in to a domain management solution they can change whatever they want.
So, how are these systems attacked? In the simplest case, an important domain is hosted at a registrar and protected only by a weak or leaked password. We may wonder how this is possible but it happens a lot. The “most important domain” for many companies was frequently registered by the founder ages ago. And unlike all new domains, it still languishes at a relatively unknown provider where it was registered back in the 1990s. This for example is the case for our own ‘powerdns.com’ domain.
And this original founder may not have been a security professional and picked ‘password123’ as his password. Or perhaps he did pick a good password, but it has now leaked in one of the massive breaches over the past decades.
Secondly, almost all DNS control panels come with a password reset solution that typically sends a reset mail.. to a preconfigured email address. This email address again might not be a well secured Gmail account but some ancient Yahoo mailbox that hasn’t been touched in years – again likely with a 1990s-era password.
If that doesn’t work, an attacker has further options. If gaining access to the control panel of ‘importantdomain.com’ fails on the first try, and the password recovery email address is ‘john@companyfounder.com’, we can repeat the whole process over at ‘companyfounder.com’!
Perhaps someone over time improved the password for ‘importantdomain.com’ but not for the control panel of ‘companyfounder.com’. And if we control the ‘companyfounder.com’ domain, we can hijack the account recovery email, and thence take over ‘importantdomain.com’.
Beyond, even if that fails, we can repeat the whole process for the accounts not of ‘importantdomain.com’, but for the domain that contains the names of the nameservers themselves. Once an atttacker changes those, they can substitute nameservers that give answers that are implement the hijack.
The options to attack a domain administratively go on and on and on. It is therefore indeed very plausible that attackers have been able to acquire control of large numbers of domains.
So, what should operators do? The standing recommendation is of course to enable two-factor authentication for all control panels and to make sure that any remaining account recovery mailboxes are very well secured. Despite our very low opinions of Google’s stance on privacy, currently almost nothing beats a GMail account that itself is two-factor secured.
In addition, some domains can be “registry locked”, which is also highly recommended for high-profile domains.
But the most important recommendation is to audit each and every domain name of the company to see if these security measures have actually been taken. Because through the hops as described above, ‘importantdomain.com’ may in fact be hijacked via the nameserver of the domain of the mailbox of the company founder.
As a final note, it is often claimed that DNSSEC and TLS will protect against these attacks. While adding cryptography does raise the bar, and sometimes significantly, the control panels we have discussed so far include options to disable DNSSEC, while a DNS hijack enables an attacker to get fresh all new TLS certificates under their control within seconds. Using DNSSEC and TLS judiciously requires attackers to work harder, but it is no guarantee.
I hope this has been helpful!
