DNS Spoofing is the result of changes made to a DNS server’s records, malicious redirection of traffic. DNS spoofing can be performed through a direct attack scenario on the server or through a man-in-the-middle attack targeting DNS traffic.
DNS Cache spoofing works in a way that clearly takes advantage of the way DNS communication is structure. When a DNS server attempts to perform a search on a domain, it forwards the request to the DNS authorized by the root account and moves through the chain of DNS servers recursively until it reaches the authoritative DNS server through the domain. Since the local DNS server does not know which server is responsible for which domain and the exact path to each proxy, it accepts responses from anywhere as long as the response matches the query and is formatted correctly. The attacker can take advantage of this design by defeating the real authoritative DNS server when responding to the local DNS server, and if it does, the local DNS server will use the attacker’s DNS record instead of the actual authoritative response. Due to the nature of DNS, the local DNS server has no way of determining which response is genuine and which is fake.
This attack is exacerbated by the fact that DNS servers cache searches internally so that the domain does not have to waste time querying the authoritative servers each time it is requested. This poses another problem because if an attacker can defeat the Authorized DNS server to arrive at an answer, the attacker’s record will be cached by the local DNS server, meaning any user using the local DNS server will be given the attacker record, and all potential users using that local DNS server will be directed to the site.
DNS Poisoning and Fraudulent Activities
Users who have a specific account at the bank and make their transactions over the internet are under the threat of fraud. The user who will log into the bank account over the Internet, if the DNS cache is poisoned; can be trapped and defrauded.
If the IP addresses of the entries in the cache have been changed, the person; Instead of his account at the bank, he enters the fake bank account prepared by the attacker. Here, while making data entry; can steal bank passwords. With these methods, offensive; It can empty the user’s bank account within minutes.
DNS Cache Poisoning Examples
Blind response fraud with a birthday attack
A DNS protocol change does not authenticate responses to repeated iterative queries. The only check to validate the query is the 16-bit transaction ID and the source IP address and destination port of the response packet. Before 2008, all DNS resolvers used the fixed port 53. Therefore, all the information needed to simulate a DNS response, except for the transaction ID, is predictable. DNS attacks that exploit this vulnerability are known as the “birthday paradox,” and on average, 2⁸ or 256 attempts are made to guess the transaction ID. For the attack to be successful, the fake DNS response must reach the target resolver before the legitimate authoritative response arrives. If the legitimate response comes first, it will be cached by the parser, and until the expiration date (TTL), the parser will not ask the proxy to resolve the same domain name and will not prevent the attacker from poisoning matching for that domain until the TTL expires.
Black Hat appeared in 2008, with the simple blinding technique remaining the same as an expanded version of the Birthday Attack. The underlying attack exploits of DNS replies use the pattern of DNS responses, which can be a response (direct IP address of the request) or a reference (the server authorized on a specific domain). Birthday Attack fabricates a response that injects an incorrect entry for a specific domain record. The Kaminsky exploit uses a redirect to make an incorrect entry for an entire domain name, bypassing the TTL on previous entries. The basic idea is for the attacker to select the domain they want to compromise and then query the target resolver for a subdomain that was not previously cached by the solution. Targeting subdomains that do not exist is a good bet so that the record is not cached by the DNS resolver. Because the subdomain is not in the cache, the target resolver sends a query to the proxy for that domain. At this point, the attacker stuffs the resolver with multiple bogus responses, each with a different pseudo transaction ID number. If the attacker succeeds in spurious response injection, the parser caches a mismatch for a proxy server. Future DNS queries to the target resolver of the compromised domain result in all requests forwarded to the attacker controller authoritative resolver, allowing the attacker to provide malicious answers without the need to add fake entries for each new DNS record.
Many new proposals to improve DNS security include source port randomization, 0x20 XOR encoding, WSEC-DNS, all dependent on the asymmetric availability of components used for authentication. In other words, they provide security through uncertainty rather than privacy through authentication and cryptography. Their only goal is to prevent attacks made by BLIND as discussed above. Using these security methods still leaves the DNS vulnerable to trivial attacks by compromised servers and network sniffers, this time without blind guessing, to remove ambiguity and perform the same attacks as seen above. Even in Layer 2 controlled environments, ARP poisoning and similar techniques can be used to force entire packets into a malicious computer, removing ambiguity.
DNS Cache Poisoning Risk Mitigation
The best way to prevent DNS revolvers from Cache Poisoning is to implement a secure encryption and authentication method. DNS as a protocol is outdated and surprisingly the backbone of the entire internet, it is an unencrypted protocol with no form of validation for the logins and responses it receives.
The solution, of course, is to provide an authentication and authentication method known as DNS Secure or DNSSEC. The protocol creates a unique cryptographic signature that is stored with DNS records. The signature is then used by the DNS resolver to verify a DNS response to ensure the record has not been tampered with. In addition, it provides a chain of trust from the Top-level domain to the domain authority zone and ensures the security of the entire DNS resolution process.
Despite these apparent advantages, DNSSEC adoption has been slow, and most of the less popular Top-level domains still do not use the security that DNSSEC provides. The main problem is that DNSSEC is complex to set up and needs upgraded devices to process the new protocol; Also historically, due to the rarity and inadequacy of most DNS spoofing attacks, DNSSEC implementation is not seen as a priority and is usually performed only once. devices reach the end of their useful life.
How Does DNS Poisoning or Spoofing Work?
DNS cache poisoning code is often found in URLs sent via spam emails. These emails try to frighten users into clicking the presented URL, thereby infecting their computers. Advertising banners and images found in e-mails and unreliable websites can also direct users to this code. After being poisoned, the user’s computer redirects the user to deceptive, fake websites that appear to be real, exposing them to risks such as spyware, keyloggers, or worms.