In 2008, researcher Dan Kaminsky revealed one of the most serious Internet security threats ever: a weakness in the domain name system that allowed attackers to massively send users to bogus sites instead of the genuine sites of Google, Bank of America, or anyone else. With industry-wide coordination, thousands of DNS providers around the world have installed a solution that has averted this doomsday scenario.
Now Kaminsky’s DNS cache poisoning attack is back. Researchers on Wednesday presented a new technique that could again cause DNS resolvers to maliciously return spoofed IP addresses instead of the site that legitimately matches a domain name.
“This is quite a big advancement similar to Kaminsky’s attack for some resolvers, depending on how [they’re] actually running,” said Nick Sullivan, chief of research at Cloudflare, a content-delivery network that runs the 188.8.131.52 DNS service. “This is one of the most effective DNS cache poisoning attacks we’ve seen since Kaminsky’s attack. It’s something you should take seriously if you’re running a DNS resolver.”
When people send emails, surf 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. This is a server or group of servers usually owned by the ISP, company or large organization the user is connected to.
In case another user of the ISP or organization has recently interacted with the same domain, the resolver has already cached the corresponding IP address and will return the result. If not, the resolver will query the dedicated authoritative server for that specific domain. The authoritative server then returns a response, which the resolver provides to the user and temporarily caches it for any other users who may need it in the near future.
The entire process is unauthenticated, which means that the authoritative server does not use passwords or other credentials to prove that it is indeed authoritative. DNS lookups also take place using UDP packets, which are only sent in one direction. As a result, UDP packets are usually trivial to forge, meaning someone can make UDP traffic appear to be coming from somewhere other than where it actually came from.
DNS Cache Poisoning: A Summary
When Internet architects first designed the DNS, they realized that it was possible for someone to pose as an authoritative server and use the DNS to send malicious results back to the resolvers. To protect against this possibility, the architects designed lookup transaction numbers. Resolvers appended these 16-bit numbers to every request sent to an authoritative server. The resolver will only accept a response if it contains 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 address for a domain with minor variations, for example 1.google.com, 2.google.com, etc., and using a different transaction ID for each answer to record. Ultimately, an attacker would reproduce the correct number and the malicious IP address would be passed on to all users who trusted the resolver. The attack was dubbed DNS cache poisoning because it compromised the resolver’s lookup storage.
The DNS ecosystem solved the problem by exponentially increasing the amount of entropy required to accept a response. Where previously lookups and responses only went through port 53, the new system randomized the used lookups by port number. For a DNS resolver to accept the IP address, the response also had to contain the same port number. Combined with a transaction number, entropy was measured in billions, making it mathematically impossible for attackers to land on the right combination.
Cache poisoning redux
On Wednesday, researchers from Tsinghua University and the University of California, Riverside presented a technique that enables cache poisoning again. Their method uses a side channel that identifies the port number used in a lookup request. Once the attackers know the number, they again have a high chance of guessing the transaction ID.
The side channel in this case is the rate limit for ICMP, short for the Internet Control Message Protocol. To save bandwidth and computing resources, servers only respond to a certain number of requests from other servers. After that, the servers stop responding at all. Until recently, Linux always set this limit at 1,000 per second.
To take advantage of this side channel, the new spoofing technique floods a DNS resolver with a large number of responses that are spoofed so that they appear to come from the name server of the domain they want to impersonate. Each response is sent through a different port.
When an attacker sends a response over the wrong port, the server sends a response that the port is unreachable, reducing the global speed limit by one. When the attacker sends a request over the correct port, the server will not respond at all, which does not change the rate limit counter. If the attacker examines 1,000 different ports with spoofed responses in one second and they are all closed, the entire rate limit will be completely drained. Conversely, if one of the 1,000 ports is open, the limit drops to 999.
Then the attacker can use their own unspoken IP address to measure the remaining rate limit. And if the server responds with a single ICMP message, the attacker knows that one of the previously examined 1,000 ports must be open and can further narrow down to the exact port number.
“How do we know?”
“We are indirectly trying to conclude that the resolver sent an ICMP unreachable message to the authoritative server,” UC Riverside professor Zhiyun Qian told me. “How do we know? Because the resolver can only send a fixed number of such ICMP messages per second, which means that the attacker could also try to request such ICMP packets for itself.”
The researchers’ report, DNS Cache Poisoning Attack Reloaded: Side Channel Revolutions, provides a much more detailed and technical description of the attack. They call the attack SAD DNS, short for Side channel AttackeD DNS.
The researchers have provided their findings privately to DNS providers and software developers. In response, Linux kernel developers introduced a change that causes the speed limit to randomly fluctuate between 500 and 2,000 per second. Professor Qian said the fix will stop the new technique from working. Cloudflare has introduced its own solution. In some cases, the DNS service falls 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 by video this year due to the COVID-19 pandemic. The researchers provide additional information here and a press release from UC Riverside is here.