DNS cache poisoning, the Internet attack from 2008, is back from the dead

[Karlston]

DNS cache poisoning, the Internet attack from 2008, is back from the dead

A newly found side channel in a widely used protocol lets attackers spoof domains.

Enlarge

Henrik 5000 / Getty Images

34 with 30 posters participating

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.

 

 

DNS cache poisoning, the Internet attack from 2008, is back from the dead

 

[steven36]

A group of academics from the University of California and Tsinghua University has uncovered a series of critical security flaws that could lead to a revival of DNS cache poisoning attacks.

 

 

 

Dubbed "SAD DNS attack" (short for Side-channel AttackeD DNS), the technique makes it possible for a malicious actor to carry out an off-path attack, rerouting any traffic originally destined to a specific domain to a server under their control, thereby allowing them to eavesdrop and tamper with the communications.

 

"This represents an important milestone — the first weaponizable network side channel attack that has serious security impacts," the researchers said. "The attack allows an off-path attacker to inject a malicious DNS record into a DNS cache."

 

Tracked as CVE-2020-25705, the findings were presented at the ACM Conference on Computer, and Communications Security (CCS '20) held this week.

 

The flaw affects operating systems Linux 3.18-5.10, Windows Server 2019 (version 1809) and newer, macOS 10.15 and newer, and FreeBSD 12.1.0 and newer.

 

 

DNS Forwarders Become New Attack Surface

DNS resolvers typically cache responses to IP address queries for a specific period as a means to improve response performance in a network. But this very mechanism can be exploited to poison the caches by impersonating the IP address DNS entries for a given website and redirect users attempting to visit that website to another site of the attacker's choice.

 

However, the effectiveness of such attacks has taken a hit in part due to protocols such as DNSSEC (Domain Name System Security Extensions) that creates a secure domain name system by adding cryptographic signatures to existing DNS records and randomization-based defenses that allow the DNS resolver to use a different source port and transaction ID (TxID) for every query.

 

 

 

Noting that the two mitigation measures are still far from being widely deployed due to "incentives and compatibility" reasons, the researchers said they devised a side-channel attack that can be successfully used against the most popular DNS software stacks, thus rendering public DNS resolvers like Cloudflare's 1.1.1.1 and Google's 8.8.8.8 vulnerable.

A Novel Side-Channel Attack

The SAD DNS attack works by making use of a compromised machine in any network that's capable of triggering a request out of a DNS forwarder or resolver, such as a public wireless network managed by a wireless router in a coffee shop, a shopping mall, or an airport.

 

 

It then leverages a side channel in the network protocol stack to scan and discover which source ports are used to initiate a DNS query and subsequently inject a large number of spoofed DNS replies by brute-forcing the TxIDs.

 

More specifically, the researchers used a channel used in the domain name requests to narrow down the exact source port number by sending spoofed UDP packets, each with different IP addresses, to a victim server and infer whether the spoofed probes have hit the right source port based on the ICMP responses received (or lack thereof).

 

This port scan method achieves a scanning speed of 1,000 ports per second, cumulatively taking a little over 60 seconds to enumerate the entire port range consisting of 65536 ports. With the source port thus derandomized, all an attacker has to do is to insert a malicious IP address to redirect website traffic and successfully pull off a DNS cache poisoning attack.

Mitigating SAD DNS Attacks

Aside from demonstrating ways to extend the attack window that permits an attacker to scan more ports and also inject additional rogue records to poison the DNS cache, the study found that over 34% of the open resolvers on the Internet are vulnerable, 85% of which comprise of popular DNS services like Google and Cloudflare.

 

To counter SAD DNS, the researchers recommend disabling outgoing ICMP responses and setting the timeout of DNS queries more aggressively.

 

The researchers have also put together a tool to check for DNS servers that are vulnerable to this attack. In addition, the group worked with the Linux kernel security team for a patch that randomizes the ICMP global rate limit to introduce noises to the side channel.

 

The research "presents a novel and general side channel based on [the] global ICMP rate limit, universally implemented by all modern operating systems," the researchers concluded. "This allows efficient scans of UDP source ports in DNS queries. Combined with techniques to extend the attack window, it leads to a powerful revival of the DNS cache poisoning attack."

 

Source

[steven36]

I could  not  get the test URL  from  the post   to work but  by going here it worked.

https://www.cs.ucr.edu/~zhiyunq/SADDNS.html

 

And testing Linux's Greg Hartman already have back ported and patched this.

https://lkml.org/lkml/2020/10/27/1098

 

More info  from here below