Show 61 discussed the DNS hijacking of several well known websites. This blog briefly explains the industry context within which this attack occurred, then explains some practical activities you can take to protect your organisation from DNS hijacking.
If you only want the suggestions, just scroll to the last section labelled Finally, the suggestions.
So what happened?
Readers of the affected sites attempted to visit them and found themselves looking at a defacement page. However the websites of the victims were not breached. Users were sent to the defacement page because the DNS details of the victims were altered…specifically the delegation details.
Delegation, for the uninitiated, refers to the mechanism within the DNS to indicate who is responsible for a domain. Pro tip, if you use the unix tool “dig” using the +trace option will show you delegation (note that you need to be able to query the root servers for this and some networks block this). Amateur tip, you should learn to use the unix tool “dig”, it’s confusing at first, but useful in all manner of situations (including Active Directory troubleshooting.. check out the ixfr section in “man dig”).
So what happened? Didn’t I already ask that?
The attacker broke into the management console of a Registrar. Registrars are the middlemen of the domain industry; it is they who sell you a domain, and it is they who update the delegation details with the Registry under which your domain resides. With access to the management console, the attacker could change the delegation details of any domains that Registrar was responsible for. The Registry accepts updates from Registrars as if they have come from the domain owners, so the attacker had full control. There was nothing the victims could do at that point except notify the Registrar, who then needed to reverse the changes made and close the method the attacker used to gain access in the first place (SQL injection in this case).
Hang on, didn’t you say this post was about preventing this? Is this about DNSSEC? I’ve heard it’s hard…please don’t talk about DNSSEC.
The suggestions will follow, but first: DNSSEC. It’s not as hard as you think and I encourage you/your organisation to deploy it, but it would not have made the slightest difference in this case. Access to the registrar meant that the attacker would have been free to update the DS records within the parent zone. I’m ignoring the TTL issues that such a change would face. All suggestions below are relevant to DNSSEC signed domains and unsigned domains.
Finally, the suggestions:
First, and this part won’t yet protect against malicious redelegation but it’s useful for other reasons, organisations should generally have infrastructure domains. These are domains which you use for critical infrastructure, but will be largely invisible to users. You use these domains to identify critical services such as name server names or router names. This domain (or domains) should not be attached to an IPAM or hosted by a brand management/DNS portfolio management firm. This domain should be static, should be managed on a hidden master DNS server and changes should be under the IT/Network operations change management control.
Note that particularly large organisations will have several such infrastructure domains with a sliding scale of updates, but still manual or heavily restricted backend management systems. The most critical domains will almost never change, while the less critical domains are, the more likely they are to change. And if your web properties are attached to a Content Delivery Network as many media sites are, then often the CNAME or apex records which redirect users to the CDN will be within an infrastructure domain. These lower security but still restricted domains can also be used for organisations that represent you, such as mail marketing firms (/sigh) or order processing sites.
Ensure that these domains are with a Registrar with whom you have a direct relationship (not a reseller) and who offers Registrar Lock as a minimum. Registrar lock should result in a second factor being required for redelegation or domain transfer. Ideally you will also have Registry Lock, which is offered by the Registry, but for which Registrars may charge a little extra. This forces manual changes to delegation and domain transfer. So changes just became really hard. However since these infrastructure domains should not be changing often, it is added protection without much down side. If your Registry offers Host Lock (glue record locking in the same way the other locks work), you should take that as well. All of these options are available in COM and NET. Check with your specific ccTLD or gTLD.
In case you hadn’t heard the term before, glue records are the “hints” provided by a Registry when your domain is delegated to a name server which is a child of that domain. For instance, example.com is delegated to ns1.example.com, so the COM servers will provide resolvers with a hint (ADDITIONAL in dig output) to ns1.example.com.
For your primary branded domains, if you don’t update them often because you use network based mechanisms to update public services, then all the options above apply, except I’d still recommend delegating these domains to your own infrastructure domain. Even if you have a 3rd party DNS hoster, they will let you add their name server addresses into your infrastructure domain. This lets you move providers without the headache of redelegation and retaining change control. Of course some providers won’t like it because they want to change IP addresses as they see fit, which is a valid requirement, but doesn’t protect you. If you do update your primary domain regularly or you have a portfolio brand management company that looks after domain delegation, then make sure you have good contact with them and do your homework on their processes.
Finally, monitor the delegation and glue record (I’ve seen this attacked in isolation) as you would any other service. For a stable TLD, that is easy enough, but some TLDs have significant stability issues that sadly will result in many alerts due to dropped DNS queries. So you may need to observe and adjust for behaviour if your TLD is not very stable. If you use DNSSEC, then monitor the DS record, it should not change unless you updated it (which should happen every 6 months or so).
DNS is not regularly attacked because of the difficulty in changing it and maintaining that change while trying to do something with the diverted traffic. However, it is incredibly attractive to anyone who wants to impersonate your organisation. So you won’t get many opportunistic DNS attacks, but when someone does attack your DNS, they are likely to be more prepared and only focused on you. That means you need to be similarly prepared.