DNS resource record integrity is still a big, big problem
Posted on: November 18, 2008
Taken From techrepublic.com.com, November 17th, 2008
The need to secure DNS has never been greater. Attacks against DNS cache integrity, including entire zone references, are an easy way for criminals to redirect your unsuspecting users to malicious sites. The IETF and others are working on a set of security extensions to protect the integrity of DNS information as it is shared across the Web. However, these extensions, known as DNSSec, are far from globally accepted, and it will probably be years before they are implemented for all DNS transactions.
So what can you do today to protect your users? Quite a bit, actually. But before we get to the DNS security checklist developed by the U.S. National Institute of Standards and Technology (NIST), it’s important to understand the role DNSSec will play in the future and why its implementation is an important part of global Internet security.
In this article I review how DNS works and I define DNS cache poisoning. In the next article, I describe DNSSec, how it will eventually provide protection from malicious redirection, and what you can do until DNSSec becomes a reality.
DNS review
The DNS (Domain Name System) is a critical component of not only the Internet, but also internal network operation. It uses distributed repositories to convert human-friendly addresses to IP addresses. For example, converting the domain name google.com to 64.233.187.99 or mail.google.com to 64.233.183.17. Routers need the numeric version to make sure packets make it to the right network segment, no matter where it might exist.
Figure 1 depicts the IP address resolution process when the target system and DNS server are both internal. In this example, a workstation must establish a session with a server in Farpoint.company.com. In order for a workstation to implement DNS, it must be running a DNS Client or Client Resolver. The resolver initiates the following process, resulting in the conversion of the domain name to an IP address (Microsoft TechNet, 2008).
Figure 1
Step 1: The resolver checks the resolver cache in the workstation’s memory to see if it contains an entry for Farpoint.company.com. The entry would be present if the workstation had resolved the name to an IP address since the last time it was powered on, and the Time to Live of the entry had not been exceeded. In this example, no entry is found.
Step 2: Having found no entry in the resolver cache, the resolver sends a resolution query to the internal DNS server.
Step 3: When the DNS server receives the query, it first checks to see if it can authoritatively answer a query about resources in company.com. If it can, the server performs a lookup in its internal zone table. In this case, it finds a host Resource Record (RR) that includes the IP address for Farpoint.company.com.
Step 4: The IP address of Farpoint.company.com is returned to the resolver.
Step 5: The resolved domain name and IP address are placed into the resolver cache. Figure 2 is an actual listing of the contents of a workstation resolver DNS cache.
Figure 2
In the previous example, the target server was located within the requestor’s network. But what if the target device is located somewhere on the Internet? In that case, the process is somewhat different. Please refer to Figure 3 as we step through this second DNS resolution process.
Figure 3
Step 1: The resolver checks the resolver cache in the workstation’s memory to see if it contains an entry for Farpoint.companyA.com.
Step 2: Having found no entry in the resolver cache, the resolver sends a resolution request to the internal DNS server.
Step 3: When the DNS server receives the request, it first checks to see if it’s authoritative. In this case, it isn’t authoritative for companyA.com. The next action it takes is to check its local cache to see if an entry for Farpoint.companyA.com exists. It doesn’t. So in Step 4 the internal DNS server begins the process of iteratively querying external DNS servers until it either resolves the domain name or it reaches a point at which it’s clear that the domain name entry doesn’t exist.
Step 4: A request is sent to one of the Internet root name servers. The root server returns the address of a server authoritative for the .COM TLD (Top Level Domain).
Step 5: A request is sent to the authoritative server for .COM. The address of a DNS server authoritative for the companyA.com domain is returned.
Step 6: A request is sent to the authoritative server for companyA.com. The IP address of Farpoint.companyA.com is returned.
Step 7: The IP address for Farpoint is returned to the client resolver.
Step 8: An entry is made in the resolver cache, and a session is initiated with Farpoint.companyA.com.
This process, from the client resolver perspective, is known as a recursive query.
A summary of DNS cache poisoning issues
When attackers want a DNS server to hand out IP addresses to their servers, they must use some method of replacing valid addresses on the caching server with their own. There are few controls to ensure the integrity of a query response, that it came from a server authorized to provide resolution information. Once the attacker’s information is written to a caching server or to a resolver’s cache, DNS cache is said to be poisoned. A more detailed description of one way this might happen is found in DNS Cache Poisoning: Definition and Prevention. Another method, recently disclosed by Dan Kaminsky, is described in An Illustrated Guide to the Kaminsky DNS Vulnerability.
One method developed to help prevent cache poisoning is randomization of the transaction ID. Each DNS query is assigned an ID. Randomizing this value makes an attacker’s job a little harder. Current DNS solutions support this feature, but Kaminsky demonstrated that it isn’t enough to provide reasonable and appropriate protection.
Adding query source port randomization to transaction ID randomization is a good way to increase an attack’s work factor. Instead of an attacker knowing only the transaction ID, he or she also has to know the port from which the transaction was sent. A securely configured DNS server using the most current iteration of BIND, for example, could randomize the port used instead of settling on port 53.
Although this is a big step forward, there are still many DNS servers not using this feature, putting systems querying them at risk. And even if all DNS servers on the Internet used a combination of transaction ID randomization and source port randomization, this should be considered an interim solution at best. The entropy provided is not sufficient to dissuade a tenacious attacker.
The final word
In the next post, we’ll look at what international organizations are doing to strengthen DNS integrity via DNSSec. Since DNSSec is still far from globally deployed, we’ll step through the NIST checklist for securely deploying DNS services without it.
Mxin's Weblog 
Tinggalkan komentar