In the 1990s, the poisoner’s job was relatively easy. The lower-level name servers are generally maintained by private entities: Amazon, for instance, controls the addresses supplied by the amazon.com name server. If a low-level name server can’t find a requested address, it will either refer the requester to another name server or tell the requester the page doesn’t exist. But in the ’90s, the low-level server could also furnish the requester with the top-level server’s address. To poison a cache, an attacker simply had to falsify that information. If an attacker tricked, say, an ISP’s name server into storing the wrong address for the .com server, it could hijack most of the traffic traveling over the ISP’s network. Mockapetris says several features were subsequently added to DNS to protect the system. Requesting servers stopped accepting higher-level numerical addresses from lower-level name servers. But attackers found a way around that restriction. As before, they would refer a requester back to, say, the .com server. But now the requester had to look up the .com server’s address on its own. It would request the address, and the attacker would race to respond with a forged reply before the real reply arrived. Ad hoc security measures were added to protect against this strategy, too. Now, each request to a DNS server carries a randomly generated transaction ID, one of 65,000 possible numbers, which the reply must contain as well. An attacker racing to beat a legitimate reply would also have to guess the correct transaction ID. Unfortunately, a computer can generate so many false replies so quickly that if it has enough chances, it’s bound to find the correct ID. So the time to live, originally meant to keep name servers from being overburdened by too many requests, became yet another stopgap security feature. Because the requesting server will store an answer for some period of time, the attacker gets only a few chances to attempt a forgery. Most of the time, when the server needs a .com address, it consults its cache rather than checking with the .com server. Kaminsky found a way to bypass these ad hoc security features–most important, the time to live. That made the system just as vulnerable as it was when cache poisoning was first discovered. Using Kaminsky’s technique, an attacker gets a nearly infinite number of chances to supply a forgery. Say an attacker wants to hijack all the e-mail that a social-networking site like Facebook or MySpace sends to Gmail accounts. He signs up for an account with the social network, and when he’s prompted for an e-mail address, he supplies one that points to a domain he controls. He begins to log on to the social network but claims to have forgotten his password. When the system tries to send a new password, it does a DNS lookup that leads to the attacker’s domain. But the attacker’s server claims that the requested address is invalid. At this point, the attacker could refer the requester to the google.com name servers and race to supply a forged response. But then he would get only one shot at cracking the transaction ID. So instead, he refers the requester to the nonexistent domains 1.google.com, then 2.google.com, then 3.google.com, and so on, sending a flood of phony responses for each. Each time, the requesting server will consult Google’s name servers rather than its cache, since it won’t have stored addresses for any of the phony URLs. The attack completely bypasses the limits set by the time to live. One of the attacker’s forgeries is bound to get through. Then it’s a simple matter to direct anything the requesting server intends for Google to the attacker’s own servers, since the attacker appears to have authority for URLs ending in google.com. Kaminsky says he was able to pull off test attacks in as little as 10 seconds.
Gain the insight you need on security at EmTech Digital.