DNS Fool

In response to claims of “foot-dragging” with regards to DNS security, the United States government has ordered the administrators of all .gov domains to implement DNSSEC before January 2009.

DNSSEC is a somewhat controversial set of extensions to the DNS protocol designed to provide protection from forged data.  Although it was first proposed in 1995, DNSSEC has not been widely adopted and as of a few weeks ago only 99 .com domains were using it (here’s a map of worldwide deployments).  Of the many concerns preventing deployment, the two most controversial have been “zone enumeration” and the issue of who controls the master keys.

The matter of key ownership was raised again last year when the U.S. Department of Homeland Security announced that it wanted to manage the root keys.  Operators of many other top level domains took issue with this, and proposed that ICANN/IANA be tasked with root key management.

Update: A PDF of the mandate is available from the Whitehouse website.

A lot has happened in the world of DNS since July 8th.  Of course, that is when Dan Kaminsky revealed his now famous DNS bug and the patching panic began.  Since that time there have been many explanations of the bug, along with much discussion about also how the bug can be exploited and why it is a big deal.  I’ve contributed to this discussion in the form of two articles posted on LinuxJournal.com:

• Understanding Kaminsky’s DNS Bug - An overview of how the bug can be exploited.
• The DNS Bug: Why You Should Care - A look at the importance of this bug to everyone on the Internet.

It isn’t often that the New York Times covers topics like the Domain Name System, but this security issue was enough to warrant two articles on the award winning news site.

It’s been said many times by many people, but it really is amazing that this bug went undiscovered for 25 years.  Once it is explained it just seems so simple.  How could we not have seen it?

But how do we know that someone else didn’t discover this bug long ago?  For all we know, a bad guy may have been exploiting this issue for years, undetected.  This is why it is so important that the Internet community embrace full-disclosure security practices.  Information exists, and it’s better for it to be available to everyone, publicly, than to just the bad guys, privately.

Even if the bug had not been known before, and Dan didn’t accidentally find it, how do we know a bad guy wasn’t on the brink of discovering it?  How would the news media have reacted to the story in that case?

Let’s just be glad Dan Kaminsky is on our side. 

The initial patches provided for better port randomization in BIND caused it to experience performance issues.  Today ISC has provided a second patch for each of the Unix versions of 9.3.5, 9.4.2, and 9.5.0 that addresses the problems introduced in the first patch.  As stated in the release notes, this update provides:

• performance improvement over the P1 releases, namely
  • significantly remedying the port allocation issues
  • allowing TCP queries and zone transfers while issuing as many
    outstanding UDP queries as possible
  • additional security of port randomization at the same level as P1

Additionally, the patch for 9.5.0 includes “fixes for several bugs in the 9.5.0 base code.”

Those using BIND for Windows will need to wait a little longer for the performance fixes as these patches do not fix the issues on that platform.

The updated versions can be downloaded directly from the BIND page on the ISC website.

ISC has issued a statement about the performance issues that many BIND administrators are seeing.

Evidently, the new security updates to BIND are causing problems in high traffic recursive environments (more than 10k queries/sec).  Specifically, the issue exists with BIND 9.5.0-P1.  Their statement recommends that systems affected by this be immediately downgraded to BIND 9.4.2-P1, which does not exhibit the problem.

There is speculation that this is the reason that Apple has delayed providing an update for Mac OS X Server.  It’s been three weeks since the exploit was first announced and Apple has been noticably quiet among the companies publishing security updates.

Well that didn’t take long.

Mere days after the details of the recent DNS attack were made public there is already an exploit out in the wild.  HD Moore and I)ruid have added an exploit to the Metasploit project, a popular penetration testing framework.  These are the good guys, but the bad guys have the same access to the code as everyone else.

It doesn’t seem like anyone outside DNS and networking communities really understand how significant this issue is.  Noted DNS expert Cricket Liu has suggested that this may be the biggest DNS vulnerability in the history of the Internet, and certainly the biggest vulnerability right now.

Also, there’s a good interview with Dan Kaminsky over at Wired where he talks about discovering the vulnerability and reiterates that “this (attack takes) ten seconds to hijack the net”.

Dan provides a “DNS Checker” on his website to see if your DNS is vulnerable.  Please go check.  If you find that you are not safe, OpenDNS is ready for your traffic.  If you are a network administrator, now might be a good time to consider switching to djbdns.

It was just 14 days ago that Dan Kaminsky announced that he had found a critical security flaw in DNS, but that the details would be kept secret until he took the stage at Black Hat on August 6th.  This 29 day gap between the announcement of the discovery and the detailed description of the attacks was to give ISPs and software vendors time to update their systems so that more people on the ‘net would be protected when exploits hit the wild.  Also, it would give Dan’s Black Hat talk a lot of well deserved attention.

That all changed yesterday when Halvar Flake speculated what the attack may be.  He wasn’t sure of it himself, but as it turned out his guess was pretty close.  The Matasano team posted an entry on their blog that gave details of the attack, which quickly spread around the Internet.  Although the post has since been taken down, and the Matasano team has apologized, the text of the post is available all around the Internet.  The cat is out of the bag, so everyone needs to make sure their systems are patched right away.

The attack is interesting indeed, and it is amazing that no one has considered this approach until now.  If you have a few minutes, you may want to read what is available.

Dan Kaminsky has done it again.

Kaminsky found a security vulnerability in the design of DNS itself.  Yea, let that sink in.  The problem was in the DNS protocol, not just certain implementations.  That means BIND is affected (of course), Microsoft DNS is affected, and so on.   A full list of affected systems is available in the CERT advisory.

Something to note is that BIND 8 is not being patched.  If you are running BIND then you should consider upgrading to BIND 9 immediately.

Several systems are not susceptible, including dnscache from djbdns, OpenDNS, and PowerDNS.  Kaminsky comments on how Dan Bernstein was years ahead of everyone else with djbdns:

DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.

There is a fantastic quote that guides a lot of the work I do: Luck is the residue of design. Dan Bernstein is a notably lucky programmer, and that’s no accident. The professor lives and breathes systems engineering in a way that my hackish code aspires to one day experience. DJB got “lucky” here — he ended up defending himself against an attack he almost certainly never encountered.

Here is a PDF of the executive overview of the vulnerability.

This is being called the largest coordinated security update in the history of the Internet, and it probably is.  Kaminsky coordinated the announcement of the security issue with all the major vendors, allowing everyone to have patches available at the same time and prevent chaos across the Internet.

The Internet is lucky to have Dan Kaminsky looking out for us.

Bite my Bytes has collected a list of free DNS reporting utilities.

ICANN and IANA were the victims of a DNS redirection attack this week.

Turkish crackers were able to take over the icann.com, icann.net, iana.com and iana-servers.com and redirect them to a hosting account at atspace.com.

Zone-H is hosting a mirror of the defacement.

Yesterday ICANN moved forward with a proposal to expand the DNS namespace by allowing private entities to stake out new top level domains.  This is probably good news in the long run, but it may be the source of confusion for some in the immediate future.  Is my banking account at citibank.com or www.citi ?

As some have pointed out, this may not be much of an issue because most users today arrive at their destination through a search engine, and rarely enter domains in the address bar.

It will also be interesting to see if the domain squatters are able to mess this up for everyone.