[ad_1]
In 2008, researcher Dan Kaminsky revealed one of the most serious Internet security threats ever: a weakness in the domain name system that allowed attackers to send users en masse to impostor sites in the world. instead of the real ones owned by Google, Bank of America, or whoever else. Through industry-wide coordination, thousands of DNS providers around the world installed a patch that avoided this doomsday scenario.
Now, Kaminsky’s DNS cache poisoning attack is back. Researchers on Wednesday demonstrated a new technique that can once again trick DNS resolvers to return spoofed IP addresses instead of the site that rightfully matches a domain name.
“It’s a pretty big breakthrough that’s similar to Kaminsky’s attack for some resolvers, depending on how [they’re] Said Nick Sullivan, head of research at Cloudflare, a content delivery network that operates the DNS 1.1.1.1 service. “This is one of the most effective DNS cache poisoning attacks we’ve seen since the Kaminsky attack. This is something you need to take seriously if you are running a DNS resolver. “
DNS first
When people email, browse a website, or do just about anything else on the internet, their devices need a way to translate a domain name into digital IP address servers in use. to locate other servers. A device will first look for a DNS resolver, which is a server or a group of servers that is typically owned by the ISP, company, or large organization that the user is connected to.
In the event that another user from the ISP or organization has recently interacted with the same domain, the resolver will already have the corresponding IP address cached and return the result. Otherwise, the resolver will query the authoritative server dedicated for that particular domain. The authoritative server will then return a response, which the resolver will provide to the user and temporarily store in its cache for any other users who might need it in the near future.
The whole process is unauthenticated, which means the authoritative server does not use any passwords or other credentials to prove that it is in fact authoritative. DNS lookups also occur using UDP packets, which are sent in one direction only. The result is that UDP packets are generally easy to spoof, which means that someone can make UDP traffic appear to be coming from somewhere other than its origin.
DNS cache poisoning: a recap
When Internet architects first designed DNS, they recognized that it was possible for someone to impersonate an authoritative server and use DNS to return malicious results to resolvers. . To protect against this possibility, the architects devised search transaction numbers. Resolvers attached 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.
What Kaminsky realized was that there were only 65,536 possible transaction IDs. An attacker could exploit this limitation by flooding a DNS resolver with a malicious IP address for a domain with slight variations (e.g. 1.google.com, 2.google.com, etc.) and including a different transaction ID. for each answer. Eventually, an attacker would reproduce the correct number and the malicious IP address would be transmitted to all users who relied on the resolver. The attack was called DNS cache poisoning because it contaminated the resolver search store.
The DNS ecosystem solved the problem by exponentially increasing the amount of entropy required for a response to be accepted. Whereas previously searches and responses only traveled on port 53, the new system randomized the port number search queries used. For a DNS resolver to accept the IP address, the response had to include that same port number as well. Combined with a transaction number, entropy was measured in billions, making it mathematically impossible for attackers to land on the right combination.
Redux poisoning cache
On Wednesday, researchers at Tsinghua University and the University of California at Riverside demonstrated a technique that, once again, makes cache poisoning possible. Their method uses a secondary channel that identifies the port number used in a search request. Once attackers know the number, they again have a good chance of successfully guessing the transaction ID.
The secondary channel in this case is the rate limit for ICMP, short for Internet Control Message Protocol. To save bandwidth and computing resources, servers will only respond to a set number of requests from other servers. After that, the servers will not provide any response. Until recently, Linux always set this limit at 1000 per second.
To exploit this secondary channel, the new spoofing technique floods a DNS resolver with a high number of responses that are spoofed so that they appear to come from the name server of the domain they want to pass off. Each response is sent to a different port.
When an attacker sends a response on the wrong port, the server sends a response indicating that the port is unreachable, which drains the overall rate limit of one. When the attacker sends a request to the correct port, the server will give no response, which does not change the rate limit counter. If the attacker probes 1000 different ports with spoofed responses in one second and they are all closed, the entire rate limit will be completely exhausted. If, on the other hand, one of the 1000 ports is open, then the limit will be reduced to 999.
Subsequently, the attacker can use his own unspoiled IP address to measure the remaining rate limit. And if the server responds with a single ICMP message, the attacker knows that one of the 1000 ports probed previously must be open and may be further restricted to the exact port number.
“How do we know?”
“We are trying to indirectly infer that the resolver sent an ICMP unreachable message to the authoritative server,” Professor Zhiyun Qian of UC Riverside told me. “How do we know? Because the resolver can only send a fixed number of such ICMP messages in a second, which means the attacker can also try to solicit such ICMP packets for himself.”
The researchers’ paper, Reloaded DNS Cache Poisoning Attack: Revolutions with Secondary Channels, provides a much more detailed and technical description of the attack.
The researchers privately provided their results to DNS providers and software developers. In response, the Linux kernel developers introduced a change that causes the rate limit to fluctuate randomly between 500 and 2000 per second. Prof Qian said the patch prevents the new technique from working. Cloudflare has introduced its own patch. In some cases, its DNS service will fall back to TCP, which is much more difficult to spoof.
The research was presented at the 2020 ACM Computer and Communications Security Conference, which is being held this year via video due to the COVID-19 pandemic. Researchers provide additional information here, and a UC Riverside press release is here.
[ad_2]
Source link