DNS Flaw Causes Global Panic - Flaw Exposed
(Page 2 of 4 )
Here's how it happened: someone thought it would be a good idea to post speculations about the details of the flaw on their blog. That's right. Someone posted something nefarious on a blog. Who could have predicted such an anomaly? Besides everyone.
Anyway, when Halver Flake mused on his blog about the vulnerability, someone from the security research firm Matasano, who already knew the details, published them on their own blog. One can only assume they didn't want to be shown up by someone other than Kaminsky. Regardless, the post was quickly removed, but not before others could mirror the information.
This was not good news. At the time, 52 percent of DNS servers had not deployed the patch and were still vulnerable. It was only a matter of time before someone would create an exploit code for the flaw.
It turns out it took less than a day. An exploitation that allows the insertion of malicious DNS entries into the cache of target servers was posted to Metasploit, which provides information and tools on exploit techniques. The one constraint that the exploit had was that it could not overwrite an existing cache entry. However, it will display the expiration date for pre-cached entries and wait the required time before completing the attack.
Again, warnings were issued (this time from CERT) to patch vulnerable systems as soon as possible. The vulnerability is in the DNS protocol and is not specific to a particular vendor, so it is imperative that all vendors react to the problem and patch if necessary. The vulnerability itself is not patched; it merely makes exploiting the flaw more difficult. This particular flaw, however, can make successful attacks even more destructive than prior DNS exploits, which have been around for over a decade.
The usual cache poisoning attack is what Kaminsky refers to as a race between the good guy and the bad guy. When a DNS lookup request is made, the good guy knows the secret code that verifies whether the response to the request is authentic. The bad guy doesn't have the code, but does decide when the request goes out and, thus, knows about the request before the good guy. The good guy wins the majority of the time, but this new exploit targets the system in a different way.
Next: Patch Now! >>
More Web Hosting News Articles
More By Michael Lowry
