Not all sequels are good! Especially if the sequel is one of the most severe cybersecurity threats of all time. Researchers have recently discovered that the DNS Cache Poisoning attack is back from the dead and can cause damage to data by malevolently spoofing IP addresses.
In case you don’t know the DNS cache poisoning, let us give you some background.
A researcher Dan Kaminsky, in the year 2008, discovered a vulnerability in the domain name system, which could have allowed malevolent attackers to misguide users to the wrong websites instead of the original ones. This problem affected multiple DNS providers across the globe, after which a fix was released.
Now, 12 years later, researchers have unveiled a way to make the DNS poisoning attack possible. The researchers that found the flaw in the system have created a report, wherein all the nuances of it are explained in thorough detail. This attack has been named the SAD DNS.
What was the DNS Cache Poisoning attack of 2008?
Now that we are discussing the returned DNS Cache Poisoning attack, it is worthwhile to know more about the initial DNS Cache Poisoning attack. It will help us understand what this attack is and also what is different this time.
Once the DNS was devised, its protection was a matter of concern for internet architects. They knew that impersonating an authoritative server & returning malevolent results to the resolvers was a prime possibility that attackers could exploit. Their solution to it was 16-bit lookup transaction numbers designed by them. These numbers were to be attached with each request sent to the authoritative server and the resolver would only accept responses containing the same ID.
Good enough. But here’s the catch.
There were only 65,536 possible transaction IDs, which was a major drawback. This meant that attackers had a way of this drawback. All they had to do was flood the DNS resolver with a malicious IP for domains that had slight variations in them. Consider, for example, 1.google.com, 2.google.com and more. Here each response will have a unique transaction ID. In this process, there will be at least one accurate transaction ID number which will then allow the attacker to feed their malicious IP to all the users relying on the resolver.
But, why was it named Cache Poisoning?
By using the method of swarming the DNS resolver, the attacker eventually taints the resolver’s store of lookups, hence the name DNS Cache Poisoning attack.
Also read,
Now, what was done to make things better?
The eventual solution to the problem at the time was to exponentially increase the entropy amount required for the acceptance of a response. This was done so as to safeguard the DNS resolver better.
How this changed was that where the old system required the responses & lookups to only travel over port 53, the new system randomized the usage of port-number lookup requests. Besides, the response also needed to contain the same port number for the DNS resolver to accept the IP address. The entropy could be measured in billions, owing to it being combined with a transaction number. It became very inconvenient and implausible for the attackers to land the correct combination to perform the attack.
What does the Cache Poisoning attack 2020 look like?
Last Wednesday, researches from two Universities proved that cache poisoning was still plausible. The researchers from the University of California & Tsinghua University devised a method that exploits a side-channel to identify the lookup request port-number. And once the port-number is determined, the circle of guessing the transaction ID can be performed again as mentioned above to perform the attack.
In order to conserve the computing resources & bandwidth, servers can only respond to a set number of requests coming from the other servers. Once that limit of requests is reached, the servers will cease to provide any response at all. By far, Linux has set this limit to a thousand per second. In the scenario of this attack, this rate limit of ICMP (Internet Control Message Protocol) becomes the side channel that the attackers can resort to.
How do they do that?
They made use of a new spoofing technique that swarms the DNS resolver with multiple spoofed responses, each of which I sent over a different port. These responses, since spoofed, look like they belong to a genuine server, that is to be impersonated.
Now, what will happen is that each time the wrong port receives the request, the server will send a response claiming that the port is unreachable, which in turn will re reduce the global rate limit by one. But, when the request is sent to the correct port, the server will send no response whatsoever, thus not altering the rate limit counter.
This basically makes it possible for the attackers to measure the rate limit after they sent a request. The attacker can successfully do this using their own non-spoofed IP-address too. Once they receive an ICMP message, they can affirm that one of the multiple ports is open. This allows them to be able to eliminate & reach the accurate port number.
What can be done?
These findings have been submitted to both the DNS providers as well as the software developers. In order to enhance safety, the Linux Kernel developers have introduced a change in the system. This change causes the rate limit of ICMP to fluctuate between 500 to 2000 per second randomly. This is supposed to avoid the above-mentioned attack technique from succeeding.
Besides this, Cloudflare has also introduced their own version of the fix that will cause the DNS service to fall back to TCP making it infeasible to spoof.
The fact that this technique can be used to target public DNS servers like Google 8.8.8.8 and Cloudflare 1.1.1.1 and that the internet is filled with vulnerable public DNS and open resolvers, makes it a scary situation for everyone. It is the companies’ responsibility to identify & mitigate such vulnerabilities so that a lot of people do not risk their data.
