The DNS cache poisoning, the 2008 web assault, has returned from the useless
In 2008, researcher Dan Kaminsky exposed one of the most serious internet security threats of all time: a flaw in the domain name system that allowed attackers to send users en masse to scam websites rather than the actual Google, Bank websites of America or anyone else. With industry coordination, thousands of DNS providers around the world have installed a fix that prevents this doomsday scenario.
Now Kaminsky's DNS cache poisoning attack is back. Researchers on Wednesday unveiled a new technique that allows DNS resolvers to once again return maliciously spoofed IP addresses instead of the site that rightfully corresponds to a domain name.
"This is pretty big a leap forward, and it's similar to Kaminsky's attack for some resolvers, depending on how they're actually executed," said Nick Sullivan, chief research officer at Cloudflare, a content delivery network that operates 184.108.40.206 DNS- Service. "This is one of the most effective DNS cache poisoning attacks we've seen since Kaminsky's attack. If you're using a DNS resolver, take it seriously."
When users send email, browse a website, or do almost anything else on the Internet, their devices need a way to translate a domain name into the numeric IP address servers used to find other servers. The first place a device will appear is in a DNS resolver. This is a server or group of servers, usually owned by the ISP, company, or large organization that the user is connected to. advertising
If another user at the ISP or organization has recently interacted with the same domain, the resolver has already cached the corresponding IP address and returns the result. If not, the resolver queries the dedicated authoritative server for that particular domain. The authoritative server then returns a response that the resolver makes available to the user and temporarily stores it in its cache for any other users who may need it in the near future.
The whole process is not authenticated, meaning the authoritative server does not use passwords or other credentials to prove that it is indeed authoritative. DNS lookups are also performed on UDP packets that are only sent in one direction. The result is that UDP packets are usually trivial to forge, which means that someone will seemingly let UDP traffic come from a different location than where it actually originated.
DNS Cache Poisoning: A Summary
When Internet architects first developed DNS, they realized it was possible to impersonate an authoritative server and use DNS to return malicious results to resolvers. To protect themselves from this possibility, the architects designed lookup transaction numbers. Resolvers appended these 16-bit numbers to every request sent to an authoritative server. The resolver would only accept a response if it contained the same ID.
Kaminsky realized 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 minor deviations, e.g. B. 1.google.com, 2.google.com, etc., and by specifying a different transaction ID for each domain response. Eventually, an attacker would reproduce the correct number and the malicious IP would be forwarded to all users who rely on the resolver. The attack was known as DNS cache poisoning because it put pressure on the resolver's search memory.
The DNS ecosystem addressed the problem by increasing exponentially the entropy required for an answer to be accepted. While previously searches and responses were only transmitted via port 53, the new system has randomized the search requests used for port numbers. For a DNS resolver to accept the IP address, the response had to contain the same port number. In combination with a transaction number, the entropy was measured in the billions, which made it mathematically impossible for attackers to land on the correct combination.
Cache Poisoning Reduction
On Wednesday, researchers from Tsinghua University and the University of California, Riverside, presented a technique that makes cache poisoning possible again. Their method uses a side channel that identifies the port number used in a search request. As soon as the attackers know the number, they have another high chance of successfully guessing the transaction ID.
In this case, the side channel is the rate limit for ICMP, the abbreviation for the Internet Control Message Protocol. To save bandwidth and computing resources, servers only respond to a set number of requests from other servers. After that, the servers do not respond at all. Until recently, Linux always set this limit at 1,000 per second.
To take advantage of this side channel, the new spoofing technique floods a DNS resolver with a large number of responses that are spoofed so that they appear to come from the name server of the domain they are trying to impersonate. Each response is sent on a different port.
If an attacker sends a response on the wrong port, the server sends a response that the port is unreachable, reducing the global rate limit by one. If the attacker sends a request on the correct port, the server will not respond at all, which will not change the rate limit counter. If the attacker checks 1,000 different ports with fake responses in one second and all of them are closed, the entire rate limit will be completely used up. On the other hand, if one of the 1,000 ports is open, the limit is lowered to 999.
The attacker can then use their own non-spoofed IP address to measure the remaining rate limit. If the server replies with an ICMP message, the attacker knows that one of the 1,000 ports previously examined must be open and can narrow down the exact port number.
"How do we know?"
"We're trying to indirectly conclude that the resolver sent an unreachable ICMP message to the authoritative server," UC Riverside Professor Zhiyun Qian told me. "How do we know? Since the resolver can only send a fixed number of such ICMP messages in one second, the attacker can also try to request such ICMP packets for himself." advertising
The researchers' paper, DNS Cache Poisoning Attack Reloaded: Side-Channel Revolutions, 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 made their results privately available 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 update prevented the new technique from working. Cloudflare introduced its own fix. In certain cases, the DNS service uses TCP, which is much more difficult to spoof.
The research was featured at the 2020 ACM Conference on Computer and Communications Security, which will be held via video this year due to the COVID-19 pandemic. The researchers provide additional information here, and a press release from UC Riverside is available here.