DNS cache poisoning poised for a comeback: Sad DNS | ZDNet

Back in 2008, Domain Name System (DNS) server cache poisoning was a big deal. By redirecting the results from DNS with misleading Internet Protocol (IP) addresses, hackers could redirect your web browser from the safe site you wanted to a fake one loaded with malware. Fixes were discovered and DNS cache poisoning attacks became rare. Now, thanks to a discovery by the University of California at Riverside researchers, a new way has been found to exploit vulnerable DNS caches: Sad DNS.

Here’s how it works: First, DNS is the internet’s master address list. With it, instead of writing out an IPv4 address like “173.245.48.1,” or an IPv6 address such as “2400:cb00:2048:1::c629:d7a2,” one of Cloudflare‘s many addresses, you simply type in “http://www.cloudflare.com,” DNS finds the right IP address for you, and you’re on your way.

With DNS cache poisoning, however, your DNS requests are intercepted and redirected to a poisoned DNS cache. This rogue cache gives your web browser or other internet application a malicious IP address. Instead of going to where you want to go, you’re sent to a fake site. That forged website can then upload ransomware to your PC or grab your user name, password, and account numbers. In a word: Ouch!

Modern defense measures — such as randomizing both the DNS query ID and the DNS request source port, DNS-based Authentication of Named Entities (DANE), and Domain Name System Security Extensions (DNSSE) — largely stopped DNS cache poisoning. These DNS security methods, however, have never been deployed enough, so DNS-based attacks still happen.

Now, though researchers have found a side-channel attack that can be successfully used against the most popular DNS software stacks, SAD DNS. Vulnerable programs include the widely used BIND, Unbound, and dnsmasq running on top of Linux and other operating systems. The major vulnerability is when the DNS server’s operating system and network are configured to allow Internet Control Message Protocol ICMP error messages. 

Here’s how it works: First, the attacker uses a vice to spoof IP addresses and a computer able to trigger a request out of a DNS forwarder or resolver. Forwarders and resolvers help work out where to send DNS requests. For example, with a forwarder attack, when the attacker is logged into a LAN managed by a wireless router such as a school or library public wireless network. Public DNS resolvers, such as Cloudflare’s 1.1.1.1 and Google 8.8.8.8, can also be attacked. 

Next, the researchers used a network channel affiliated with, but outside of, the main channels used in the DNS requests. It then figures out the source port number by holding the channel open long enough to run 1,000 guesses per second until they hit the right one. With the source port derandomized, the group inserted a malicious IP address and successfully pull off a DNS cache poisoning attack.

In their study, they found just over 34% of the open resolver population on the internet is vulnerable. They found that 85% of the most popular free public DNS services are open to attacks. 

You can check to see if you’re open to attack simply by going to this Sad DNS web page and following the instructions. I’ll add that I’m both very security and network conscious and my systems were vulnerable. 

There are ways to stop these attacks. Indeed, we already have these methods. DNSSEC would help, but it’s still not deployed enough. If you used the relatively new RFC 7873 DNS cookie that would help as well. 

The simplest mitigation, though, is to disallow outgoing ICMP replies altogether. This comes at the potential cost of losing some network troubleshooting and diagnostic features. 

Another easy fix is to set the timeout of DNS queries more aggressively. For example, you should set it so that’s less than a second. This way the source port will be short-lived and disappear before the attacker can start injecting rogue responses. The downside, however, is the possibility of introducing more retransmitted queries and overall worse performance.

Whichever method you use, one thing though is clear. If you run a DNS server or forward you must do something. This attack is too easy. It will soon be used by criminal hackers. And, while I certainly recommend the quick and easy fixes, would it really kill you to finally start using DNSSEC? It’s way past time for everyone to adopt it. 

As for users, you must be more careful than ever that when you go to a commerce site like Amazon or your local bank that the site really is the one you think it is. If you don’t, you can kiss your online identity and a lot of money goodbye.

Related Stories: