In the event another user of the ISP or organization has recently interacted with the same domain, the resolver will already have the corresponding IP address cached and will return the result. If not, the resolver will query the dedicated authoritative server for that particular domain. The authoritative server will then return a response, which the resolver will provide to the user and temporarily store in its cache for any other users who may need it in the near future.
The entire process is unauthenticated, meaning the authoritative server uses no passwords or other credentials to prove it is, in fact, authoritative. DNS lookups also occur using UDP packets, which are sent in only one direction. The result is that UDP packets are usually trivial to spoof, meaning someone can make UDP traffic appear to come from somewhere other than where it really originated.
DNS cache poisoning: A recap
When Internet architects first devised the DNS, they recognized it was possible for someone to impersonate an authoritative server and use the DNS to return malicious results to resolvers. To protect against this possibility, the architects designed lookup transaction numbers. Resolvers attached these 16-bit numbers to each request sent to an authoritative server. The resolver would only accept a response if it contained the same ID.
What Kaminsky realized was that there were only 65,536 possible transaction IDs. An attacker could exploit this limitation by flooding a DNS resolver with a malicious IP for a domain with slight variations—for instance, 1.google.com, 2.google.com, and so on—and by including a different transaction ID for each response. Eventually, an attacker would reproduce the correct number, and the malicious IP would get fed to all users who relied on the resolver. The attack was called DNS cache poisoning because it tainted the resolver's store of lookups.
The DNS ecosystem fixed the problem by exponentially increasing the amount of entropy required for a response to be accepted. Whereas before, lookups and responses traveled only over port 53, the new system randomized the port-number lookup requests used. For a DNS resolver to accept the IP address, the response also had to include that same port number. Combined with a transaction number, the entropy was measured in the billions, making it mathematically infeasible for attackers to land on the correct combination.
Cache poisoning redux
On Wednesday, researchers from Tsinghua University and the University of California, Riverside presented a technique that, once again, makes cache poisoning feasible. Their method exploits a side channel that identifies the port number used in a lookup request. Once the attackers know the number, they once again stand a high chance of successfully guessing the transaction ID.
The side channel in this case is the rate limit for ICMP, the abbreviation for the Internet Control Message Protocol. To conserve bandwidth and computing resources, servers will respond to only a set number of requests from other servers. After that, servers will provide no response at all. Until recently, Linux always set this limit to 1,000 per second.
To exploit this side channel, the new spoofing technique floods a DNS resolver with a high number of responses that are spoofed so they appear to come from the name server of the domain they want to impersonate. Each response is sent over a different port.
When an attacker sends a response over the wrong port, the server will send a response that the port is unreachable, which drains the global rate limit by one. When the attacker sends a request over the right port, the server will give no response at all, which doesn’t change the rate limit counter. If the attacker probes 1,000 different ports with spoofed responses in one second and all of them are closed, the entire rate limit will be drained completely. If, on the other hand, one out of the 1,000 ports is open, then the limit will be drained to 999.
Subsequently, the attacker can use its own non-spoofed IP address to measure the remaining rate limit. And if the server responds with one ICMP message, the attacker knows one of the previously probed 1,000 ports must be open and can further narrow down to the exact port number.
“How do we know?”
“We’re trying to indirectly infer that the resolver has sent an ICMP unreachable message to the authoritative server,” UC Riverside Professor Zhiyun Qian told me. “How do we know? Because the resolver can send only a fixed number of such ICMP messages in one second, which means the attacker can also try to solicit such ICMP packets to itself.”
Loading comments...
