The Critical DNS Vulnerability

Unless you've been sheltered for the last month, you are by now well aware of the important news about the critical DNS vulnerability. You have patched or otherwise protected your networks, right?

One thing that was immediately apparent about this vulnerability was the unique way that it was disclosed simultaneously by a number of vendors and their claim that the patch itself did not disclose the vulnerability (that alone may be a topic for future discussion). The fact that so many vendors were able to collaborate in secret on this vulnerability for more than 6 months before the patch was released was a clear sign to me of the importance of the discovery. It frankly surprises me that many were so skeptical at first that something "new" was found. In part I think their skepticism and unfounded early criticism of Dan was an attempt to try to lure the details out prior to the 30-day quiet period Dan had hoped for to enable patch deployment and other protections necessary as a result of this attack.

I took a different point of view. Instead of being skeptical, I actually chose to make my own attempts at deciphering the core problem that the patch was an attempt to remediate. I think I was fascinated by the fact that they released a patch with full confidence that reverse engineering the patch alone would not give insight into the real problem they had protected against. I don't think I even bothered diff'ing the patches at first because I knew what I was going to find was exactly what was said -- merely fixes to enable source port randomization.

To be honest, it didn't take me long to start deciphering the code. As I mentioned before, I've been around a few years, and I actually recall the turmoil back in 1993 and 1997 when CA-1997-22 came out (SecureWorks has a good Back History on this.). Back then it was a simple matter of predicting the next transaction ID and beating the real server to the answer. So in looking at this issue, I had that bit of understanding to go on, and below is a recount of my few days (about one and a half days on and off really) of investigation that resulted in my findings of what I believed was the crux of the issue. In the end, I found something that allowed me to spoof any domain I wanted, up to and including the root servers.

Now I'm not going to say I found the exact issue, right away, it did take a bit of investigation and review of DNS as I had not looked at this in a few years. Initially I was looking at this solely from the point of view what response would I have to successfully send to gain ownership of a domain at the level I believed that this issue clearly was. I knew that the responses had to follow the in-baliwick rules, and if you could successfully spoof one of these responses you could use the glue records to overwrite whatever you chose, including the existing A records for the name servers handling the domain. Immediately I realized how big this was, if I could overwrite the name server records in this way, I could take over .com, .net, or even the proverbial root domain, yes '.' itself. That's how DNS works afterall.

Now, as I mentioned, initially I was looking at what I'd had to spoof, and I did proof of concept spoofs by utilizing packet inspection. Obviously this was an easier attack method (if you control the network path you really don't need to spoof anyways), but I figured if I could do it that way, the remote spoof of blasting various txid's was just a coding exercise. Once I made this realization I then started looking at the birthday attacks from previous research. After getting caught up on this aspect of DNS exploitation, I started looking at crafting my own proof of concept exploit tools.

After getting past the above More awareness of the Birthday attacks made it clear to me what the attack was. The birthday attack previously was an effort to increase the chance of collision by causing a number of races at the same time with differing txids, increasing the odds for collision. But it was always done with the same query. What if you started a number of attacks at the same time against different queries? No longer would you have to worry about winning one race, you'd have the ability to start as many races as you liked. With that I began my attempts at the blind spoofing attacks by using the random in-baliwick name lookup method. Amazingly, I got this exploit to work within a few hours of coding (spoofing DNS packets is not something I ever felt the need to do before).

Now, mind you, I started working on this in my spare time Thursday and Friday after the initial announcement. I had working exploit code by the end of the week, and I couldn't imagine I was the only one to do this. In hindsight, Dan has made it clear that other researchers were able to figure this out as well.

Now, one would argue that if the good guys were able to do this so quickly, the bad guys were as well. I certainly won't disagree with that. But based on the information that has been released publicly, it is not clear if anyone actually exploited this publicly in a large way prior to the metasploit modules being released. Since they have been released, we've obviously seen some people uptake that code, or at least the concept to leverage for their own means.

I would like to say that I am glad that there are more responsible people out there who realized the scale of impact of this issue and chose to keep the information to themselves for as long as was possible. In the end, more people have patched, and we are better protected from this issue than had it been fully disclosed without this "gift of time."