Last updated at Wed, 26 Jul 2017 16:39:47 GMT
If you haven't already noticed by now, we've recently published two modules which exploit Kaminsky's DNS cache poisoning flaw. I'll get to those in a second, but first a word about disclosure.
In the short time that these modules have been available, I've received personal responses from a LOT of people, spanning the spectrum from "OMG how could you do this to the Internet users???" to "Great work, now I know what I'm up against... We need more open researchers like you guys." In all honesty, I was content to wait for Kaminsky's presentation at BlackHat before coding these up, because I didn't have the details and was too busy to go figure them out. But once public speculation started nailing the issue (form your own conclusions on whether the speculation itself was "responsible" or not), and then the accidental leak of the full details, followed by Kaminsky's describing the bug himself via a story on how he found it in an interview shortly thereafter, working exploits being created was only a (likely, short) matter of time. I was personally aware of multiple exploits in various levels of development before, during, and after HD and I wrote ours, so we felt at this point publishing working exploit code was fair game. We hope that all of you who were unfortunate enough to not have the vulnerability information shared with you originally all enjoy testing your nameserver implementations and products, and get your own patches out (or in the consumer case, applied) posthaste.
So, on to our new modules. There's no reason to rehash the deep tech regarding packet formats and spoofing techniques, as most of the speculation linked above was correct, and the original leak has been mirrored just about everywhere. In short, the way this flaw works is that it combines two previously known but somewhat mitigated flaws to achieve success:
The first flaw is that since DNS (over UDP) is connectionless, it can easily be spoofed. The original primary mitigation against this was to make use of a 16-bit transaction ID which is used to correlate requests and replies that the attacker would have to guess in order to correctly spoof a reply packet. This makes spoofing harder, but not an insurmountable task; you just need to be able to send a whole lot of packets to eventually get one right at match the transaction ID chosen for the request packet.
The second flaw was that additional records would be inserted into the cache which were included in replies from another nameserver. This is core protocol functionality, however the original problem was somewhat mitigated by creating the in-bailiwick constraints that essentially limits the domain space for additional records that could be sent in the replies to hostnames from a given domain. Sounds reasonable; this prevents nameservers from doing malicious things to records in domains that they weren't queried for or aren't authoritative for, while still allowing nameservers who are authoritative for a domain to update the records they need to.
When you combine the attacks for these two flaws however, and introduce nameserver query recursion, an attacker can essentially cause the target nameserver to make as many queries as the attacker wants while also pretending to be the authoritative nameserver and spoofing the responses, achieving the birthday attack against the transaction ID and successfully updating the nameserver record for a domain to point to a malicious nameserver address. You can also use this trick to inject cache entries for individual hostname records as long as those hostnames are both not already cached, and also in-bailiwick.
The two Metasploit modules which implement these attacks are "DNS BailiWicked Host Attack" for injecting individual uncached host records into the target nameserver's cache, and "DNS BailiWicked Domain Attack" for replacing a target domain's nameserver records in a target nameserver's cache. Currently these must be run from the MSF "trunk" development branch, as they rely on Net::DNS and raw sockets functionality which currently only exists in the development branch for MSF. The raw sockets code also currently only works when running MSF under Linux.
