Unsure about your DNS security? Use a free, comprehensive vulnerability test

This week, I’m once again delaying the next installment in the business continuity event management series to discuss what I believe is one of the most valuable free solutions for identifying DNS risk—GRC’s DNS Nameserver Spoofability Test.  Since this is way too much to type, I’ll just call it “the Test.”

The Test, still getting its rough edges smoothed, is the work of Steve Gibson.  (If you don’t know who Steve Gibson is, you’re not listening to arguably the best security netcast ever produced, Security Now.)  The purpose of Steve’s project is to test DNS servers for common security vulnerabilities, such as the one identified by Dan Kaminsky earlier this year. 

Vulnerable DNS servers can be “poisoned,” causing users to go to malicious sites instead of the sites intended.  Once DNS services are compromised, Internet use is no longer safe.  In such cases, organizations may experience a business continuity event while the problem is fixed.

In order to better understand the how and why of the Test, let’s spend a little time looking at the problem.

How DNS works

DNS is a network service designed to translate domain names (e.g., adventuresinsecurity.com) to an IP address (e.g., 216.39.58.113).  Routers on the Internet use the IP address to send packets to the server hosting the desired Web site. 

A workstation “resolves” the domain name by sending a DNS query to a DNS server.  Within a corporate environment, this initial DNS server is usually on the internal network or hosted by the company’s ISP.  This initial DNS caching server is not authoritative (is not the official repository) for any domains other than those belonging to the managing organization, but it caches other domain name/IP address pairs resolved on behalf of internal users.

A DNS server resolves DNS names to IP addresses for which it isn’t authoritative through an iterative query process, as described in DNS Cache Poisoning: Definition and Prevention.  If the domain name requested by a user is found, the name and IP address are stored in the resolving DNS server’s cache.  Caching this information allows the server to resolve the domain name query locally, reducing resolution time and improving the user’s browsing performance.

The DNS Dilemma

In the early days of the Internet, security wasn’t a big concern.  The few servers connected for information exchange and research were controlled by ethical, responsible individuals.  Services like DNS were developed in this environment of trust, its developers never visualizing the explosion of their small network into a global phenomenon.  So DNS was never designed with security built in.

A vulnerability known for some time involves how query responses are managed.  When a resolver sends a query to an authoritative server, the response should exactly match the query.  Initial implementations of DNS had no way of checking this.  Servers owned by cybercriminals could force a DNS resolver to attempt to resolve a domain name they wanted to impersonate, for example, and then send response packets with an IP address of a malicious site.  The resolving server cached the malicious address instead of the real one.  The solution was to randomize previously sequential 16-bit transaction IDs.

A 16-bit transaction ID allows for 65,546 possible values.  One of these values is randomly assigned to a query.  Any responses received must also contain the transaction ID contained in the request.  This was considered “safe enough” until a few months ago, when a security researcher discovered a way around this control.

The researcher, Dan Kaminsky, found that by sending the same response packet with all possible transaction ID values, the correct ID would eventually be “guessed.”  So to increase the difficulty of spoofing a DNS query response, DNS vendors provided a fix which adds randomization of query ports to the mix.

Before this fix, most DNS servers simply established the name resolution service on a single port.  The port assigned for this, and most commonly used, was port 53.  With the new security fix, the port used for the query is randomized across 65, 546 possible port numbers.  The response to a query must be returned to the port from which the query was sent.  When implemented, the number of possible random transaction ID/random port number combinations is too high to make DNS response spoofing practical.

The Test

There are still some problems with DNS security, including a new issue that appears fixable only when DNSSEC is deployed.  In addition, over a million DNS servers still do not appear to use changing port numbers as a safeguard.  And many that do are configured to restrict the number of ports randomized or to use sequentially numbered ports, reducing the effectiveness of this security control.

So the Test, run from the GRC Web site, uses a virtual DNS server and a really big domain name string to force a large number of query resolutions from the DNS servers your workstation uses.  (See How This Works at the GRC site for more detailed information about what’s under the hood.)

I ran the test from my workstation at the office.  Figure 1 shows part of the results.  The Test determines whether DNSSEC is supported and how vulnerable the servers are to spoofing.  You can also customize how the Test behaves, as shown in Figure 2.

Figure 1

 Figure 2

The final word

If you are unsure whether your in-house or ISP DNS servers are vulnerable to spoofing, run this test.  If you receive a negative report from one or more servers (like I did), strongly encourage their administrators to secure their DNS services as soon as possible.  Poisoned DNS servers directly affect your ability to secure your network and continue Web-based services.