|)ruid and HD Moore release part 2 of DNS exploit

[Updated 07/24/2008: Gallery images of diffs of code revisions has been included and will be updated as things change, see here.]

Earlier today, noted researchers |)ruid and HD Moore released exploit code for the Metasploit tool for attacking the DNS flaw that was originally reported by Dan Kaminsky. The release was only part of the bigger picture of the exploit; however, and the second piece of exploit code has been released on the Computer Academic Underground blog and on Full-Disclosure. There is a subtle but important difference in the two pieces of exploit code, which is only readily apparent from reading the comments in the source code. Part 1 of the exploit, released earlier today, is commented as below:

This exploit attacks a fairly ubiquitous flaw in DNS implementations which Dan Kaminsky found and disclosed ~Jul 2008. This exploit caches a single malicious host entry into the target nameserver by sending random sub-domain queries to the target DNS server coupled with spoofed replies to those queries from the authoritative nameservers for the domain which contain a malicious host entry for the hostname to be poisoned in the authority and additional records sections. Eventually, a guessed ID will match and the spoofed packet will get accepted, and due to the additional hostname entry being within bailiwick constraints of the original request the malicious host entry will get cached.

Part 2 of the exploit, released just moments ago, is commented as follows:

This exploit attacks a fairly ubiquitous flaw in DNS implementations which Dan Kaminsky found and disclosed ~Jul 2008. This exploit replaces the target domains nameserver entries in a vulnerable DNS cache server. This attack works by sending random hostname queries to the target DNS server coupled with spoofed replies to those queries from the authoritative nameservers for that domain. Eventually, a guessed ID will match, the spoofed packet will get accepted, and the nameserver entries for the target domain will be replaced by the server specified in the NEWDNS option of this exploit.

So let's analyze this a bit, see if we can figure out what's different. Good friend and noted researcher, Billy Rios, assisted me with some code review, and we tried to find as much as we could about this new twist on events. We found several things of note. The most obvious, the exploit just got worse. Now the code will use spoofed replies to hijack the name server entries for a target domain, allowing control over an entire domain, whereas the original hijacked an individual host. For example, before, we could hijack www.myaddress.com, now we can hijack all of myaddress.com.

Further, within the credits portion of the code, |)ruid adds credit to a new researcher for "helping with the NS injection" confirming the idea that this is now about attacking nameserver entries, and not just address records. The credits are listed below:

Credits ======= Dan Kaminsky is credited with originally discovering this vulnerability. Cedric Blancher <sid (@) rstack.org> figured out the NS injection method and was cool enough to email us and share!

Rios and I suspect that Cedric probably made use of the following from RFC 1035:

NS authoritative name server, code 2. Specifies a host name (which must have an A record associated with it), where DNS information can be found about the domain name to which the NS record is attached. NS records are the basic infrastructure on which DNS is built; they stitch together distributed zone files into a directed graph that can be efficiently searched.

Next, Rios clued me into a very interesting observation... as he said, "it went from rev 5585 5591 that's 6 different changes in a few hours... it's still being tuned." Which means it's going to get faster. Dan originally stated he could pull this off in a matter of seconds. With able programmers refining the existing code, it's only a matter of time before this exploit becomes lightning quick.

Work to make the exploit quicker may be confirmed by noting that there has been changes to the rand code for the xidbase.

So things are getting worse. If you have not patched by now... well, you're on your way to being pwned, so I'd get to it ASAP.

-Nate