By Robert Vamosi
Defense in Depth
July 8, 2008
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
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
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
Attend Black Hat USA, August 2-7 in Las Vegas,
the world's premier technical event for ICT security experts.
Featuring 40 hands-on training courses and 80 Briefings
presentations with lots of new content and new tools.
Network with 4,000 delegates from 50 nations.
Visit product displays by 30 top sponsors in
a relaxed setting. http://www.blackhat.com