In 2008, researcher Dan Kaminsky revealed one of the more severe Internet security threats ever: a weakness in the domain name system that made it possible for attackers to send users en masse to imposter sites instead of the real ones belonging to Google, Bank of America, or anyone else. With industrywide coordination, thousands of DNS providers around the world installed a fix that averted this doomsday scenario.
Now, Kaminsky’s DNS cache poisoning attack is back. Researchers on Wednesday presented a new technique that can once again cause DNS resolvers to return maliciously spoofed IP addresses instead of the site that rightfully corresponds to a domain name.
“This is a pretty big advancement that is similar to Kaminsky’s attack for some resolvers, depending on how [they’re] actually run,” said Nick Sullivan, head of research at Cloudflare, a content-delivery network that operates the 1.1.1.1 DNS service. “This is amongst the most effective DNS cache poisoning attacks we’ve seen since Kaminsky’s attack. It’s something that, if you do run a DNS resolver, you should take seriously.”
DNS primer
When people send emails, browse a website, or do just about anything else on the Internet, their devices need a way to translate a domain name into the numerical IP address servers used to locate other servers. The first place a device will look is a DNS resolver, which is a server or group of servers that typically belong to the ISP, corporation, or large organization the user is connected to.
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.”
The researchers’ paper, DNS Cache Poisoning Attack Reloaded: Revolutions with Side Channels, provides a far more detailed and technical description of the attack. They call the attack SAD DNS short for Side channel AttackeD DNS.
The researchers privately provided their findings to DNS providers and software developers. In response, Linux kernel developers introduced a change that causes the rate limit to randomly fluctuate between 500 and 2,000 per second. Professor Qian said the fix prevents the new technique from working. Cloudflare introduced a fix of its own. In certain cases, its DNS service will fall back to TCP, which is much more difficult to spoof.
The research was presented at the 2020 ACM Conference on Computer and Communications Security, which is being held this year by video because of the COVID-19 pandemic. The researchers provide additional information here, and a UC Riverside press release is here.