Secure Computing: Sec-C

Today, nearly every major DNS provider issued patches for the same DNS vulnerability. However, the patch does not actually "fix" the problem; it just mitigates the core issue identified by Dan Kaminsky. In an interview on Martin McKeay's podcast, Dan was hesitant to describe the details of the vulnerability. However, the Internet Storm Center (ISC) has a good high-level description of the issue and solution.

The Exploit

In short: this is an old and well-known problem. Since DNS uses UDP, any DNS server that forwards queries to other servers becomes vulnerable to cache poisoning -- where an attacker answers first and with alternate information. For example, if your browser looks up "bankofamerica.com", then your DNS server will forward that query to another server. During this time, an attacker can forcefully put an IP address for the hostname that points to a phishing site or malware site or some other hostile location.

A variation of this attack occurs when the attacker both initiates and responds to the query. Here is how it goes:

1. The attacker issues one query that will be sent to a DNS server owned by the attacker. For example, "what is the IP address of mydomain.org?" This tells the attacker the source port used by the caching DNS server.
   
   
2. The attacker issues a query for the domain they want to hijack ("What is the IP address for citibank.com?"). By issuing the query, the attacker guarantees that the server will forward the request at the right time. The attacker can actually issue multiple queries, in case the DNS server will issue concurrent queries. (More queries lead to more opportunities for a successful attack.)
   
   
3. Since the query can have any of 65,536 different session numbers, the attacker only needs to respond with at most 65,536 packets that all provide an alternate answer. ("citibank.com is 1.2.3.4", an IP address owned by the attacker.) Moreover, if the DNS server increments the session identifier, then far fewer than 65,536 packets are required; the attacker already knows the current sequence number from the first query.
   
   
4. Caching DNS servers will hold onto the records until they expire. During this time, any subsequent queries against the caching server will receive the same false reply.

A New Exploit?

Although the mass media is crediting Dan Kaminsky with "discovering" this flaw, this is really not the case. The problem, as described by the ISC and CERT, is not new. This vulnerability was at the root of a series of attacks dating back over a decade.

This vulnerability is so old, that I even wrote about it in Chapter 17 of my book, Introduction to Network Security back in 2006. (For it to be in my 2006 book, I had to know about it in 2005, and I guarantee that I didn't "discover" it. I learned about it in the late 1990's. And even then, it was well-known.) As I wrote in Section 17.4.3 of the book:

In theory, a blind attacker must also guess the UDP port number. But most DNS servers reuse the same port number for subsequent queries. By reusing the same port, the DNS software does not need to manage a suite of UDP network connections and does not spend time binding to new UDP ports. Unfortunately, this also means that the attacker can determine the port to attack before initiating the attack. Although rare, DNS servers can rotate their UDP ports when making queries. This lessens the risk from a blind attack but increases the software complexity since multiple ports must be managed.

DNS cache poisoning attacks are in Section 17.4.2 and Blind ID Attacks are in Section 17.4.3.

The real thing that Dan managed to do was align all of the DNS vendors. According to the CERT advisory, the solution is to modify the DNS servers so random source ports are used. This does not remove the problem, but does make a blind exploit less likely to succeed. If the old attack required a maximum of 65,536 packets, the new attack would require a theoretical maximum of 4-billion packets (65,536*65,536) -- but a realistic complexity size is in the millions. (This exact solution was described in a posting to mailing.unix.bind-users back in 2001 -- and even then, it wasn't novel.)

The CERT advisory also mentions using all 16-bits in the session ID (yes, some vendors don't use all of them), using random session IDs (not sequential), and not sending duplicate queries when one query has already been sent. These may sound like "duh" issues, but they have been known for decades and nobody has bothered to fix them until now.

Additional Information

If you run a caching DNS server and forward requests to external or remote DNS servers, then be sure to patch your system.

Finally, if you are interested in learning more about DNS issues, consider some of these sources:

• Ian Green, DNS Spoofing by The Man In The Middle. SANS Institute, 2005.
  
• Irving, Christopher, The Achilles Heal of DNS. SANS Institute, 2003.
  
• Martin, Derek, Securing BIND: How To Prevent Your DNS Server From being Hacked. SANS GIAC Security Essentials Certification, SANS Institute, 2002.
  
• And for a great write-up of DNS's history: One History of DNS by Ross Wm. Rader, 2001.

[Update 9-July-2008]
Dan has set up a DNS self-test at http://www.doxpara.com/. The test appears to send five packets. The check seems to be looking for source ports that are constant, source ports that are sequential, or sequential DNS transaction IDs. If your DNS server has any of these, then you are vulnerable to a cache poisoning attack as I described above.