On Tuesday, 8th July 2008, multiple vendors published patches for Domain Name System (DNS) software after a coordinated effort to mitigate a widespread vulnerability arising from deficiencies in the DNS protocol and common DNS implementations which would allow DNS cache poisoning attacks. Earlier this year Dan Kaminsky, a security researcher at IOActive, reported the flaw to authorities (including US CERT) after which engineers from multiple vendors around the world gathered, at the end of March 2008, to coordinate Tuesdays release of software fixes.

DNS, Background

The Domain Name System is critical for the normal operation of networked computers and the internet as a whole. DNS is a distributed system of Domain Name Servers which translate Domain Names (such as "google.com") to their respective numerical IP addresses (such as 72.14.207.99) and vice versa for DNS clients or resolvers. DNS allows the assignment of Domain Names to be independent of addressing by numerical IP address. At the top of the hierarchy are the Root Name Servers which provide authoritative answers to queries regarding Top Level Domains such as .com or .org. Each domain has one or more Authoritative DNS servers that publish information about that domain and the name servers of any domains subordinate to them. Resolving/Caching Name Servers will forward queries from clients (those requesting recursive queries) to other resolving and authoritative Name Servers, receive answers from these servers and pass the answer back to the clients from which it received queries. The vulnerability primarily affects Caching Name Servers which store, for a limited period of time, the answers received in response to their queries so that they can more readily provide those answers to clients and to avoid repeatedly requesting the same information. Cache poisoning involves providing bogus DNS information to a Caching Name Server so that queries to it from clients will be answered with the bogus DNS information. Cache poisoning allows a malicious party to control the destination of IP traffic from computers that request DNS information from a poisoned DNS cache.

The Flaws

In order to poison the DNS cache of a caching name server with bogus DNS information a malicious party must provide an acceptable answer to a query made by the name server before any other acceptable answer is received. To ensure that a bogus answer is acceptable requires that:

1. The question section (comprising QNAME, QCLASS and QTYPE) of the DNS answer is identical to that of a DNS query currently waiting for an answer.
2. The ID field of the DNS answer must be the same as that used in the DNS query.
3. The source IP address of the DNS answer must be the same address to which the DNS query was sent.
4. The answer must be directed to the same UDP port at the same IP address from which the DNS query was sent.

Cache poisoning is possible because the DNS protocol is used atop the User Datagram Protocol which is a connectionless transport protocol and because the above four requirements can be met by a malicious party.

1. To satisfy the first condition is trivial since if the malicious party wants to manipulate the IP address of any given domain, they need only issue a DNS query to the target caching name server for that domain. If the applicable information is not in the servers cache at that point, it will issue it's own query for that domain containing the same question section supplied by the malicious third party.
2. The DNS ID field is a 16 bit number which allows for 2^16 (65536) possible variations. Some DNS implementations increment this field sequentially and it may be possible for a malicious party to limit the number of likely ID numbers by predicting possible numbers or by issuing a query to the target name server for a domain to which the malicious party owns or has access to an authoritative name server and thus capturing the UDP traffic. Moreover, some DNS implementations do not use the entire 16 bits of the ID field. In any case, a malicious party would need to issue at most 65536 UDP packets containing the bogus DNS answer.
3. It is trivial to spoof the source address field in a UDP packet and a malicious party would need only to know the IP address of the name server to which the target name server sent a query.
4. Current DNS implementations often bind to a UDP port when the service starts and will continue to use that same port until shut down. It may be possible for a malicious party to determine, before a poisoning attack, the source UDP port and IP address used to send DNS queries by the target caching name server. This information could be obtained, for instance, at the same time as the value of the ID field in 2) above and is detailed in a paper by Gamma from August 1998.

A malicious party could also take advantage of the fact that it is possible to send multiple queries for the same information which increases the number of ID numbers for which there are outstanding queries thus making it more likely that one of the bogus replies would be accepted as an answer.

Not a new flaw

The inadequacy and predictability of the 16 bit ID field in the DNS header was noted in section 5.3 of a paper by Steven M. Bellovin (pdf) of AT&T Bell Laboratories in 1989, in a paper by Paul Vixie of Internet Software Consortium in 1995 and in a post by Daniel J. Bernstein to the mailing.unix.bind-users newsgroup in 2001. In his post, Daniel, a professor in the Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago, spelled out the increase in cost of a Normal Blind Attack against the Berkeley Internet Name Domain DNS implementation if the ID value and the source UDP port of a DNS query were selected using cryptographic randomisation. The Fix

In order to mitigate the possibility of a successful exploit vendors have addressed three main flaws:

• Predictability of the ID field
• Multiple outstanding requests for the same information
• Fixed source port for generating queries

The US-CERT Vulnerability Note VU#800113 lists Systems known to be vulnerable, known to be invulnerable and those for which it is currently unknown as to whether vulnerable or not. There are links to more information about the products affected for each vendor. There is also information regarding what steps to take for users and administrators of affected products.

Dan Kaminsky's role

Earlier this year Dan Kaminsky evidently discovered (pdf) a reliable (and perhaps, much easier) method of exploiting the known flaws in popular DNS implementations and has been instrumental in bringing together the vendors who have reached consensus about how to mitigate the vulnerability and who have worked to implement the fixes before a coordinated public release. Dan's goal was to minimise the risk that malicious individuals could figure out the vulnerability before all vendors were able to offer updated versions of their DNS implementations. Dan intends to make public his exploit in a Black Hat USA 2008 Briefing on August 6th after which time the exploit will become public knowledge and it is highly likely that malicious individuals will have a field-day with any unpatched vulnerable systems very soon after (or possibly before, should the exploit is independently 'discovered').

On his website, Dan has made available a tool to allow visitors to check the susceptibility of the caching/resolving name server currently in use by the visitor. The tool displays the IP address of the resolver and the source port and ID field used in five queries to a seemingly random (and non-existent) subdomain of a domain registered for DoxPara Research. The tool reports whether the resolver used is vulnerable based, seemingly, on the source port and ID field. Yesterday, the resolver belonging to my Internet Service Provider made 5 queries from the same source port and with sequential ID's. Today, the resolver seems to have been patched:

Your name server, at X.X.X.113, appears to be safe.
Requests seen for 0c65d2323d50.toorrr.com:
X.X.X.113:3659 TXID=58111
X.X.X.113:18960 TXID=46569
X.X.X.113:47258 TXID=39068
X.X.X.113:64955 TXID=18071
X.X.X.113:17764 TXID=1625

What is really interesting about this story is the coordinated effort by security researchers and industry players to help make the internet a safer place for everyone. It only now requires users and administrators of name servers to follow the advice given and apply the patches. Early indications are that this is already happening.