DNS Cache Poisoning, the Internet Attack From 2008, Is Back From the Dead (arstechnica.com) 22
An anonymous reader quotes a report from Ars Technica : 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.
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. Linux kernel developers responded by introducing a change that causes the rate limit to randomly fluctuate between 500 and 2,000 per second, preventing the new technique from working. Cloudflare also introduced a fix where its DNS service will fall back to TCP, "which is much more difficult to spoof," reports Ars.
The researchers' press release is available here.
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. Linux kernel developers responded by introducing a change that causes the rate limit to randomly fluctuate between 500 and 2,000 per second, preventing the new technique from working. Cloudflare also introduced a fix where its DNS service will fall back to TCP, "which is much more difficult to spoof," reports Ars.
The researchers' press release is available here.
Re:No kidding (Score:5, Funny)
UDP and its consequences have been a disaster for the human race.
I was going to tell a joke about UDP. But some people might not get it.
Re: (Score:2)
As Bill the Cat would say, "ACK! Thppt!"
Re: (Score:2)
You sound like an UNRELIABLE source....
DNSSEC? (Score:3)
Anyone for DNSSEC? Or is everyone still pretending it doesn't exist?
Re: DNSSEC? (Score:5, Insightful)
Your ISP would rather you think it doesn't exist, and your vendor is too lazy to implement it.
Re: (Score:2)
Fortunately every OS has good secure DNS options (DoH, DoT, or DNSCrypt) that can point towards resolvers that use DNSSEC.
Re: (Score:2)
Actually many ISP turn on DNSSEC validation.
maybe this will change their minds... (Score:2)
DNSSEC + TCP only get implemented when there is a reason... here is the reason
Re: (Score:2)
Re: (Score:2)
There's even a good change your ISP's DNS servers will use DNSSEC client side even if
Re: (Score:2)
Re: (Score:2)
Google.com, Microsoft.com, etc all have DNSSEC and are immune to typical poisoning attacks right now.
You got my hopes up :(. Sadly google.com and microsoft.com don't have DNSSEC enabled. You can check on dnsviz.net. Amusingly microsoft.com are not even following RFCs for non-DNSSEC DNS, they are not case-preserving queries. Typical Microsoft.
Paypal.com does have DNSSEC enabled so there is some hope.
Now, However... (Score:2)
Unlike in 2008, in 2020 almost all big websites exclusively use https encrypted traffic. Spoofing DNS may be possible, spoofing site certificates is not.
Re: Now, However... (Score:1)
Re: (Score:1)
impotent launch
Sounds like a great name for a band.
Re: (Score:3)
Spoofing DNS may be possible, spoofing site certificates is not.
That would be cool, except that spoofing DNS allows you to get fraudulent certificates -- as many (in fact, most) of the CA cartel don't do any extra verification.
Both issues would be nicely solved by DNSSEC/DANE, but as that'd hurt malicious governments, we can't have that in mainstream browsers.
Re: (Score:2)
But we do have DNSSEC, as browsers support DoH, which most often people use to point towards DNSSEC-supporting servers like Quad9 or Cloudflare.
Re: (Score:2)
spoofing site certificates is
harder.
Re: (Score:2)
Unlike in 2008, in 2020 almost all big websites exclusively use https encrypted traffic. Spoofing DNS may be possible, spoofing site certificates is not.
If you can spoof dns, you can trick letsencrypt into giving you a certificate. Fortunately, letsencrypt already issues dns challenges from several geographically distributed hosts, so it's less likely you'd be able to trick all of their upstream dns recursive resolvers.
what do you mean "back"? (Score:1)
DNS cache poisoning never went away. It's part of the protocol. Every caching resolver has been vulnerable to it, we've known that.
Re: (Score:3)
Actually you can do DNS over UDP and not get successful cache poisoning. It does require using DNS COOKIE and falling back to TCP when the server doesn't support DNS COOKIE.
Note: the paper greatly underplays the availability of DNS COOKIE. It's supported by multiple vendors and 15-24% of authoritative server support DNS COOKIE in the 4 years since it became a RFC.