DNS cache poisoning is about to make a comeback: Sad DNS

In 2008, Domain Name System (DNS) server cache poisoning was a big deal. By redirecting the results of DNS with misleading Internet Protocol (IP) addresses, hackers can redirect your web browser from the desired secure website to a spoofed malware website. Corrections were discovered and DNS cache poisoning attacks became rare. Thanks to a discovery made by researchers at the University of California at Riverside, a new way has now been found to exploit vulnerable DNS caches: Sad DNS.

Here’s how it works: First, DNS is the Internet’s main address list. Instead of writing an IPv4 address like “173.245.48.1” or an IPv6 address like “2400: cb00: 2048: 1 :: c629: d7a2”, one of Cloudflare’s many addresses, just enter “http”: //www.cloudflare.com, “DNS finds the right IP address for you and you’re on your way.

However, if DNS cache poisoning occurs, your DNS requests will be intercepted and redirected to a poisoned DNS cache. This unwanted cache gives your web browser or other internet application a malicious IP address. Instead of going where you want to go, you are sent to a fake site. This fake website can then upload ransomware to your PC or retrieve your username, password and account numbers. In a word: Ouch!

Modern defenses – such as the random assignment of DNS query ID and DNS request source port, DNS-based Named Entity Authentication (DANE), and Domain Name System Security Extensions (DNSSE) – have largely stopped DNS cache poisoning. However, these DNS security methods have never been adequately deployed so that DNS-based attacks continue to occur.

Although 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 programs that run on Linux and other operating systems. The main vulnerability is that the operating system and network of the DNS server are configured to allow ICMP error messages from the Internet Control Message Protocol.

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

Next, the researchers used a network channel connected to but outside of the main channels used in the DNS requests. Then the source port number is determined by keeping the channel open long enough to make 1,000 guesses per second until the correct one is made. After the source port was derandomized, the group inserted a malicious IP address and successfully carried out a DNS cache poisoning attack.

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

You can check if you are open to attack by simply going to this Sad DNS website and following the instructions. I would like to add that I am both very security and network conscious and my systems have been vulnerable.

There are ways to stop these attacks. In fact, we already have these methods. DNSSEC would help, but it’s still not deployed enough. If you were to use the relatively new DNS cookie RFC 7873 this would also be helpful.

The simplest mitigation, however, is to prohibit outbound ICMP responses altogether. This leads to the potential cost of losing some network troubleshooting and diagnostics.

Another simple solution is to time-out DNS queries more aggressively. For example, you should set it to take less than a second. In this way, the source port is short-lived and disappears before the attacker can inject unwanted responses. The downside, however, is the ability to introduce more retransmissions and overall poorer performance.

Whichever method you use, however, one thing is clear. If you are running or forwarding a DNS server, you have to do something. This attack is too easy. It will soon be used by criminal hackers. And while I definitely recommend the quick and easy fixes, would it really kill you to finally use DNSSEC? It is long past that everyone accepted it.

As for users, you need to be more careful than ever when visiting a commerce website like Amazon or your local bank that the website really is who you think it is. If you don’t, you could kiss your online identity and big bucks goodbye.

Similar posts: