A summary about the DNS vulnerability

From juliano.info

Jump to: navigation, search

This is a summary of events around the recently discovered Domain Name System vulnerability. In short, one of the core Internet protocols have a serious design flaw. This flaw compromises the whole domain name system, the privacy and the security of all Internet users. There is no real solution ready to deploy today, but patches to mitigate the problem were released. It is important to check your system and take immediate action if you find that you are vulnerable.

Keep reading for more information.

Contents

Introduction

The Domain Name System, also known as DNS, is an hierarchical distributed database and of domain names and IP addresses, it is one of the core protocols of the Internet. It acts as sort of a phone catalog, where you ask for a name (like google.com), and it returns the number that your computer have to "dial" (like 64.233.167.99) in order to contact the right destination. In fact, it is a little more complex than this, but this ought to be enough for people unfamiliar with Internet protocols to understand the importance of the DNS.

It was created shortly after the deployment of TCP/IP, when ARPAnet became what we know today as the Internet. That was twenty-five years ago, and just like most of the technology from that time, it struggled with a few issues regarding scalability and security demanded by the underestimated growth of the Internet.

Although DNS was designed to be scale well, the security concerns were very different 25 years ago. As with many legacy systems that manage to survive this long, it is not technically feasible anymore to replace DNS with anything different, without breaking half of the Internet apart. It is perfectly comparable with other technologies with major scalability and security issues, like IPv4 and SMTP. Many new technologies were invented in order to patch or mitigate these issues, like NAT for IPv4 and SPF for SMTP. But these technologies are, in most cases, either difficult to deploy or bring shining new problems themselves. The preferable solution, when feasible, is to switch over to a new technology on par with today's standards. This is an inherently difficult task, even if all necessary measures are planned beforehand, like we are observing today with the (much slower than expected) acceptance and deployment of the next generation of the Internet protocol (IPv6).

The DNS also had its own share of security vulnerabilities, that were discovered and patched in the past. Most of these vulnerabilities involve DNS cache poisoning, where your domain name resolver is induced into believing that a different domain name server (owned by the attacker) has authority over a given domain name. Since domain names are hierarchical, depending on the level targeted by the attack, this may result in some very scary scenarios, where huge branches of the domain name tree (think, for example, all domains below ".com") are delegated to the attacker servers. This means that your resolver will be asking the wrong person about what number to "dial" when you connect to a site.

Some technologies to mitigate the weaknesses of the Domain Name System were designed, namely, the DNS security extensions (DNSSEC). DNSSEC improves the security of the DNS by using cryptographic authentication. Unfortunately, the big infrastructure changes required by DNSSEC and some other few but significant unresolved issues hinder its deployment.

The Domain Name System, as of today, is extremely insecure. This was evidenced with the recent discovery by Dan Kaminsky of a very simple and easy way to poison the cache of any domain name resolver. Coordinated patches to mitigate the problem were released by major providers of DNS software, but the issue is still of great concern.

Sequence of events

On July 8th, 2008, multiple DNS software vendors coordinately released patches to mitigate an alleged cache poisoning attack. Public disclosure of the vulnerability (without details) followed the release of the patches.

Vendor notices and patches:

Security advisories:

News coverage:

The patches consist of randomizing UDP source ports of all queries performed by domain name resolvers. They don't actually fix the issue, they only make it harder for attackers to inject forged responses to domain name resolvers. Note that DJBDNS doesn't need a patch, since it already did source port randomization since the beginning.

Since no full disclosure was immediately made available (in order to give time for network administrators to patch their systems), everyone started speculating about the vulnerability.

On July 14th, Paul Vixie, author of many Internet RFCs, author of the BIND domain name server software and founder of the Internet Software Consortium, responded to the skeptics about the DNS vulnerability, and reinforced about the importance to patch your systems as soon as possible.

On July 21st, after a lot of speculation from many security experts, some events lead to the confirmation and disclosure of the details of the vulnerability on the Matasano blog. The information was pulled from the site two hours later, but not without being spread to many other sites.

On July 23rd, the exploit code for the vulnerability was made public. Fifteen days after the patches that mitigate the problem were released.

Test your system

You can check your system online through Kaminsky's blog. Click on the button "Check My DNS" on the right column, and you should see an analysis of the security of your domain name resolver.

The DNS-OARC also published a web-based test to determine if your domain name resolver does a good source port randomization, and thus more secure against DNS cache poisoning. Go to the DNS-OARC: Web-based DNS Randomness Test and click the big "Test My DNS" link. It tests both your source port and your transaction ID randomness. If you get a "POOR" result on either test, then you have a serious problem.

You may also test from remote servers by issuing a DNS TXT query for the address porttest.dns-oarc.net. The result of this query says whether your source port randomization is good or not: DNS-OARC: Check your resolver's source port behavior.

If you get any "POOR" results from the above tests, you must take action immediately.

Taking action

If you are a home Internet user, the first thing you have to do is to call your Internet service provider and request that they patch their domain name resolvers. In the meantime, you should consider changing your DNS server addresses to point to OpenDNS or any other provider of domain name resolution services that have already addressed the issue. Advanced users may also want to run their own domain name resolver. If you decide to run your own local domain name resolver, be warned that some home routers translate source ports in a predictable way, meaning that you end up again with the same problem.

If you are a network administrator, patch all your servers, now! If you run unpatched domain name resolvers, you have the privacy and security of all your users at risk. The attack is very easy and with a damage potential that is really scary. If you can't visualize the relevance of this situation, then you have two problems.

Also remember that the real problem is not fixed yet. Big changes to the Internet infrastructure are required in order to have a safer DNS. If you are a network administrator and manage domain name servers, research about DNSSEC. Check if your TLD or ccSLD supports it.

Note that Brazil is one of the early-adopters of the DNSSEC, and most Brazilian ccSLD's (except for ".com.br" and ".org.br") support DNSSEC.

Views