Shocker DNS spoofing vuln discovered three years ago by a student
The mad woman in the attic
Agentless Backup is Not a Myth
A flaw in how the internet's addressing system works that sparked a patching frenzy on Tuesday night may has first been uncovered by a student as long as three years ago.
Shortcomings in how the Domain Name System protocol is implemented by multiple vendors facilitate DNS cache poisoning attacks, security clearing house US CERT warned on Tuesday. Successful exploitation of these security shortcomings creates a means for hackers to spoof DNS replies, allowing for the redirection of network traffic or to mount man-in-the-middle attacks.
Security researcher Dan Kaminsky deserves a lot of credit for realising the seriousness of the flaw and working behind the scenes with multiple vendors over recent months leading up to co-ordinate this week's patching activities. But Kaminsky may not have been the first to discover the flaw, only the first with enough clout to mobilise action.
Three years ago Ian Green, then studying for his GIAC Security Essentials Certification (GSEC), submitted a paper that details the same DNS spoofing vulnerability, the SANS Institute's Internet Storm Centre notes.
In order to spoof a DNS request it's necessary to "guess" both the Query ID and the source port. The query ID is 16 bits long, and the UDP source port also has over 60,000 potential option. But as Green noted back in January 2005, DNS transactions are incremented by one for each subsequent query while the UDP source port remains the same during a session.
Although the weaknesses of the DNS protocol have been known for some time, Kaminsky's upcoming presentation at Black Hat next month is sure to put what has been a peripheral, forgotten issue (something like the mad woman in the attic) into the full view of the public. Details of new tools designed to exploit the vulnerability or exploits already in the wild are likely to emerge. ®
COMMENTS
@Eric Pinkerton
> In my understanding it follows that if the UDP transaction ID is predictable, > the default TCP transaction ID is likely to follow suit, thus it is still vulnerable, > allbeit to a slighlty more sophisticated attack.
The transaction ID is part of the DNS query/response, therefore application-layer, unrelated to the underlying transport-layer protocol.
The benefit I'm suggesting is that using TCP instead of UDP, the user's computer must actually connect to the legitimate name server* and exchange the query and response with it. An attacker spewing a barrage of bogus A and Additional records from his machine located at some arbitrary IP address won't fly even if the attacker knows or guesses the transaction ID and victim's source port; the victim is not connected to it and therefore not paying any attention to it.
Also, using TCP for DNS does not require any new development; the capability has always been there. Doing this would mean simply turning off DNS via UDP.
> Better to come up with a fix tha[n] a workaround.
No disagreement there. My suggestion is far from ideal, and has costs. The plus side is that it requires no overhaul of the DNS and can be done quickly.
* This presuming the attacker does not have sufficient control of the victim's network to impersonate these connections, something very unlikely.
@ "patched in minutes"
> i'd love to move to something more more security... but i dont see
> DNSSEC being properly taken up widely for years and years to come :-(
It's coming, and fast. Implementation at the TLD level is getting closer and closer - at least 4 TLD's are now signed, plus some parts of in-addr.arpa. The new DLV service offered by ISC and others makes even the lack of signing of TLD's less of a barrier.
@ JonB
> How come there hasn't been a massive exploit of this, potentially lucrative flaw?
Oh but there has been. It's called "pharming". Been going on for years.
The secret shortcut Mr. Kaminsky has "discovered" is simply that you can rather easily get the source port used for queries, because it's unchanging. That reduces the problem to the query ID, which in some vulnerable implementations is entirely predictable (bad entropy algorithm). At best, this is a 16-bit random number - how secure is 16-bit crypto?
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Agentless Backup is Not a Myth
