Mind the gap

When Dan Kaminsky discovered a gaping hole in Internet security in the form of DNS cache poisoning, vendors rushed to plug it. So, what was all the fuss about and is there still cause for alarm?

One of the most important security issues in the history of the Internet broke recently. I'm of course alluding to the DNS cache poisoning issue discovered by Dan Kaminsky earlier this year, and reported in July. Supposedly, on discovering the flaw, Kaminsky called his girlfriend and told her "I broke the Internet". Of course, in reality, all that has happened since then has been a minor media stir, a flurry of patches to various systems, and a great deal of confusion as to the exact nature of the problem and how serious it was, or is. Was this really a major crisis? Is it still today? Now that the dust has settled, I'll look at this issue in some detail.

Question and answer
DNS is the mechanism used to provide information about domains, including domain name to IP address mappings. DNS is in effect a distributed database, with individual DNS servers spread around the globe providing information about their own domains. Each time a client needs to resolve a fully qualified domain name (FQDN) to an IP address, the client asks its local DNS server if it knows the answer. The local DNS server may be inside a corporate domain or it may belong to an ISP. The DNS server knows directly about domains for which it is responsible, so for example your corporate DNS server will typically know directly about your own corporate domain. However, many times the local DNS server will not have the information itself and will need to ask other DNS servers to help it provide the answer.

A series of question and answer messages between DNS servers provides information about the domain. Let's say you type www.slaterinseattle.com into your web browser. This corresponds to a server called www in the slaterinseattle.com domain. The local DNS server doesn't know the IP address that corresponds to that named server, so it asks one of the 13 root DNS servers if they know how to find the address.
 
Those servers don't know anything directly about the slaterinseattle.com domain either, but they do know about name servers responsible for the .com domain. So the answer from a root DNS server provides the names and IP addresses of those .com name servers. Now that your local DNS server is a bit closer, it can ask one of the .com DNS servers the same question. The .com DNS server again doesn't know the specific IP address your local DNS server is looking for, but this time it does know the DNS server that contains information about the slaterinseattle.com domain. It responds with that data. Now your local DNS server is really close to the answer, so it sends the same question one more time to the DNS server it just learned about, and gets the response it requires.

At first sight this process seems inefficient, but in reality all these roundtrips happen in a fraction of a second and make the maintenance of a huge database practical. That said, once your local DNS server has found information about a particular domain, it makes sense to store the information locally, reducing traffic and making response times faster. For this reason, many DNS servers are configured to contain a local cache. If a client asks a question that can be answered by records in the local cache, the DNS server answers directly and doesn't bother going anywhere else.

Cache poisoning
All of which brings us (finally) to DNS cache poisoning. If an attacker can somehow get incorrect records into a DNS cache, any client that contacts that DNS server for information about that domain will get the wrong information. An attacker could use cache poisoning to change the mapping of a domain name to an IP address, and therefore ensure that users end up visiting a fake, shadow version of a web site. Or, through different kinds of records, e-mail could be redirected to the attacker's own server.

To get the bogus records into a cache, the attacker must trigger the DNS server to ask for the record, and then provide a bogus answer to that question before the correct answer arrives. Triggering the DNS server to ask for the record is easy. By configuring your client to use the DNS server you are attacking, you can trigger a query by entering an address into a browser, or pinging the remote host.

Assuming the DNS server doesn't already have the appropriate record, it will now send out its usual questions, and if you can quickly spoof a response before the correct response comes, the DNS server will have the wrong record stored in its cache. That record may stay in the cache for a long time, because the time to live of a particular record is specified on the record itself. So an attacker would typically give the spoofed record a very long time to live, meaning the attack could remain active for a long period of time.

To a new level
Internet security people have known about this kind of low level DNS cache poisoning for some time, but Kaminsky discovered how this type of attack could be expanded to make it much more dangerous. This enhanced form of DNS cache poisoning doesn't just involve individual records any more, but entire domains. Remember in the previous example how a root server would respond with the names of the .com DNS servers, and a .com DNS server with the DNS servers for slaterinseattle.com? Well all that information gets cached too. If I can get records into the cache that show a bogus IP address for the slaterinseattle.com DNS server, I could potentially spoof the entire domain. Now imagine if that domain was a major search engine. Go one level higher, then I put any .com domain at risk, and one level higher still I put every domain on the Internet at risk.

The practical risk from this type of attack rests in an extra level of detail that I can only summarise here. DNS servers typically issue many queries of the type I've described, sometimes hundreds a second. So as the responses flood in they need to match them to the initial queries. This is done using a query ID. This goes out in the initial request, and if the response has a query ID that matches (and other elements are the same), it is accepted as a response, the information is passed on to the client and the record is cached. So for an attack to be successful, the attacker must get the query ID right in the spoofed response. Not only that, but the attacker's spoofed response must be received prior to the correct response.

What this means is that the security of a DNS implementation really resides in how random the query IDs are. Older implementations of DNS would simply increment the query ID by 1 for each new query. That meant they were easy to guess. Once an attacker found one query ID, he would simply flood the server with query IDs for the next few hundred numbers and a match would probably be found. This could be automated and if the network topology was in the attacker's favour, could happen before the genuine response was received.

Patch work
More recently, security had been tightened up, and a query ID would be randomly generated from 64,000 possibilities. But a coordinated attack against randomly generated names in a domain, paired with random query IDs can be successful, and can compromise a cache on a targeted DNS server within a few minutes.

After Kaminsky's discovery, multiple vendors met secretly at Microsoft's campus to come up with a patch to remedy the issue. Those patches were released on the same day the official reports came out about the issue (and the details were only released later to give organisations time to patch their servers). The patches involve also randomly generating a source UDP port for the request, and an attacker would need to guess both this and the query ID to successfully poison the DNS cache.
If you routinely apply patches marked as "important" or "critical" on your servers, you will be protected to the level that is currently possible. There is little more that you can do, except to validate that your ISP has deployed the patch, and that it did so very rapidly (if it did not, it might be worth looking for a new ISP).

Clearly the vendors worked quickly and effectively to come up with a coordinated response, which is impressive (and a little surprising), but as I write today, still around half the world's DNS servers are yet to be patched. The vulnerability itself was not discovered by any government secret service or cybersecurity organisation, but by a private individual who just happened to be one of the good guys. If there is a call to action this month, it would be to do what you can to make sure that all governments recognise the nature of this kind of threat to national security.