On Tuesday, security researcher Dan Kaminsky of IO Active calmly explained in a conference call with security reporters how he first stumbled upon a pervasive flaw deep within the Domain Name System (DNS), a series of servers used to translate common Internet names to IP addresses. Kaminsky said he wasn't even looking for a security vulnerability. What he found, however, could explain how criminal hackers have been able to redirect DNS queries recently.
What he did next is remarkable: he waited. Instead of selling the vulnerability to a company like TippingPoint through its program Zero Day Initiative, wherein the company would then handle the vendor contact and resolution, Kaminsky took the responsible step of contacting the most affected vendors himself. He discussed with them how best to address the flaw that resides at the most fundamental level of how the DNS currently works.
Together, Kaminsky and the vendors set a date of July 8 in which they would collectively announce and roll out the patches. In the meantime, additional steps were taken, such as notifying US-CERT (United States Computer Emergency Readiness Team) and CERTs in other nations, to minimize the possibility of criminals using the July 8 announcement to cause DNS havoc.
At Tuesday's press conference, Kaminsky refused to provide details about the flaw, preferring to give additional vendors and administrators affected at least 30 days to create or implement the patches.
But within the conference call, during the question-and-answer session, some details and clarifications emerged.
DNS servers translate a popular name such as CNET.com into its numeric IP address. There are 13 principal servers and many subservers located throughout the world to speed the process of IP resolution. Usually a DNS look-up query is assigned a random translation ID, but Kaminsky observed that when a vulnerable DNS server is able to perform recursive DNS queries, it was possible to guess the transaction ID and redirect the result.
DNS queries currently offer a transaction ID that is one of 65,000 possible values. The ID is supposed to be there on every legitimate response. But Kaminsky and others noticed that some weren't particularly random. What has been discovered is that 65,000 is just not enough, said Kaminsky.
Every query has a transaction ID between 0 and 65,000, and the reply must contain the transaction ID. Thus, it may be possible to guess these transaction ID values in advance and insert a malicious server as the authoritative DNS server for a popular bank or e-commerce site.
After applying the patch, Kaminsky said, the transaction ID would now contain the correct transaction ID plus the correct source port, a random identifier located at a different layer in the IP packet. He said when discussing remediation of the flaw the only place they could go for additional randomness within the current infrastructure was the source port. This would increase the size of the translation ID from, say, 16 bits to 32 bits, he said.
The IP protocol has a system for sending small messages and there are various headers. He said think of the source port in this case as a return address on an envelope; it's extra data in addition to the message you are sending. He said you can sign your name on the letter itself. You can also sign your name on the envelope as well. The patch does something similar with the translation IDs.
Kaminsky said he will release more details in time for Black Hat 2008, to be held August 7 and 8 in Las Vegas.
In the meantime he's set a high standard for responsible vulnerability disclosure.