DNS Cache Poisoning: Technology Overview, Examples, and Protection Methods
Despite being one of the oldest and most fundamental protocols of the internet, DNS still does not use encryption or validation of records and responses.
Author: Christopher Makarem
What Is DNS Cache Poisoning?
DNS spoofing involves altering records on a DNS server to redirect traffic. This can be done through a direct attack on the server (which is the focus of this article) or via a man-in-the-middle attack specifically targeting DNS traffic.
DNS cache poisoning exploits the way DNS communication works. When a DNS server tries to resolve a domain, it forwards the request to a root authoritative server and iteratively moves through the chain of DNS servers until it reaches the authoritative server for the domain. Since the local DNS server does not know which server belongs to which domain or the full path to every authoritative server, it accepts responses from anywhere as long as the response matches the request and the required format.
An attacker can exploit this by substituting the response from the actual authoritative DNS server with a fake one to the local server’s request. As a result, the local DNS server will use the attacker’s DNS records instead of the legitimate ones. Due to the DNS architecture, the local server cannot distinguish a fake response from a real one.
The situation is made worse because DNS servers cache queries sent between each other to save time on repeated requests to authoritative servers. If an attacker manages to substitute the response from the authoritative DNS server, the attacker’s records will be cached by the local DNS server, and all users of that server will receive the fake records. Ultimately, all users of the compromised local server will be redirected to the attacker’s site.
Figure 1: DNS Cache Poisoning Scheme
Examples of DNS Cache Poisoning
Blind Response Forgery via Birthday Attack
The DNS protocol does not provide for authentication of responses to recursive iterative queries. Only a 16-bit transaction ID, the source IP address, and the destination port in the response are checked. Until 2008, all DNS resolvers used the fixed port 53. Thus, aside from the transaction ID, all information needed to forge a response was predictable. Attacks exploiting this weakness were based on the “birthday paradox.” On average, it took 256 attempts (2 to the 8th power) to guess the transaction ID. For a successful attack, the fake DNS response must reach the target resolver before the legitimate response. If the legitimate response arrives first, it will be cached, and the resolver will not send another request for the same domain name until the TTL expires. Therefore, the attacker cannot poison the cache for that domain during the TTL period.
The Kaminsky Exploit
In 2008, a new method for the birthday attack was presented at the Black Hat conference. The basic blind guessing method remained the same. DNS responses can be of two types: one with the IP address for the query, and another (referral) with the server authorized for a specific zone. The birthday attack involves forging a response and injecting content for a specific domain record. The Kaminsky exploit uses a referral to create a fake record for an entire domain and bypass the TTL limitation of previous records.
First, the attacker selects a domain to compromise and sends a query to the target resolver for an uncached subdomain (any non-existent subdomain will do). Since the subdomain is not cached, the target resolver sends a request to the authoritative server for that domain. At this point, the attacker floods the resolver with a large number of fake responses with different transaction IDs. If the attacker succeeds in injecting a fake response, the resolver will cache the fake information as if it came from the authoritative server. Subsequent DNS queries to the target resolver for the compromised domain will be redirected to the attacker’s controlled authoritative resolver. As a result, the attacker can generate malicious responses without having to inject fake content for each new DNS record.
Traffic Interception
Many ideas for improving DNS security are based on randomizing the source port, such as using the 0x20 XOR algorithm or WSEC-DNS, depending on the asymmetric availability of authentication components. In other words, these security measures rely on uncertainty rather than confidentiality through authentication or cryptography. These techniques are designed to protect against the blind attacks described above. However, even with these methods, DNS remains vulnerable to trivial attacks involving server compromise and network sniffers, which can gather the necessary information to carry out the attacks described above. In this case, blind guessing is no longer required. Even in environments using switches, techniques like ARP poisoning and similar methods can be used to redirect all packets to the attacker, allowing them to gather the necessary information and bypass randomization and uncertainty-based protections.
Protection Against DNS Cache Poisoning: DNSSEC
The best way to prevent DNS resolver cache poisoning is to implement secure cryptographic and authentication methods. Despite being one of the oldest and most fundamental protocols of the internet, DNS still does not use encryption or validation of records and responses.
The solution is to implement verification and authentication called DNS Security Extensions, or DNSSEC. This protocol creates a unique cryptographic signature stored with DNS records. This signature is then used by the DNS resolver to verify the authenticity of the response and the record. Additionally, this scheme is used to create a trusted chain from the TLD to the authoritative domain zone and to secure DNS name resolution.
Despite its clear advantages, DNSSEC adoption has been slow, and many less popular TLDs still have not implemented DNSSEC-based security measures. The main problem is the complexity of setting up DNSSEC and the need to upgrade equipment to support the new protocol. Furthermore, since most DNS spoofing attacks have become outdated and less relevant, implementing DNSSEC is often not a priority and usually happens only when it’s time to replace equipment.