So, Dan Kaminsky’s DNS exploit I previously mentioned has been revealed. It turns out that what Kaminsky found was pretty much what I speculated — he just had it put together into a coherent attack, and fully recognized the implications.

If I want to poison your DNS server, say, to redirect www.yourbank.com to my malicious web server, I can make a DNS request to it and ask for www.yourbank.com. Your DNS server either already knows the address (because it’s in the cache), or it sends a request to yourbank.com (the top-level DNS name for www.yourbank.com) asking where to find it. This request has a random sequence number, called the XID, from 0 to 65,535 on it, and the reply needs to match that number to be accepted.

However, DNS works through UDP, which is spoofable. That is, the way you know where a UDP packet came from is… to take its word for it. UDP packets have a sender address attached. So I can request www.yourbank.com from your DNS server, then send a reply claiming to be “from” yourbank.com answering the request and pointing to my malicious web server. The only thing stopping me is the XID — I have to guess which XID your DNS server used, since I didn’t get to see the request packet. Ten years ago, there were ways to predict XIDs, but that’s all fixed now. So all I can do is flood you with hundreds of replies with different XIDs, and hope I guess the right XID before the real reply arrives. Once the real one arrives, it goes into the cache, and I can’t ask for www.yourbank.com anymore (well, I can ask, but the server won’t do the lookup — it already knows where the site is.) So it’s a race — can I guess the XID faster than the real DNS server can respond? Since I only get to try once, it’s a race that, as the attacker, I will almost always lose.

A bit about DNS replies — they can contain multiple bits of information. This is to cut down on requests, because sometimes one server has many names. For instance, if I request “login.yourbank.com”, the DNS can reply with a packet that essentially says “login.yourbank.com is actually www.yourbank.com, and by the way, www.yourbank.com is 1.2.3.4″. I can’t, however, do this with a totally different domain — I can’t say, for instance, “www.evilsite.com is actually www.google.com, and www.google.com is 6.6.6.6″, because the DNS server wasn’t asking about Google, so it’s not interested in hearing my DNS server’s speculation about where it is. This defense is somewhat whimsically called “baliwick checking.”

Here’s Kaminsky’s exploit: if I query your DNS server about an invalid subdomain, and provide in my spoofed responses a reference to something else in the same subdomain, then I can attempt to poison your DNS cache all day long, until I get it right. Say I can get 100 spoofed replies in before a real reply. Now I don’t query for www.yourbank.com — I query for 00001.yourbank.com, which does not exist. I spoof replies that say “00001.yourbank.com is actually www.yourbank.com, and by the way, www.yourbank.com is 6.6.6.6″. If that doesn’t work within half a second, then I’ve failed. And since I’ve got time for 100 replies, and only a 1 in 65,535 chance of any of them being right, I probably fail — the odds are only 1 in 655 that I’ll succeed. So… I just try again 654 more times, with 00002.yourbank.com, and so on.  Since I’m rotating subdomains, I never run into the case where it’s already cached and I can’t force a lookup.

It sounds so simple — because it is. It’s by-design behavior of DNS. It’s exactly how DNS has worked for 20 years. And it’s completely devastating. Armed with this knowledge and a DNS server you control (which you can set up in minutes on any Linux box), you can reroute any vulnerable DNS server on the Internet, forcing all customers who use that server to your malicious sites. According to Kaminsky, 52% of DNS servers are still vulnerable.

There’s already a Metasploit plugin (called Baliwicked) for both the malicious DNS server and the attack client. You’ll need to sync them from the live tree if you want them, as they’re not in the main Metasploit package yet. However, it gets worse — today, a new Metasploit plugin called Evilgrade was released which uses this ingeniously. Evilgrade uses the Baliwicked exploit to remap DNS for the sites used by the auto-update functionality in eight popular software packages (Sun Java, WinZip, WinAmp, Mac OS X, OpenOffice, iTunes, the LinkedIn Toolbar, Download Accelerator, notepad++, and speedbit) to a malicious web site (itself.) What do those auto-updaters have in common? They all call home, look for updates, and if they find them, download and install whatever’s there without checking to see if it’s real. With the DNS being redirected, this means they download arbitrary Trojan horse code from the malicious site and install it, telling the user it’s a “critical update” to their software.

You might notice that no Microsoft software is on the list. This is because Microsoft’s updater technologies are all based on Windows Update, which checks a digital signature on downloaded updates before running it. Since an attacker can’t spoof the signature without Microsoft’s private keys (which are very closely guarded), the MS auto-update is useless for this sort of attack.

Unfortunately, as an end user, there’s very little you can do to protect yourself from this sort of attack. Your ISP needs to update their DNS server — most have, at this point, but only a bare majority; many, many sites and ISPs are still vulnerable. Any HTTP site can be spoofed right now — only HTTPS sites are safe (and even those only if you check the certificate and don’t access sites with SSL errors.) And auto-updaters could be installing any number of things — Evilgrade is particularly bad because you don’t have to pick a site you know the victim will go to to spoof, because the auto-updaters will go to their home sites automatically, whether the user wants to or not.  If you use any of the products spoofed by Evilgrade, it would probably be a good idea to turn off auto-update for a few weeks.

The lesson here is that the security community needs to stop trusting DNS – it is not a security technology, it never was, and it is not designed to be reliable. However, old habits die hard, especially when there is no viable substitute for many scenarios right now.

On Tuesday, July 8th, Microsoft’s usual package of patches seemed to end-users like every other Patch Tuesday — some security updates to various and sundry Windows files to patch security vulnerabilities unknown.  However, it contained something very unusual this time — a design change to DNS.

DNS has been around since the 1970’s, so people don’t expect it to change much.  And this wasn’t an ordinary patch, fixing a bug in the code where it was behaving in an unintended fashion.  In this case, Dan Kaminsky found something potentially extremely serious in the designed behavior of DNS and reported it to all the major DNS vendors.  As a result, it wasn’t just Microsoft that released a patch, but also Apple, Cisco, and the Internet Systems Consortium (makers of BIND, the primary DNS daemon of the UNIX world.)

Dan did this in secret, to prevent people from exploiting the bug.  This led to a lot of skepticism about whether it was a “real” vulnerability, or just Kaminsky (a ubiquitous figure in the security press and an amusing character by anyone’s measure) engaging in self-promotion by pointing out something already well-known.

If the linked blog post seems confusing, what he is implying is that all Kaminsky “found” was the fact that the DNS sequence number, used to match DNS replies with queries, is extremely short, such that if you can send 65,535 spoofed replies to a DNS server before the real server manages to reply, you can poison the cache.  While this is true, and a problem, it’s been known for a decade and is not interesting.  It’s exploitable in another way, too — you could ensure your forged response gets in first by forcing a user to make many queries (e.g. by giving him a web page with tens of thousands of embedded images) with while you spoofed a flood of responses with constant sequence numbers.  If you attached CNAMEs to all of those, and put the images on subdomains of the target (e.g. 1.google.com, 2.google.com, 3.google.com, etc.), you could potentially clobber the DNS record for a top-level domain on the end-user’s server.

The end result of which would be that if a user visits your malicious web site, you change the IP that, say, google.com goes to for everyone using that DNS server.

However, bad as all that sounds, it seems that Kaminsky found something even worse.  All of the skeptics of his discovery who have been let in on the secret have come around to his side, and all the DNS vendors issued a design-change patch.  Among other things, this patch broke ZoneAlarm — everyone running ZoneAlarm found themselves suddenly unable to use the Internet at all.  (At least, so it appeared — my guess is that they were actually just unable to make DNS queries, but to a normal non-tech-savvy user this amounts to a total loss of Internet.)

So, what is this exciting new DNS vulnerability?  Right now, heaven only knows (well, and Dan.)  But Kaminsky has promised to tell us all about it at BlackHat 2008, and I’ll certainly be there to post the results here.  For now… patch your DNS servers.  The only hint we have right now is that source port randomization (one of the mitigations in the DJBDNS secure DNS package) would have stopped it.