There has been a lot of hush-hush recently regarding a DNS security issue finding by Dan Kaminsky. Industry wide coordinated effort led by Dan ensured that patches were released by multiple vendors. Even though the technical details of the issue were not yet made public by Dan, an inadvertent leak by Matasano Security blog seems to have given out a lot of the information regarding the issue. At this time I cannot confirm that the findings published on the leaked (and subsequently removed) blog are in fact the same details that Dan is to make public at Black Hat, but the scenarios described in there are a very serious threat to the Internet at large. As has been discussed on a number of follow-on blogs and articles, the threat emerges from two different issues with DNS protocol.

1. Prediction of Source Port and Transaction ID: DNS primarily uses UDP packets to send questions and receive answers. The image below depicts a very simple scenario where a Client is trying to look up the IP address for www.bob.com.

Also, a DNS question (request) and answer (response) UDP packets have the following simple structure.

The Client will accept any packet as an answer to its question as long as the packet is coming from the DNS Server, the source & destination ports match the destination & source port of the question packet, and most importantly the Transaction ID and Question match its question. An attacker can spoof such an answer packet as long as he can pretend to be the DNS server and also guess the source port (SP1) and transaction ID (TID1) (the destination port is usually 53). The attacker also needs to make sure his spoofed answer packet reaches the Client before the actual answer packet from the legitimate DNS Server. The image below depicts a very simple attack scenario.

2. Additional Resource Records:  When a DNS server replies to a question, it can also include additional information in the answer to make future process efficient. A typical answer to a question such as “What is the IP for www.bob.com?” from Client DNS server to bob.com DNS server may look like the following image.

So the next time when Client DNS server needs to know the IP for another of bob.com domain, such as mail.bob.com, it will send a question directly to either the DNS server at 1.1.1.254 or 1.1.1.244.

Combining above two issues is what makes it more interesting. If an attacker is successful in predicting the source port and transaction ID (as in Issue 1 described above), and also inserts the additional information into the spoofed answer packet with the DNS servers pointing to the IP of his evil DNS server (as in Issue 2 described above), he can control the traffic directed for bob.com domain. Below is an image showing such a spoofed answer packet. 

Although everything looks simple in theory, the two important keys to successful exploitation lie in the process for guessing the source port and the transaction IDs. In reality a large number of attempts are required by an attacker to guess the source port and the transaction ID of a DNS question before an answer from legitimate DNS server is received by the victim. Some of the DNS implementations do not completely randomize the transaction IDs. They may also use the same source port to connect to the same destination DNS server to resolve a series of questions within a short time period.  Such patterns can be identified by an attacker by sending recon probes to the victim name server to lookup for domains controlled by the attacker. This combined with other strategies such as the birthday attack make it possible to guess the source port and transaction ID in a relatively short number of attempts.

It should be noted that both DNS clients and server are vulnerable to these issues although the potential impact of a successful exploitation is greater when a DNS server cache can be poisoned. If you would like to know whether your DNS server is vulnerable you can check out Dan’s DNS CHECKER or follow some of the suggestion on Sans Dairy. McAfee customers with McAfee Network Security Platform (formerly IntruShield) line of products are protected by the following attack signature id 0×40303200 that was released in sigset4.1.30.4 and sigset 3.1.67.3.

In closing, I think these are very serious issues in DNS protocol and not necessarily the only issues that Dan will be presenting at Black Hat. I guess we can wait a few more days to get complete details.