The Great DNS Vulnerability of 2008 by Dan Kaminsky
The Internet was never designed to be secure. The Internet was designed to move pictures of cats.
In 2008, Security Researcher Dan Kaminsky presented on the massively widespread and critical Domain Name System (DNS) vulnerability that allowed attackers to send users to malicious sites and hijack email at Black Hat, the information security conference. The exploit would allow attackers to impersonate any legitimate website and steal data.
This fundamental design flaw allowed for arbitrary DNS cache poisoning - affecting nearly every DNS server on the planet, including vendors and products that worked with DNS. To explain what that is - here’s some background on DNS:
A nameserver is the server software that answers DNS questions such as “What is the IP address for www.google.com?”
It may know the answer directly, if it’s authoritative for the zone - a collection of hostnames/IP pairs managed together. If not, it may have to ask around the Internet to find the answer (a recursive nameserver), according to Steve Friedl’s An Illustrated Guide to the Kaminsky DNS Vulnerability.
If a nameserver doesn’t have the contents of a zone but can find its owner, it’ll delegate that zone to another nameserver - basically, telling you to go ask this hostname for details on the zone you’re asking about.
Nothing actually prevents any nameserver from hosting any zone, including those it doesn’t really own. That means a bad guy could set up a nameserver and configure an authoritative zone for whatever site they wanted, but it doesn’t matter because no other nameserver ever delegates to it.
Local cache in recursive nameservers is used to build a faster Content Delivery Network (CDN) and improve local performance. This means that once an authoritative answer for a name is determined, it’s saved to local cache and can be used to fulfill any future queries directly.
DNS Cache Poisoning
This is when a malicious hacker manages to inject bad data into a recursive nameserver’s cache, which spreads that data to local clients. While the hostnames are genuine, they’re routing users to bad servers.
A cache poisoning attack redirects a user that brings up www.google.com to a malicious site instead, allowing an attacker to install malware or steal data from the user.
The DNS flaw Dan found would allow an attacker to launch cache poisoning attacks against nameservers.
The DNS Flaw Itself
While caching allows for a faster Internet experience/CDN, it can also be leveraged in this DNS attack. If a user sends a request to visit www.google.com, they get a reply in the form of a 16-bit transaction identifier (TXID).
As Dan explains in the video, that’s similar to playing a lottery where your odds of winning are 1 out of 65k (number of hosts). But, due to caching, you can only play the lotto once a day, because the cache time is set to one day.
Winning that lottery will take 87 years, which is enough time for a decent amount of security.
But that rule doesn’t apply to looking up unique entries/sibling names to www.google.com - like 1.google.com, and 2.google.com. Attackers can do this and say they’re the official server for www.google.com, telling the nameserver what www. needs to be, and the nameserver will believe the attacker.
It makes the Internet faster when it comes to delivering content, but it also makes it faster to override just about everything - reducing the 87 year delay to about 10 seconds to exploit. That means your DNS servers can be take over in ten seconds.
The Aftermath
It took two days to figure out that this exploit worked on every nameserver on the planet - except for one written by Professor djb (Daniel J. Bernstein) who told them to not make this mistake in 1999, but no one listened, according to Dan.
Dan called Paul Vixie, creator of several DNS protocol extensions and applications used throughout the Internet today to tell him about the bug he found.
Then, they called an emergency summit to Microsoft’s headquarters to discuss how to address the wide-spread problem, bringing in Paul’s contacts and vendor representatives. This coalition worked to create a fix for the vulnerability before it was disclosed to the public, with vendors simultaneously releasing patches for their products on July 8, 2008.
But, according to Dan, they didn’t actually repair DNS, they just took a 16-bit transaction identifier and used UDP source ports as a hack to get a 32-bit transaction identifier. Now, an attack that used to take 10 seconds now takes hours or days or weeks. While not completely eliminating the attack, they were eliminating the instantaneous attack.
Watch Duo’s animated video retelling of the story, in Dan Kaminsky’s own words.