DNS Server Attack - Cache Poisoning

There has been a long history of attacks on the Domain Name System ranging from brute-force denial-of-service attacks to targeted attacks requiring specialized software.
 
DNS Working:

• A computer sends a “question” to a DNS server, asking a question like “What is the IP address for google.com?”
• The computer gets an answer, and if the answer appears to match the question it asked, completely trusts that it is correct.

However, there are multiple ways that traffic on the Internet can be intercepted and rerouted, or impersonated, so that the answer given is false. This is known as Cache Poisoning.

Cache Poison Attack:
To improve efficiency, DNS servers typically store results in a cache to speed further lookups. This is the typical configuration at ISPs. With cache poisoning an attacker attempts to insert a fake address record for an Internet domain into the DNS. If the server accepts the fake record, the cache is poisoned and subsequent requests for the address of the domain are answered with the address of a server controlled by the attacker. For as long as the fake entry is cached by the server (entries usually have a time to live -- or TTL -- of a couple of hours) subscriber's browsers or e-mail servers will automatically go to the address provided by the compromised DNS server. 




A single attack on the DNS server affects the users attached to that server. The hacker exploits the DNS software. The attacker also uses DNS ID hacking to find the ID number of the user to poison the cache of the user. It is a kind of rerouting domain name to another IP address which may be phishing page of attacker. One successful cache poisoning attack can therefore affect many users.

This kind of attack is often categorized as a "pharming" attack and it creates several problems. First, users think they are at a familiar site, but they aren't. Unlike with a "phishing" attack where an alert user can spot a suspicious URL, in this case the URL is legitimate.

Another problem is that hundreds or even thousands of users can be redirected if an attacker successfully inserts a single fake entry into a caching server. The scale of the problem is amplified by the popularity of the domain being requested. Under these circumstances, even a moderately experienced hacker can cause a lot of trouble, obtaining passwords and other valuable or sensitive information.

Solution:

• Maximise the amount of randomness

UDP port used for a query should no longer be the default port 53, but rather a port randomly chosen from the entire range of UDP ports (less the reserved ports). UDP source port randomization, or UDP SPR, as it is called, makes it harder for an attacker to guess query parameters since now both the 16-bit query ID and as many as 16 additional bits for the UDP port must be correct, for a total of up to 4 billion combinations.

• Disable open recusive name servers 

Disable open recursive name servers. The attack is not effective if the attacker can not send question packets to the name server. However, if you must run a recursive name server, limit access to only
those computers that need it. (e.g. your customers). This will still be able to execute the attack, but the exposure is constrained.
Turn off open recursive name servers, if possible, because they can be used for other types of attack like denial of service.

• Introduce security to the DNS

The DNS is insecure. Therefore, for long term solution upgrade the DNS for security. DNSSEC is the current answer to this problem. This attack provides clear incentive to deploy a solution like DNSSEC, because without security the DNS will continue to be vulnerable to cache poisoning attacks.


 References:

1. http://resources.infosecinstitute.com/attacks-over-dns/
2. http://www.networkworld.com/article/2277316/tech-primers/how-dns-cache-poisoning-works.html
3. https://www.iana.org/about/presentations/davies-viareggio-entropyvuln-081002.pdf