How OpenDNS, PowerDNS and MaraDNS remained unaffected by the DNS cache poisoning vulnerability

How OpenDNS, PowerDNS and MaraDNS remained unaffected by the DNS cache poisoning vulnerability

Summary: The short answer is being paranoid about tackling a known vulnerability. It's 2001, and Daniel J.

SHARE:
TOPICS: Security
8

The short answer is being paranoid about tackling a known vulnerability. It's 2001, and Daniel J. Bernstein (DJB),Daniel J. Bernstein (DJB) author of the then popular djbdns security-aware DNS implementation, is applying basic math principles to raise awareness on what's to turn into the "sky is falling" critical Internet vulnerability in 2008, in an email on the unix.bind-users newsgroup :

"I said "cryptographic randomization.'' The output of random()  is not cryptographically secure. In fact, it is quite easily predictable. This is a standard exercise in first-semester cryptography courses. Randomizing the port number makes a huge difference in the cost of a forgery for blind attackers---i.e., most attackers on the Internet. It's funny that the BIND company has gone to so much effort to move from the first line to the second, but now pooh-poohs the third line. Do you think that "RSA'' is a magic word that makes security problems disappear? Without a central key distribution system---a system that doesn't exist now and won't exist for the foreseeable future---DNSSEC doesn't stop forgeries."

The skeleton from the closet makes another appearance in January 2005, according to Marcus H. Sachs, Director, SANS Internet Storm Center, in the face of Ian Green's GIAC Security Essentials Certification (GSEC) submitted paper detailing the same vulnerability :

"Three years ago Ian Green, then studying for his GIAC Security Essentials Certification (GSEC), submitted a paper that details the same DNS spoofing vulnerability, the SANS Institute's Internet Storm Centre notes.In order to spoof a DNS request it's necessary to "guess" both the Query ID and the source port. The query ID is 16 bits long, and the UDP source port also has over 60,000 potential option. But as Green noted back in January 2005, DNS transactions are incremented by one for each subsequent query while the UDP source port remains the same during a session."

Apparently, OpenDNS, PowerDNS and MaraDNS were all aware of the possibility for abuse here, and took action long before the recent vulnerability disclosure and coordinated multi-vendor patching initiated by Dan Kaminsky took place. How did they do it, and what's the current state of the coordinated patching campaign across the Internet?

On July 8th, David Ulevitch at OpenDNS posted a statement that OpenDNS isn't vulnerable :

"I’m very proud to announce that we are one of the only DNS vendor / service providers that was not vulnerable when this issue was first discovered by Dan. During Dan’s testing he confirmed (and we later confirmed) that our DNS implementation is not susceptible to the attack that was discovered. In other words, if you used OpenDNS then you were already protected long before this attack was even discovered.

In fact, for those of you who were listening in on the Microsoft press call this morning, you’ll note that OpenDNS was suggested as the easy and simple solution for anyone who can’t upgrade their DNS infrastructure today. Pointing your DNS servers to forward requests to OpenDNS and firewalling all other DNS traffic off at your server will help mitigate this risk." Bert Hubert, author of PowerDNS, alerted me to the fact that PowerDNS was also not vulnerable when this issue was discovered. That’s not surprising considering Bert is one of the authors of the wonderful DNS forgery resilience Internet Draft that has recently been published. :-) I updated the statement in bold appropriately."

On July 9th, Sam Trenholme at MaraDNS pointed out that the service is too, immune to the new cache poisoning attack :

"MaraDNS is immune to the new cache poisoning attack.  MaraDNS has always been immune to this attack.  Ditto with Deadwood (indeed, people can use MaraDNS or Deadwood on the loopback interface to protect their machines from this attack). OK, basically, this is an old problem DJB wrote about well over seven years ago.  The solution is to randomize both the query ID and the source port; MaraDNS/Deadwood do this (and have been doing this since around the time of their first public releases that could resolve DNS queries) using a cryptographically strong random number generator (MaraDNS uses an AES variant; Deadwood uses the 32-bit version of Radio Gatun)."

And while these DNS services and secure DNS implementations like MaraDNS in this case, weren't susceptible to the DNSDNS Fix Causes Huge Surge in DNS traffic in the Internet cache poisoning, during that time, across the Internet a synchronized patching was causing a lot of DNS anomalies, the direct effect of the ongoing patching in progress. According to Narus's Supranamaya Ranjan, they saw a 1000x increase in aggregate volume of anomalous DNS traffic between Julu 7th and 11th :

"Look at the figure below, which shows the aggregate volume (in Mbits/hour) over time for the DNS anomalies seen between July 7th and 11th. Clearly, before the CERT announcement and release of the patches, there were no anomalies. But after the announcement on July 8th, NSS saw a 1000x increase in aggregate volume of anomalous DNS traffic. NSS defines a traffic event as an anomaly if the amount or behavior of traffic heading to an ip-address exhibits sudden changes. A further analysis of the sources of these queries shows that they were being originated from open DNS proxies on the Internet and from DNS clients from well-reputed institutions from around the world. The reputation of the anomaly sources leads to the conclusion that these anomalies were not really attacks, but a side-effect of the synchronized patching."

The most recent study on the state of patching vulnerable DNS servers, was released today courtesy of Austria's CERT, stating that :

"The conclusions are rather grim so far – more than two thirds of the Austrian Internet's recursive DNS servers are unpatched while at the same time the upgrade adoption rate seems rather slow. Our findings are matched by the observations of Alexander Klink of Cynops GmbH who analyzed the results of the online vulnerability test on Dan Kaminsky's doxpara site."

The big picture? It seems that it's not just At&T's DNS servers which are susceptible to DNS cache poisoning, but many other like the following according to a request for self-auditing initiated by the Register :

"Skybroadband, Carphone Warehouse Broadband, Opal Telecom, T-Mobile, Videotron Telecom, Roadrunner, Orange, Enventis Telecom, Earthlink, Griffin Internet and Jazztel."

Publicly available exploits for remote DNS cache poisoning

With three publicly available exploits for remote DNS cache poisoning released during the last three days "in the wild", it remains yet to be seen whether or not malicious attackers would take advantage of the window of opportunity, or continue using the "cybercrime as usual" attack tactics.

Topic: Security

Dancho Danchev

About Dancho Danchev

Dancho Danchev is an independent security consultant and cyber threats analyst, with extensive experience in open source intelligence gathering, malware and cybercrime incident response.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

8 comments
Log in or register to join the discussion
  • OpenDNS is great

    I have been using OpenDNS for over 5 months now on the company network and it does a great job for us. I would recommend everyone use this tool as it has increased our DNS reliability and performance while blocking websites that I do not want on the network and it doesn't cost a thing. Just thought I would let everyone know about my experience with it and glad to see it is safe.
    OhTheHumanity
  • RE: How OpenDNS, PowerDNS and MaraDNS remained unaffected by the DNS cache poisoning vulnerability

    Using DN$ vs. OpenDNS, is what's got IT all in a BIND...Opun intended ;-)
    pundamentalist
  • OpenDNS is the ticket

    I've been using OpenDNS for several years--not because they are safe but how they cache. You can expect if you use their DNS 208.67.222.222 and 208.67.220.220 as your primary and secondary, you'll speed up your DNS queries significantly.
    D T Schmitz
  • I Ran The Test Against RR In My Area...

    And it is good to go.
    I was very glad to see that but if their upstream DNS servers aren't secure then I guess I'm still nailed.
    dunn@...
  • Went to doxpara website...

    tested my W2k and SuSE 10.2 servers. Failed the test. Went through both OS's automatic update utility, went back to doxpara and passed.

    If the fix is out there for MS's DNS and BIND, there is no reason why anyone should still be vulnerable.
    bjbrock
  • Run DJBDNS

    I inherited djbdns on the systems we have here and never left it since.
    Being a former BIND user in my previous job it took some getting use to but once it is running is I don't have problems with it.
    phatkat
  • RE: How OpenDNS, PowerDNS and MaraDNS remained unaffected by the DNS cache poisoning vulnerability

    "author of the then popular djbdns " - huh? djbdns is far more widely deployed than opendns, powerdns, maradns, etc - it's second only to Buggy Internet Name Domain for open-source distributions.

    come on, credit where credit is due. if it weren't for djbdns, it's unlikely these johnny-come-lately's would have been immune - they'd have probably made the same design mistakes BIND has made (over and over and over and over and over) if not for djb's hectoring about these issues.
    anastrophe
  • DNS Problems

    We have a solution for dns problems
    http://www.fairlinked.de
    fairlinked