DNS has been a major security hole since it was first deployed, but until recently, not much had been done to patch the network service's security vulnerabilities. Beth Cohen reveals the largest DNS security holes, explores how you can protect your network from them, and introduces the IETF's new DNSSEC standard designed to prevent potential future catastrophic attack.
In July 1997, Eugene Kashpureff, founder of AlterNIC, took advantage of an inherent security vulnerability in DNS (Domain Name Service) and carried out the first DNS spoofing attack. "It's all done with standard MIME code, right out of the box. The only thing the bot does is make a couple of interesting small queries on a public name server," Kashpureff quipped.
Five years later, the security issues have become much more visible -- and problematic. On October 21, 2002, in an attempt to bring down the Internet, a group of hackers from South Korea and the U.S. flooded the thirteen domain name root servers using a common DDoS (Distributed Denial of Service) attack. Seven of the thirteen servers completely failed to respond to legitimate DNS requests, and two failed intermittently. And just last month, another DNS spoofing attack rerouted traffic intended for the Al Jazeera website to an American pro-Iraqi war site instead.
Fortunately, in all cases, the top-level server administrators were able to successfully counter the attacks, but all are in agreement that they might not be so lucky next time. Clearly the DNS infrastructure has major unaddressed vulnerabilities. What is the Internet community doing to improve DNS security? Fortunately, they're not sitting around idly, as the IETF (Internet Engineering Task Force) is drafting a new standard, DNSSEC (DNS Security Extensions), to combat the threats by providing end-to-end authenticity and integrity.
How can DNSSEC be implemented to prevent potential future catastrophic attack, and why has it not been widely deployed by the Internet community to date? What are the largest DNS security holes and how can you protect your network? Let's take a look at the answers to these and other burning DNSSEC questions.
Page 2: DNS Security Vulnerabilities
DNS Security Vulnerabilities
Ever since Paul Mockapetris published the original DNS architecture document in 1984, DNS has been the bedrock network service that supports the Internet. DNS has worked flawlessly for many years, but it was designed long before anyone was aware of the Internet security issues that have since developed. As the Internet has become an accepted part of the general community and no longer the province of a small club of highly technical engineers, integrity threats and the need for security awareness have increased.
Because DNS is a UDP-based (User Datagram Protocol) network service, it has a number of major inherent security vulnerabilities. Most are instances of more general problems, but a few are inherent to peculiarities of the DNS protocol itself. Unlike TCP (Transmission Control Protocol), UDP does not have a mechanism for verifying a packet source, which makes it very vulnerable to source packet spoofing and inception attacks. There are four major points of attack: cache spoofing, traffic diversion, denial of service attacks on the top-level domain servers themselves, and buffer overruns. Cricket Liu, Executive VP, InfoBlox, Inc., and author of O'Reilly's "DNS & BIND," notes that there have been recent attacks on the DNS infrastructure using each of the known DNS vulnerabilities.
How does a slave (secondary) know it is talking to the proper master (primary)? Because it is using UDP for communications, the data source is not verifiable, and the DNS data can be spoofed or corrupted on its way between the upstream primary server and the secondary slave. This is a major hole in the protocol. As the IETF threat analysis paper puts it, "The DNS protocol does not allow you to check the validity of DNS data. While packet interception attacks are far from unique to DNS, DNS's usual behavior of sending an entire query or response in a single unsigned, unencrypted UDP packet makes these attacks particularly easy for any bad guy with the ability to intercept packets on a shared or transit network."
When Kashpureff spoofed the servers, he inserted some additional code into his machine's standard DNS queries that forced victims' machines to respond to his servers. When they did, an extra "A record," was sent to the victim's name server that included information on how to connect to Kashpureff's domains. Kashpureff did it partially as a publicity stunt for his alternative domain namespace company, but the distributed and hierarchical nature of the data meant that corrupted DNS data might end up in downstream caches where it could persist. Caching servers have a variable TTL (Time to Live). If the TTL value is set very high -- a week for example -- the corrupted data can cause harm for quite some time.
Another common attack is where "falsified" DNS responses divert traffic away from the intended site. The socially engineered "hijacking" of aljazeera.net -- the Al Jazeera website -- apparently by US-based pro-war extremists is a good example. In this case, information about the ownership of the domain was modified so that it no longer pointed to the correct set of servers. If a user attempted to access the site, they saw the "hacked" web pages even though the Al Jazeera site itself wasn't touched.
BIND, the software that handles the DNS requests, has several built-in vulnerabilities to buffer overrun attacks. These are well-known holes where large numbers of service requests cause the software to overrun into memory buffers not allocated to the program. These can be exploited in a number of nefarious ways to cripple the application or bring down the server. A recent and very disturbing example was the Li0n worm exploitation of a hole in a series of March-April 2001 attacks on the TSIG (Transaction Signature) code (part of the new DNSSEC BIND implementation).
Distributed Denial of Service Attacks
DDoS (Distributed Denial of Service) attacks are simple to mount and incredibly difficult to prevent. Because ICMP requests are the basic mechanism used to monitor the health of the Internet, it is nearly impossible to secure this against attack. The hierarchical nature of DNS, combined with the tiny number of top-level domain servers, makes them particularly tempting hacker targets as was confirmed by the October attack mentioned earlier.
Page 3: How DNSSEC Works
How DNSSEC Works
From our discussion so far, it is clear that DNS has some major security issues that urgently need to be addressed. The Internet and security engineering communities have responded to the threats by developing DNSSEC, a new secure DNS protocol, which addresses the data integrity and source-spoofing issues by means of a public key distribution. Interestingly, the extensions do not protect against buffer overruns or DDoS types of attack, nor do they provide confidentiality -- another major issue.
To maintain as much backwards compatibility as possible, the DNSSEC protocol requires only minor changes to the DNS protocol. DNSSEC has added four additional record types (SIG, KEY, DS, and NXT) and two new message header bits (CD and AD). Because the UDP protocol has a packet size limit of 512 bits, DNSSEC requires the use of EDNS0 extensions that override the limitation so that larger key sizes can be accommodated.
The DNSSEC implementation uses the familiar public/private key system. The site administrator generates a key pair for the secured domain. The private key is generally kept on the domain's primary master name server, and the public key is published in the domain in a KEY record. The administrator signs the domain's data record to verify its authenticity and adds a SIG record, which contains the signature for each domain record. The administrator submits the public KEY to the administrator of the domain's parent to sign with proof that he is the administrator of that domain. The parent domain's administrator signs the domain's public KEY and returns it. Unfortunately, a major unresolved issue is that nobody has really determined key authentication and verification methodologies. How keys are configured initially and how they are updated has yet to be determined as well.
DNSSEC solves many of the worst DNS security problems. It is based on generally known technology and is backwards compatible with the existing DNS infrastructure. It is completely transparent to the user population and downstream administrators if they choose not to implement the extensions. While it does require installation of BIND 9 or later, you should upgrade to BIND 9 for many other beneficial reasons.
So why has DNSSEC not been widely adopted by the Internet community to date? After all, increased security of such a vital service should be an important priority for the maintenance of the Internet. Unfortunately, the implementation of DNSSEC is problematic because of the large increase in the computational load it puts on the servers, the hierarchical model of trust, the lack of tools to support the additional administrative overhead, the need for a higher level of time synchronization between the servers, and most critically, DNSSEC by itself does not begin to solve all the known DNS security vulnerabilities.
Increased Computational Load
DNSSEC significantly increases the size of DNS response packets, which drastically increases the computational load on the DNS servers and also increases the query response time. Just the process of verifying signed resource records is computationally intensive, particularly if you choose larger key sizes. The DNSSEC standard allows up to 1024 bit keys. Adding digital signatures to a domain increases each record size 5-7 times, which puts a burden on upstream name servers.
Hierarchical Trust Model
Like DNS itself, DNSSEC's trust model is almost totally hierarchical. Any compromise in the chain between the root servers and a target machine can damage DNSSEC's ability to protect the integrity of the data owned by that downstream system.
Lack of Management Tools
DNSSEC is an order of magnitude more complex than DNS. Since the system is relatively new, there are few tools to help with the cumbersome task of maintaining a signed domain. Serious problems can occur with configuration errors and expired keys, and monitoring and log analysis tools are virtually non-existent. Debugging the errors by hand can be time consuming and difficult.
Forces Stricter Time Synchronization
DNSSEC requires at least some time synchronization between the primary and secondary name servers. This is problematic because NTP (Network Time Protocol) itself is insecure, which opens up the possibility of DoS attacks based on invalid times.
Page 4: What Can I Do Now?
This article was originally published on Monday May 12th 2003
What Can I Do Now?
You can turn on DNSSEC today if you have BIND 9. You need to distribute the keys to your upstream provider (provided they support it as well). The majority of the implementations so far have been on military networks, so you are unlikely to have access to those servers. There are things you can do in the meantime to minimize your vulnerability to attack while the top-level Internet community finalizes the specifications and works out the deployment bugs.
Cricket Lui has created a handy check list to help you:
- Get educated -- buy one of the many good books on DNS or take a class on DNS
- Review your name servers' configurations and the contents of your zones
- Use publicly available tools such as dnswalk
- Eliminate single points of failure in your DNS infrastructure
- Make sure your name servers are authoritative for the reverse mapping zones that correspond to all of your networks
- Minimize the burden you place on "high-level" name servers (such as the roots)
- If you use RFC 1918 address space, set up the corresponding zones on your name servers
- Make sure your firewalls allow DNS messages from port 53 to high-numbered ports on your name servers, or you won't get responses
- If you use Active Directory or Windows 2000/Windows XP's network registration features, make sure that your dynamic update and query traffic remain local
- Your name servers must be authoritative for a zone with the same name as the name of your Active Directory domain
In today's ultra security-conscious environment, an inherent security vulnerability is an open invitation to intrusions from harmless -- and not so harmless -- hackers. DNS has been a potential security hole since it was first developed and widely deployed, long before anyone took network and computer security seriously, but until recently, not much had been done to patch the vulnerabilities in DNS. IETF's new DNSSEC standard is the first step in the long process toward completely securing DNS and should be able to help improve the overall security of the Internet if its problems with trust, lack of tools, and packet size can be overcome.
http://www.dnssec.net/ - The official DNSSEC website with all the resources on this subject in a nicely organized fashion
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-02.txt - A recent analysis of the security threats against DNS
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-05.txt - The IETF draft of the DNSSEC protocol
http://www.isc.org/products/BIND/bind-security.html - A list of the known vulnerabilities in BIND and their patches.
http://www.cert.org/advisories/CA-2002-19.html - Buffer overrun vulnerabilities and patches
http://www.icann.org/committees/security/dns-security-update-1.htm - ICANN committee report on DNS vulnerabilities
http://cyber.law.harvard.edu/icann/mdr2001/archive/pres/lewis.html - Paper on DNS Security Vulnerabilities
See All Articles by Columnist Beth Cohen