DNS Vulnerability; The Other Part of that Partial Disclosure

By: Danny McPherson -

Just under two weeks ago, on July 8, a vulnerability disclosure was released warning of multiple DNS implementations being susceptible to yet another new DNS cache poisoning attack, but one professed to be far worse than previous attacks. Dan Kaminsky, in cooperation of with a large number of well-respected security and DNS experts, and a convincingly long list of organizations in tow, attempted to make a compelling argument to the community regarding the severity of the vulnerability that had been discovered and the immediacy with which upgrades and patch deployments were required.

You might be asking yourself, if this is such a severe vulnerability, then why is there a need to make a convincing argument for folks to patch their systems? Well, the vulnerability disclosure was only a partial disclosure. That is, it included plenty of details about badness that might happen and the urgency with which folks should upgrade, but it did NOT include the details of the actual problem, those were only made available to a select subset of folks, mostly those that had code to patch and testing to perform before making patched versions of their software available for distribution in conjunction with the partial disclosure.

The reasoning for this partial disclosure, and one of the great coups professed as a result of the handling of the pre-disclosure by the folks involved, was that it was an industry first on the multi-vendor and CERT vulnerability disclosure and coordination front. In reality, I think a great deal of similar coordination occurred with the SNMP PROTOS attacks in 2002, as well as the TCP Slipping in the Window attacks in 2004, as well as couple others. However, I certainly wouldn’t want to detract from the excellent job Dan, Paul Vixie, and all the other folks involved on the back end did in order to corral a core set of critical stakeholders and agree on interim “work arounds”. Now that ALL the goods have been spilled, albeit prematurely, I understand their caution and sense of urgency.

However, to take a bit of a different angle for a moment, let’s have a look at this from an outsider’s perspective:

  • Dan finds the vulnerability, talks to a few folks, and all agree it’s very ugly
  • A core set of pre-disclosure stakeholders are engaged by Dan and team
  • A workaround, source port randomization, is determined to be the only viable workaround absent DNSSEC
  • All the involved vendors build and test patches
  • A partial disclosure is made via the CERT Vulnerability Note and an accompanying slew of vendor disclosures, and an impressive multimedia PR machine is put to work, touting the badness and reminding folks that all the goods will be released at Black Hat in August

Now, here’s where a big part of the problem arises. The Vulnerability Note was only a partial disclosure, and basically, folks were told:

  • There’s a big problem, and it’s well beyond what’s been disclosed in previous cache poisoning vulnerabilities
  • No, we’re not going to tell you what the actual issue is
  • Upgrade to code that makes source ports less predictable, and it will make the attack more difficult to launch successfully
  • No, we’re not going to tell you what the actual issue is, but it’s inherent to DNS and multi-vendor, the patch makes it more difficult to launch successfully, but is NOT a complete fix, but upgrade
  • Only DNSSEC will completely protect against this, but you need to upgrade anyway to the patch – now!
  • Reverse engineers are encouraged to have a gander, speculation is good
  • No, we’re not going to tell you what it is, BUT Dan will share all the bits at Black Hat in August – be there!
  • Hackers gang up on Kaminsky, as he requests NO speculation, which is indeed commendable, but certainly considered unreasonable to many folks
  • Kaminsky stays the course – upgrade – now!, get the goods at Black Hat

So, there’s lots of speculation, and folks don’t know if they should upgrade, and don’t know what all the details are, and so there’s more speculation, and even some very detailed speculation, as below, and Dan asks folks to hold-off on it.. So, naturally:

This highlights the problem with partial disclosure, especially when pre-disclosure has already occurred. Many folks rightly question the severity and the need to upgrade. Many speculate and reverse engineer and try to figure it out. Leaks occur, in particular when there’s as much media activity around this as we’ve seen, with a grand climax scheduled for a conference such as Black Hat. I’m sympathetic to the folks at Matasano, as this really could have happened to anyone – be assured we at Arbor have certainly learned something about pre-drafting and post availability.

As for the actual vulnerability – it’s real, and it’s ugly, and the concern by Dan and the folks he engaged was well-founded. If you’ve made it this far and not been distracted already by the links above, then here’s the summary in a nutshell:

  • Cache poisoning has been an issue for ever. I want to poison a DNS cache I send it a query to a resolver, and then spoof lots and lots of response packets with the answer. The resolver caches the corrupt query, and everyone from that point forward uses the corrupt address rather than the legit one
  • “Lots and lots” of packets can become just “lots” of packets with “Birthday Attacks“, and lots is not actually that many.
  • So, if I can guess DNS query source port, and DNS transaction ID, and employ birthday attacks, then it’s all pretty easy to corrupt a cache.
  • However, if I can further corrupt a cache, say when I query for a host that doesn’t exist, and include some additional information in the spoofed packet thats says “BTW: because you’re asking about unknownhost.example.com, let me go ahead and tell you as well about the address for the authoritative name server for example.com, via some Additional Resource Records (RRs) that DNS allows me to piggyback in the response.”, then I can be considerably more effective with this attack

So, how do you use this? Say you corrupt the cache on the DNS resolvers in the top 50 global broadband networks with NS records for the largest 100 financial institutions globally, and then field those queries and redirect them to your phish network. Or you decide you’d like to add your own MX records to those resolvers, or enterprise or government resolvers, for a bunch of .gov domains. I’m certain we’ll see even some clever uses for this attack in the near future.

One of the ugly things with DNS cache poisoning attacks is that they’re fragmented, can be targeted and localized, and occur entirely unbeknownest to the legit domain owner. Also, because resolvers have to query root servers, and then the authoritative resolvers for a domain, there really is no stopping these attacks by disabling recursion. They can also effect end-hosts, not just resolvers, and there are clever things you can do to trigger an end host to send a DNS resolution query. The attacker can spoof the authoritative server (or other query path devices) IP address and inject the corrupt response from pretty much anywhere on the Internet. If source port randomization is employed the difficulty in this is raised considerably, and that’s the patch that’s being made available in the absence of DNSSEC.

I would argue that if host couldn’t spoof source addresses on the Internet, then this would be a non-issue (although DNSSEC provides the application layer protection needed against other attacks). Ubiquitous deployment of source address verification and anti-spoofing measures such as BCP 38/RFC 2827 and the IETF’s Source Address Verification work that’s now underway, would help squash these and many other types of attacks that rely on IP address spoofing. However, according to our Infrastructure Security Report source address spoofing is deployed in only about 50 percent of the networks today, a number dismal and disappointing at best.

Their attempt to do the right thing here certainly has protected many folks, and if you haven’t already patched, as Dan says – “patch, now!”, and deploy anti-spoofing mechanisms in the networks you manage, and encourage your ISPs and peers to do the same .. and give DNSSEC a look..

Comments

  1. Average User 07/23/2008, 12:04 am

    If a cautious end user avoids using DNS for critical sites by going to http:\\[ip address of Big Bank Inc] rather than http://www.BigBankInc.com, then said user has no worries, correct?

  2. For some reason my commentary on doxpara.com and matasano.com blogs including twitter for Security Twits has largely gone unnoticed. Kudos for bringing up RFC2827 again as things like spoof protection, uRPF, FW-extensions, tracking UDP-state, HIPS looking at floods from single SRC IP would all help to address attacks on ISPs and Enterprises. Essentially one must spoof the authoratative NS SRC IP for this to work.

    Sure you have to initiate the lookup via iframes/image tags/SPAM or compromised hosts to start the race in the first place, but with some form of ‘state’ and good filtering this shouldn’t be such an issue. Network configs can buy time to addess patching…. TIME is still the issue, both the start time and the response time…

    Maybe I am missing something. Maybe not.

  3. Danny,

    I’ve seen several people making the argument similar to your point: “Reverse engineers are encouraged to have a gander, speculation is good”, which doesn’t mesh with what Dan actually communicated with the public. What Dan explicitly encouraged was further investigation and scrutiny of DNS (which is a good thing). What he explicitly discouraged was public speculation of the vulnerability (which of course is an arguable point). There was certainly no higher authority enforcing Dan’s requests, so it was up to the opinion of each and every researcher to judge his requests and guide their own actions. But saying that Dan encouraged speculation is inaccurate.

    Also, the attack doesn’t rely on the birthday paradox. In fact, it’s even more simple. If you can play a game with a low probability of winning a large number of times, you can achieve a high probability of eventually winning one of the games. Since we can request an “unlimited” number of non-existent RRs, each with a low probability X/(2^16) of succeeding (where X is the number of TXIDs we’re able to successfully beat the authoritative server with in the race), we will eventually win the game and poison the cache by slipping in the malicious glue NS RR.

    Regards,
    Jon Oberheide