DNS authentication vulnerable to cache poisening
July 22nd, 2008- Affects Windows, Unix/Linux, Juniper and Cisco products. This was first mentioned around July 7. But now we have a full discussion about responsible disclosure.
- Why does this vulnerability matter and why should it be out into the open?
- To make our DNS system more secure against such and other types of attacks for sure and because seucrity through obscurity is just plain dumb.
What is the technical issue
Vulnerable DNS software may be tricked into supplying incorrect IP addresses for requested hostnames. This could allow an attacker to redirect internet traffic to a possibly malicious website.
In practice this could work if an attacker manages to flood a DNS server with multiple requests for domain names. One example might be www.CyTRAP00001.com, www.CyTRAP00002.com and so on. Since the name server may not have seen these requests before it proceeds to query a root server for the name server that handles lookups for domains ending in .com. In turn, the attacker proceeds by using the information to send fraudulent lookup information to the DNS server and make it appear as if it came from the authoritative .com name server. Unfortunately, once enough requests have been issued, one of these spoofed requests could just match and the IP address for a requested domain will be falsified.
How new is this?
The issue is not that new since a first alert has been issued around July 8-10 by some alerting services not providing many details.
Note the description section of SecPod ID: 10109 Multiple Vendor DNS Spoofing Vulnerability This advisory alludes to the critical element of bogus additional RRs. To our best knowledge it appears to be the only one that mentioned that problem.
What is the discussion right now - someone posting code
The question now is when a full description will be provided by someone posting working code? The exploit code has been available in certain circles for some time now. By posting the vulnerability and making the details available, responsible security engineers would then have the possibility to check if the problem exists regarding their systems and DNS handling.
Security advisories like the one below we got this morning are of little help because they do not provide a full description:
Neither do the solutions suggested take care of the problem described in the above advisory
The underlying premise of all the discussions is that we have to keep the details under wraps until Dan Kaminsky can present his findings at the Black Hat conference. Naturally, some researchers have posted some thoughts about this issue including a possible exploit of this vulnerability:
On Dan’s request for “no speculation please”
However, keeping information like a DNS spoofing vulnerability under wraps, while the bad guys know the details already is neither responsible disclosure nor helping in better protecting the internet. It actually increases our risks while helping Dan Kaminsky and Black Hat to get publicity. Is this ethical and responsible behavior?
Related Posts:
- IPv6 deployment 10 years after - is there a disaster in the making?
- DNSSEC - a global effort that experiences difficulties on the road to success
- Research that matters - Microsoft’s CAPTCHA approach is insecure
- proprietary encryption schemes are a bad idea
- Microsoft predicts rise of service interruptions with datacenters

















InfoSec