The DNS Exploit Revealed… and used

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.

attacks, mitigations

If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.