Despite the fact that DNS is one of the oldest protocols that is the mainstay of the entire Internet, it still does not use encryption and validation of records and responses.
During DNS spoofing, records on the DNS server are changed in order to redirect traffic. DNS spoofing can be performed through a direct attack on the server (which we will talk about in this article) or through a man-in-the-middle attack specifically tailored for DNS traffic.
DNS cache spoofing is based on exploiting the DNS communication scheme. When a DNS server tries to do a domain lookup, it redirects the request to the root authoritative server and iterates through the chain of DNS servers until it reaches the authoritative server in the domain. Since the local DNS server does not know which server belongs to which domain, and does not know the full path to each authorized server, it accepts responses to its requests from anywhere as long as the response matches the request and the required format.
An attacker can exploit this scheme and spoof the response of the current authorized DNS server to the request of the local server. Thus, the local DNS server will use the attacker's DNS records instead of the authoritative server's response. Due to the architecture of DNS, the local server cannot distinguish a fake response from a real one.
The situation is aggravated even more, because DNS servers cache requests sent among themselves in order to save time on requests to authorized servers each time a domain is queried. Another problem arises here. If an attacker is able to spoof the response of an authorized DNS server, then the records used by the attacker will be cached by the local DNS server, and fake records will be given to other users of this local server. As a result, all users of this local server will be redirected to the attacker's site.
Figure 1: DNS Cache Poisoning Scheme
Examples of DNS cache poisoning
Faking a blind response through a birthday attackThe DNS protocol does not provide for authentication of the response to recursive iterative queries. Only the 16-bit transaction ID, source IP and target port present in the response are checked. Until 2008, all DNS resolvers used a fixed port 53. Thus, apart from the transaction ID, all information that needed to be tampered with at the time of response was predictable. DNS attacks exploiting this weakness were based on the birthday paradox. On average, it took 256 attempts (two to the eighth power) to guess the transaction ID. For an attack to succeed, a bogus DNS response must reach the target resolver before a legitimate response. If the legitimate answer comes first, then it will be cached and until the TTL expires, the resolver will not send a request with the same domain name. Thus, Exploit kaminsky.
In 2008, at the Black Hat conference, an innovation was proposed for the birthday attack. The basic blind guessing method remains the same. DNS responses can be of two types: the first type - with the IP address of the request, the second (referral) - with a server authorized for a specific zone. The birthday attack fakes the response and injects content for the specified domain record. The Kaminsogo exploit uses a referral to create a fake entry for an entire domain and bypass the TTL restriction of previous entries. First, the attacker selects the domain to compromise, and then sends a request to the target resolver for the uncached subdomain (a target non-existent subdomain is fine). Since the subdomain is not in the cache, the target resolver sends the request to the authoritative server for that domain. At this point, the attacker spam the resolver with a large number of bogus responses with different transaction IDs. If an attacker succeeds in injecting a bogus response, the resolver will cache the bogus information on behalf of the authoritative server. Subsequent DNS queries to the target resolver of the compromised domain will be forwarded to the authorized resolver of the attacker's controller. As a result, an attacker will be able to generate malicious responses without having to inject fake content for each new DNS record. Subsequent DNS queries to the target resolver of the compromised domain will be redirected to the authorized resolver of the attacker's controller. As a result, an attacker will be able to generate malicious responses without having to inject fake content for each new DNS record. Subsequent DNS queries to the target resolver of the compromised domain will be redirected to the authorized resolver of the attacker's controller. As a result, an attacker will be able to generate malicious responses without having to inject fake content for each new DNS record.
Traffic interception
Many ideas for improving DNS security relate to source port randomization, such as 0x20 XOR encoding or WSEC-DNS depending on the asymmetric availability of the components used for authentication. In other words, these security measures are based on uncertainty, not confidentiality through authentication or cryptography. These techniques are aimed at defending against the blind attacks described above. However, when using these methods, DNS remains vulnerable to trivial attacks related to compromising servers and network eavesdroppers to find out the necessary information and then implement the attacks described above. In this case, blind guessing is no longer required. Even in environments where switches are used.DNSSEC DNS Cache Sending Protection
The best way to prevent DNS resolver cache poisoning is to implement a secure method of cryptography and authentication. Despite the fact that DNS is one of the oldest protocols that is the mainstay of the entire Internet, it still does not use encryption and validation of records and responses.The solution is to implement verification and authentication called DNS Secure or DNSSEC. This protocol creates a unique cryptographic signature that is stored along with the DNS records. This signature is then used by the DNS resolver to authenticate the response and record. In addition, this scheme is used to create a trustworthy chain from the TLD to the authorized domain zone and to secure DNS name resolution.
Despite the obvious benefits, DNSSEC has been slow to implement, and many not-so-popular TLDs have yet to implement DNSSEC-based security measures. The main problem is the difficulty of installing DNSSEC and the need to upgrade the equipment to work with the new protocol. In addition, due to the obsolescence and relevance of most DNS spoofing attacks, DNSSEC implementation is not a priority and usually occurs when it is time to change hardware.
Author: Christopher Makarem
