Kaminsky DNS flaw: the trick that could hijack any domain

On July 8, 2008, makers of DNS software around the world published fixes on the same day for a flaw that the security researcher Dan Kaminsky had found. The DNS, the Domain Name System, is the internet’s address book: it translates names such as example.com into the numeric addresses that computers use to reach each other. The flaw let attackers plant false addresses for any domain in the memory of the servers that look up these names for users. According to CERT.at, Austria’s national computer emergency team, almost all DNS servers on the internet were vulnerable.

How it worked

When you open a website, your device asks a resolver for the address. A resolver is a DNS server that looks up names on behalf of users, usually run by your internet provider or your company. It asks the name servers responsible for the domain and keeps their answer for a while in its cache, a temporary memory, so that it can answer the next user at once. Whoever gets a forged answer into this cache sends every user of the resolver to the wrong server. This is called cache poisoning.

A resolver accepted an answer if it matched its question, above all through a query ID, a number between 0 and 65,535. Most resolvers sent all their questions from the same network port, so this number was the only secret an attacker had to guess: each forged answer had a chance of 1 in 65,536. Poisoning was still hard, because the real answer usually arrived within about 100 milliseconds. Once it was in the cache, the attacker had to wait until it expired, often for days.

Kaminsky’s idea removed the waiting. The attacker makes the resolver look up names that do not exist, such as random1.example.com, then random2.example.com, and so on. Such names are never in the cache, so each one is a new chance. The forged answers carry an extra entry which claims that a server of the attacker is now the name server for all of example.com. As soon as one guess fits, the resolver stores this claim and from then on asks the attacker about every name in the domain. According to a study presented in 2009 at NDSS, a conference for security research, the technique cut the time an attack took from weeks to seconds.

The US-CERT, the US government’s computer emergency team, warned that web traffic, email and other important network data could be redirected to systems under the attacker’s control.

Reach and attacks

The weakness lay in the DNS protocol itself and not in a single product, as ISC, the maker of the widely used DNS software BIND, wrote. The CERT/CC, the US coordination center for security flaws, listed 91 vendors, 37 of them affected, from Microsoft and Cisco to Linux distributions.

CERT.at, which is run by the registry of Austria’s .at domains, measured how fast Austrian resolvers were fixed. A patched resolver changes its port with every query, and CERT.at could see this in the logs of one of the registry’s name servers. Before the fixes, only about 15 % of the resolvers did so. Two weeks after the fixes, 66 % of the busy resolvers, those seen on almost every day, were still unpatched:

Studies of resolvers worldwide came to different results. Months after the fixes, researchers at the Georgia Institute of Technology probed 0.9 million open resolvers, which answer queries from anyone: about 57 % still sent every query from the same port. A survey by The Measurement Factory, commissioned by the DNS vendor Infoblox, estimated 4.3 million open resolvers in October 2008 and found poor port randomization in 24 % of those it tested.

The details of the attack were to stay secret until a talk at the Black Hat security conference in early August. But on July 21, they leaked, and on July 23, working attack code appeared, according to DNS-OARC, an association of DNS operators. A week later, the press reported that a DNS server of the provider AT&T in Texas had been poisoned, so that its users who called up google.com landed on a fake page that clicked on ads; the SANS Internet Storm Center also reported the poisoned server. The researchers from Georgia found poisoned answers for the domains of banks and large websites in the first two weeks of August 2008, 11,050 for the US bank Washington Mutual alone. The number rose after the attack tools came out, but the researchers could not prove which technique had been used. No source puts a figure on the damage.

The fix and the response

Kaminsky had warned the vendors months before: on March 31, 2008, makers of DNS software met at Microsoft to discuss the problem. Their common fix is called source port randomization. A patched resolver sends each query from a randomly chosen port and accepts only answers that arrive at exactly that port. According to CERT.at, this adds up to 16 more bits of randomness that an attacker has to guess. After Microsoft’s update, for example, Windows DNS servers picked their ports from 16,384 possible ones; together with the query ID, that makes about a billion combinations instead of 65,536. The idea was not new: CERT/CC credits it to the developer of djbdns, a resolver that already chose random ports.

CERT/CC arranged for almost all vendors to publish their fixes on the same day, July 8, 2008, among them Microsoft with update MS08-037 and ISC with new versions of BIND. CERT.at called this coordination almost unprecedented. Apple followed on July 31 with an update for the BIND server built into Mac OS X. CERT/CC also warned that routers and firewalls which translate addresses and ports could undo the protection.

Random ports only raise the bar. Without changes to the protocol such as DNSSEC, the DNS Security Extensions, which let resolvers check digital signatures on answers, the fixes “cannot completely prevent cache poisoning”, CERT/CC wrote. ISC called DNSSEC “the only definitive solution”. In October 2008, the US Department of Commerce asked for comments on signing the root zone, the top of the DNS, with DNSSEC and cited this flaw. Since July 15, 2010, resolvers have been able to check the signed root zone.

The National Vulnerability Database rates the flaw 6.8 out of 10 on CVSS 3.1, “medium”: an attacker can falsify answers but cannot read data or shut down a server, and the attack counts as hard to carry out.