How to Prevent DNS Attacks
Hackers like the Syrian Electronic Army are finding weaknesses to exploit in the Domain Name System. Here's how to keep your organization from falling victim to a DNS attack.
When the New York Times' website dropped off the Internet in August, it's a good bet that its system administrators were tearing their hair out trying to figure out how their servers had been hacked.
But as it turned out, they hadn't. The hackers -- apparently a pro-Syrian gang called the Syrian Electronic Army (SEA) -- found it easier to bypass all of the paper's security measures and compromise the Domain Name System (DNS) instead. By changing the mapping between the New York Times' domain name and the IP addresses of its physical servers, the SEA was able to direct traffic heading for the nytimes.com domain to the wrong IP addresses -- addresses of servers controlled by the SEA.
The attack shows the truth of the old mantra that cybersecurity is only as strong as the weakest link in the security chain. In this case the weakest link was the DNS system, and specifically a part that was outside the control of the company that was compromised.
How Does DNS Work?
To understand the problem, let's think about how DNS works. If you want to visit www.example.com, your browser needs to find the IP address of that particular Web server. The first thing it does it consult the system's hosts file, a text file with the IP addresses of any domain names that are effectively "hard coded" into that system.
If that Web address isn't in the system's hosts file, and this will almost always be the case, your browser will ask a DNS server -- either a resolver on your organization's network, or an external, public resolver which may be operated by an ISP, or by an organization like Google or OpenDNS.
Put simply, if the resolver has recently been asked for the IP address for that domain name, it will have that information in its cache and it will provide it directly. But if it hasn't got it in its cache -- either because it has never been asked for that information before or because the information has "expired "and been removed from the cache -- then it will refer the request on to a root server, which can tell the resolver where to get information about the .com top level domain.
It will then ask that server where to get information about example.com, and then go to that server, called the authoritative server, which will provide it with the IP addresses of any servers in the example.com domain (such as Web and email servers).
How Hackers Use DNS
The problem with this system is that if a hacker can find a way to make the resolver report back the wrong IP address, then anyone trying to get to one Web address will be sent to a bogus one, without any obvious way for the user to detect that anything is wrong. Likewise, email could be delivered to the wrong destination, and so on.
The underlying problem is one of DNS server configuration. "DNS servers tend to be forgotten about, and their default configuration is not necessarily secure," warns Chris Brenton, a fellow of the SANS Institute and director of security at Dyn, a company that specializes in providing DNS services.
Before looking at configuration and other changes that can be made to keep DNS secure, let's look at some ways that DNS can be compromised.
Cache poisoning involves putting false information into the cache of a server which is part of the domain name system. A typical way to do this is by sending a bogus "reply" with a spoofed source IP address to an information request. If the bogus reply arrives back before the genuine response comes from the server that was asked, the bogus reply may be cached.
Once a cache has been poisoned with false information in this way, any subsequent information request will be answered with this false information until the information expires. So if a corporate resolver is poisoned, local users will receive the poisoned information. If an ISP's resolver or a public resolver is poisoned, the effects will be much more widespread.
How long does the cache remain poisoned? DNS information has a time to live (TTL) associated with it -- the amount of time that it is valid before it expires and needs to be retrieved again from the authoritative server. The TTL for DNS information can be specified by the domain name owner, but getting it right is a fine balancing act.
If it is set to a long duration, any changes that the domain owner makes will take a long time to propagate through the Internet because the old, out-of-date information will stay in resolver caches for a long time before expiring. But if it is set to a short duration, any malicious changes made by a hacker will propagate more quickly -- and thus are more likely to come in to effect before the malicious changes are detected.
(In theory a hacker who manages to poison a cache could set the TTL of their malicious records to a period of weeks or months for a long-lasting effect, but most DNS software has a maximum TTL: seven days in the case of BIND, or 24 hours for Microsoft DNS.)
Compromising DNS Servers
A more effective way to compromise DNS is by changing the information in the authoritative name servers themselves. That can be done by compromising the server, perhaps by exploiting an unpatched vulnerability in the server's operating system or the DNS software itself. A simpler way is to use a technique similar to the one the SEA used to change the New York Times' records.
Here's how that technique works: A DNS server may be run internally by an organization or run by a third party like a domain name registrar on behalf of the domain name owner. In either case, the domain name records it contains will need to be changed or updated from time to time. To do this, an administrator needs to log on and carry out the changes or updates.
So if a hacker can access login credentials (perhaps by a simple social engineering or phishing email attack) then they can alter the DNS records and redirect traffic to their own site as effectively as if they had hacked the genuine Web server itself.
Preventing a DNS Attack
So what can you do to prevent your organization being the victim of a DNS attack?
Keep your resolver private and protected. If you operate your own resolver, its usage should be restricted to users on your network to help prevent its cache being poisoned by hackers outside your organization. It should not be open to external users. You can check for open resolvers on your network using The Measurement Factory's online tool.
Configure it to be as secure as possible against cache poisoning. Protections built in to DNS software to protect against cache poisoning include adding variability to outgoing requests, to make it harder for a hacker to get a bogus response accepted. Possible ways of doing this include:
- using a random source port (instead of UDP port 53)
- randomizing the query ID
- randomizing the case of the letters of the domain names that are sent out to be resolved. (That's because name servers will treat example.com and ExaMPle.com the same when it comes to resolving the IP address, but it will reply using the same case as the original query.)
Manage your DNS servers securely. When it comes to your authoritative servers, you need to decide whether to host them yourself or have them hosted at a service provider or domain registrar. "No one cares about your security as much as you do, so we advise hosting and managing yourself -- if you have the skills to do so," says Brenton. "If you don't have those skills, then of course it is better to get someone else to do it for you. It's not just a matter of expertise, but also of scale because many organizations need to have DNS servers in three or four places around the world."
If You Host Your Own DNS Servers
Don't get caught by known vulnerabilities. If you run your own name servers (probably BIND or Microsoft DNS), then it's vital to keep them (and the operating system on which they run) patched and up-to-date to prevent them being exploited by known vulnerabilities.
Separate the authoritative function from the resolving function using different servers. This reduces the possibility of your domains going offline from a denial of service attack.
Use a hidden primary master name server. If your primary name server is only used to serve data to slave name servers, this makes it much easier to carry out maintenance and upgrades on it without rendering your domain unreachable.
Monitor your name servers. Ensure you have visibility into their status and any changes made to them or unexpected behavior. The quicker you can spot malicious activity, the less likely your domain can be subverted.
Use PKI to protect your server. Use digital certificates to authenticate your SSH session when you log on to your DNS servers to make changes.
Use a hardened operating system or specialist DNS appliance. Minimize the attack surface of your DNS servers by closing unneeded ports and stopping unwanted services. DNS appliances typically offer hardened operating systems with automatic updates and protection against denial of service attacks -- but Brenton warns that vendors are often slow to supply updates and patches for their appliances.
If You Use a Domain Name Registrar
If your domain name servers are managed by a registrar or other third party, it's important to satisfy yourself that their operations and security measures are up to scratch. The following features, if offered, can help ensure that your DNS records remain secure:
- Two factor authentication. If an administrator can be social engineered or phished into giving up your DNS account details, your account may still be safe if access depends on a second authentication factor such as a security dongle or one-time password delivered to a mobile phone.
- DNS change locking. Some registrars offer specific security processes that have to be carried out before changes can be made to DNS settings. For example, a registrar employee may have to call a specific number to get verification from a named individual in your organization before changes can be made.
- IP-dependent log in. Some registrars allow you to specify a single or range of IP addresses from which you can log in to their systems. This won't protect against insider threats, but it can help keep you safe from external hackers. Brenton warns against specifying a single IP address, as this can cause problems if the machine at that address goes down, recommending instead a range of addresses.
- DNSSEC. DNSSEC http://www.icann.org/en/about/learning/factsheets/dnssec-qaa-09oct08-en.htm technology allows DNS information to be digitally signed so that a hacker can't forge it. "If a provider has not implemented DNSSEC, then you should be nervous," says Brenton. "If they don't have DNSSEC, then you have to ask yourself what other security measures they have missed out as well."
For more cybersecurity recommendations for DNS, the National Institute of Standards and Technology has published a Secure DNS Deployment Guide.
Paul Rubens has been covering enterprise technology for over 20 years. In that time he has written for leading UK and international publications including The Economist, The Times, Financial Times, the BBC, Computing and ServerWatch.