Dan Kaminsky's DNS Cache Poisoning Vulnerability Explained

There has been a lot of talk recently about Dan Kaminsky's DNS Cache Poisoning Vulnerability. Simply put there are an extremely large amount of publicly accessible DNS servers that can fairly easily be tricked into storing and serving up malicious DNS Information. The impact of this malicious DNS Information is that users can be unknowingly tricked into accessing malicious sites and possibly compromise sensitive information such as: username, passwords etc.

DNS Cache Poisoning attacks have been around for years now. However this vulnerability is far more exploitable and dangerous than its predecessors. Luckily for the world and all of its administrators, Dan Kaminsky of DoxPara Research raised awareness about the criticality of this vulnerability and coordinated a massive effort with vendors to issue patches. He gave vendors time to make patches and the public time to apply them before releasing all the details.

In regards to the exploitability of this vulnerability, there are a few challenges that need to be overcome by the attackers.

• Knowing when a DNS Server will issue a particular DNS Lookup: If the server doesn't already have the name cached, you can try to spoof the response right then, but you only get one shot.
  
• Guessing the DNS query's transaction ID: it should be possible to blast the server with 65,536 spoofed responses (one for each transaction ID). The fact that this ID is only 16 bit is generally accepted as being too weak.
  
• Creating a proper spoofed packet with poisoned information in it: Vulnerable DNS servers reuse the same source port for every outgoing request, which makes crafting the spoofed return UDP packets trivial (DNS servers that already randomized the source port are generally seen as being practically immune to this exploit, since attackers would have to guess nearly 2^32 combinations instead of only 65,536).
  
• Getting the spoofed response to the DNS Server before the real response: Latency may work against an attacker. But an attacker attacking his own ISP might not face either of these problems.
  

Overall, an attacker would need an insane amount of patience and luck to pull this off.

The steps an attacker would take to exploit this vulnerability would be something like:

1. Attacker asks Victim DNS Server: Who is gmail.google.com?
2. Victim DNS server asks the authority for google.com, Who is gmail.google.com?
3. Attacker blasts Victim with spoofed responses, each containing a different transaction ID. The packet contains a response with an IP for gmail.google.com, as well as an additional RR stating www.google.com is an IP address of the Attacker's choosing.
4. (Exploit) If a valid, spoofed response is received before the real response comes back, the Victim updates its cache with both the requested info as well as the poisonous IP information contained in the RR. The subsequent response from the authority for google.com is discarded.

This is repeated as necessary with new sub-domain requests, until one of the spoofed responses takes. When it takes, the attacker has circumvented the TTL problem and outsmarted the same-domain defense. Reports are this can happen in less than 10 minutes. i.e. 10 minutes to replace cnn.com, or youtube.com, or any other popular site with a site of your own choosing. This means for a certain period of time and for the users of your victim DNS Server you control where these popular websites point. You will be able to deface the website, show them information of your choice, or try to phish for their personal information.

An exploit is currently available from the Computer Academic Underground. It provides a good technical summary on the vulnerability and how exploitation works.

This exploit attacks a fairly ubiquitous flaw in DNS implementations which Dan Kaminsky found and disclosed ~Jul 2008. It 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 constraints of the original request the malicious host entry will get cached.

So what's the fix? There really is no fix, short of using DNSSEC, or moving to some other cryptographic method of trust. Using TCP instead of UDP has come up (this would add the additional, now nearly impossible challenge of guessing sequence numbers), but was shot down as being too resource intensive. So the accepted workaround is what was already mentioned above: DNS servers should randomize their source ports. Then attackers would have a much, much harder time spoofing the return packets.

For those of us out of India, I don't see much hope in waiting for your respective ISPs to patch. In the meanwhile I recommend switching to the DNS Servers from OpenDNS as a precautionary measure.