DNS Cache Poisoning by Christopher Makarem

(46 views)

DNS Spoofing is the result of alterations to a DNS server’s records resulting in the malicious redirection of traffic. DNS spoofing can be performed by a direct attack on the DNS server (what we will be talking about here) or through any form of a Man-in-the-Middle attack specifically targeting DNS traffic.

DNS Cache spoofing works explicitly in a way that exploits the way in which DNS communication is structure. When a DNS server attempts to perform a lookup on a domain, it will forward the request along to the root authoritative DNS and iteratively proceed down the chain of DNS servers until it reaches the DNS server authoritative over the domain. Since the local DNS server does not know which server is in charge of which domain, and does not know the full route to each authoritative server, it accepts replies to its queries from anywhere so long as the reply matches the query and is formatted correctly. The attacker can exploit this design by beating the actual Authoritative DNS server in replying to the local DNS server, and if it does so, the local DNS server will use the attacker’s DNS record instead of the actual Authoritative answer. Due to the nature of DNS, the local DNS server has no way of determining which reply is real and which is fake.

This attack is made worse by the fact that DNS servers will cache lookups internally so that they don’t have to waste time querying the authoritative servers each time the domain is requested. This poses another problem, because if an attacker can beat the Authoritative DNS server to a reply, then the attackers record will be cached by the local DNS server meaning that any user that uses the local DNS server will be given the attackers record, potentially redirecting all users using that local DNS server to the attacker’s website.

DNS Cache Poisoning Workflow

Examples of DNS Cache Poisoning

Blind Response Forgery with Birthday Attack
A DNS protocol exchange does not authenticate responses to recursive iterative queries. The only checks to validate the query are the 16-bit transaction ID and the source IP address and destination port of the response packet. Before 2008, all DNS revolvers used fixed port 53. Therefore with the exception of the transaction ID, all information necessary to spoof a DNS reply is predictable. Attacks on DNS exploiting this weakness are known as the “birthday paradox” and on average take ²⁸ or 256 attempts to guess the transaction ID. For the attack to succeed, the forged DNS reply must arrive at the target resolver before the legitimate authoritative response does. If the legitimate response arrives first, it will be cached by the resolver, and until its time-to-live (TTL) expires, the resolver will not ask the authoritative server to resolve the same domain name, preventing the attacker from poisoning the mapping for that domain until the TTL expires.

Kaminsky Exploit
An extension of the Birthday Attack was revealed at Black Hat 2008, where the basic blind guessing technique remains the same. The attack exploits the underlying nature of DNS responses in that a DNS response can be an answer (the direct IP address of the request) or a referral (the server that is authoritative over a given zone). The Birthday Attack forges an answer that injects a false entry for a given domain record. The Kaminsky exploit utilizes a referral to make a false entry for an entire domain bypassing TTL on previous entries. The basic idea is that the attacker chooses the domain that they wish to compromise and then queries the target resolver for a sub-domain which is not already cached by the resolver (Targeting non-existent sub-domains is a good bet that the record is not cached by the DNS resolver). Since the sub-domain is not in the cache, the target resolver sends a query to the authoritative server for that domain. It is at this point that the attacker floods the resolver with a large number of forged responses, each with a different forged transaction ID number. If the attacker is successful in the injection of the forged response, then the resolver will cache a false mapping for an authoritative server. Future DNS queries to the target resolver of the compromised domain will result in all requests being forwarded to the attacker controller authoritative resolver enabling the attacker to provide malicious responses without a need to inject fake entries for each new DNS record.

Eavesdropping
Many new proposals for enhancing DNS security include source port randomization, 0x20 XOR encoding, WSEC-DNS, all depend on the asymmetrical accessibility of the components used for authentication. In other words, they provide security through obscurity rather than confidentiality through authentication and cryptography. Their only goal is to prevent BLIND attacks as discussed above. Using these security methods still leaves DNS vulnerable to trivial attacks of compromised servers and network eavesdroppers to break the obscurity and perform the same attacks as seen above, this time without blind guessing. Even in switched environments, ARP poisoning and similar techniques can be used to force all packets to a malicious computer and can defeat the obscurity.


DNS Cache Poisoning Mitigation

DNSSEC
The best way to prevent Cache Poisoning of DNS revolvers is to implement a secure method of cryptography and authentication. DNS as a protocol is antiquated and as a backbone of the entire internet is surprisingly still an unencrypted protocol without any form of validation for entries and responses it receives.

The solution, of course, is to provide a method of verification and authentication known as DNS Secure or DNSSEC. The protocol creates a unique cryptographic signature stored alongside the DNS records. The signature is then used by the DNS resolver to authenticate a DNS response ensuring the record was not tampered with. Additionally, it provides a chain of trust from the TLD all the way down to the domain authoritative zone, ensuring the whole process of DNS resolution is secured.

Despite these apparent benefits, DNSSEC has been slow to be adopted, and many of the less popular TLDs still do not make use of the security DNSSEC provides. The main issue is that DNSSEC is complex to set up and requires upgraded appliances to handle the new protocol, additionally due to the rarity and impotence of most DNS spoofing attacks historically, implementation of DNSSEC is not seen as a priority and is usually only performed once appliances reach the end of their life cycle.


Originally posted: https://medium.com/iocscan/dns-cache-poisoning-bea939b5afaf 

February 25, 2019
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Newest
Oldest Most Voted
Inline Feedbacks
View all comments
© HAKIN9 MEDIA SP. Z O.O. SP. K. 2023