DNS Cache Poisoning

[Nytro]

DNS Cache Poisoning

November 21st, 2011|By: deepanker

DNS cache poisoning is a security compromise in which an attacker changes the resolver cache database entries of a DNS with some false information. The DNS server will then infect the user’s local resolver cache database with false information changed by the attacker. These lines may be difficult or little bit confusing to you, if you are not aware of DNS and Caching. Therefore, you have to know first, what is DNS and DNS cache? How DNS and DNS cache works?

DNS or Domain Name Server and its working: Every website on the internet has a unique IP address which is the address of the website on the large network of computers. In earlier days of internet, Users can only access website with the help of IP addresses. So, they had to know the IP address of websites they wanted to access. But now internet has millions of websites and it’s sure you cannot remember IP address of websites. So, domain name is the solution of this problem. Each website has given a domain name and the DNS translates your request into the IP. Domain name sever is the computer server which has a database to store the domain name and its IP address. When you type a website address in address bar of the browser, it sends a request to DNS for the IP address of the website. DNS replies with the IP address and then our browser navigate us to the website.

Figure 1: How DNS server works

DNS Cache: As we know the DNS translates the domain name to its corresponding IP address and this translation takes only few seconds on server ends. But the number of requests on the DNS is too high as there are millions of DNS queries processing on DNS which can results slow communication between DNS and other computers. So, to resolve the problem of speed and to speed up this whole process, cache is used. The cache stores recent DNS queries result on local computers. This reduces number of repetitive queries to remote DNS. This local cache is known as resolver cache and serves requests much faster than original DNS serving and this local resolver cache also reduce loads on DNS.

Therefore, each time when a computer requests for the IP address of a domain name, its local resolver DNS cache is searched first for the result. If the record is found in local resolver cache, computer has no need to communicate with DNS server otherwise request is sent to the DNS.

Figure 2: How recent query requests are looked in Cache first

How it works:

The whole process of sending request and getting response can be divided into following steps:

Step 1: When a user request for a website via web browser, the resolver checks the local resolver cache in the system’s memory to see if it contains the IP address entry for the domain. The entry would be there if it has been requested for the same since the last time it was powered on, and the Time to live has not been exceeded. Time to live attribute on cache record is used to expire the entry after some time. Suppose that the entry is found in local resolver cache, now it replies with the IP address.

Step 2: If no entry has been found, the resolver sends a query to the internal DNS server for the IP.

Step 3: When the DNS server receives the query, it first checks if it has entry for the domain which is requested. If it has, the server performs a lookup in its internal zone table. Suppose it gets in its record.

Step 4: The IP address of the domain is returned to the system’s resolver.

Step 5: The resolved domain name and IP address are placed into the resolver cache. The IP address is used to contact the website.

When a request packet is sent to the DNS, it contains the domain name and a unique transaction ID. This unique transaction ID is the only part of data which is used to authenticate the valid source. When a system gets the response from the DNS, it checks for IP address, port number and unique transaction ID. If these are the same as it was expecting, the response it taken as authenticated. But on the internet, packets can be easily be spoofed and data values can be changed.

How to see the client resolver cache of system:

In windows follow these steps to see the local client resolver cache information stored on system

Step 1: Go to start and run.

Step 2: Type CMD and press Enter. It will open Command Prompt

(one can also open command prompt by start All Programs > Accessories > Command Prompt)

Step 3: Type ipconfig /displaydns (Ex: c:/> ipconfig /displaydns)

It will give you a list of Windows IP configuration which includes entries preloaded from the local Hosts file, as well as any recently obtained resource records for name queries resolved by the system.

These are the information which is used to resolve frequently queried names before sending queries DNS servers.

DNS cache poisoning Attack: DNS cache poisoning attack is the practice of changing or adding false records in the resolver caches, so that a DNS query for a domain returns an IP added by attacker other than the original IP address of the website. This attack can be performed either on the client or the server. Most successful attack adds false records on the resolver cache of both (client and server).

Suppose a computer system sends a request to DNS to get the IP address of a website www.abc.com. But an attacker has managed to know the transaction ID of the request and respond with a spoofed packet with the same transaction ID but false IP address before the DNS response. In this case, firstly system will get the response of attacker. So the system will redirect to a false IP other than the original IP address of the website www.abc.com.

Figure 3: Attacker’s response before DNS

Now see how this attack is performed in real time:

Step 1: The resolver checks the resolver cache in the system’s memory to see the entry for the domain www.abc.com.

Step 2: If there is no entry in resolver cache, the resolver sends a request to the DNS server.

Step 3: When the DNS server receives the request, it first checks to see if it’s authoritative (because a DNS for .in domains cannot server for the request made for .com domain). If it is not authoritative for www.abc.com, it will look for its local cache for the entry of www.abc.com exists. If it does not then it will send the request to another DNS for the IP of the domain.

Step 4: Suppose an attacker wants to poison the internal cache of DNS, he will try to get the transaction ID. Once he gets the transaction ID, he can respond to the DNS query from his fake DNS server with a rogue IP. Most of the attackers use DDOS attack on authoritative servers. While the authoritative server struggles to deal with the attack, the attacker’s DNS server has time to determine the transaction ID. After getting the transaction ID, attacker can respond to the DNS with a rogue IP for www.abc.com.

Step 5: The rogue IP address for abc.com is added to DNS cache and returned to the requesting system too.

Step 6: At the system this rogue IP is added to the resolver cache and system’s browser is navigated to the IP address, sent by the attacker.

In The above example, attacker used DDOS attack on authoritative server to respond on behalf of it. But attacker can also use other methods to perform this attack.

Attacker will send a query request to DNS about a domain which is controlled by attacker. The nameservers of the attacker’s domain will reply to DNS query about the domain name requested along with the additional information about the domain (suppose www.abc.com) for which attacker want to poison the cache. If the DNS is vulnerable to the caching extra information sent in a query response, attacker would be able to poison the cache of DNS with rogue IP address. This will again poison client’s systems cache who will request for this domain (www.abc.com). This attack is simpler than I have explained in the above steps where attacker used DDOS.

There are so many other ways and you can also think how you can fool a DNS by studying how it implements security. Then you can try to break the security mechanisms.

Why attacker uses DNS cache poisoning to send a user to rogue ip address: Once the system’s and Domain Name server’s cache is poisoned with a rogue IP address, the user will redirect to a wrong website. In the examples I have shown above, the system’s cache is poisoned for www.abc.com. So user will not be able to access the original website. Now attacker can do following things with this attack.

Phishing attack: User will create a fake website which will be identical to www.abc.com. When user will try to access www.abc.com , he will be sent to fake website hosted by attacker. Suppose the website is a bank website, attacker can easily get the login information of users. If the cache of DNS is poisoned, all the users connoting to the DNS will be sent to the fake phishing website.

Man in the middle attack: This attack is also useful in performing MIM (Man in the Middle) attack. When a system initiates a session with the attacker’s server, attacker’s server can initiate a session with original website. In this way all the information passed from the system to original website will be visible to attacker.

Malware distribution: Many times, this attack is used to distribute malware to users. Malware is uploaded to the fake website and will be downloaded to all the visitors. This is the best way to distribute malware. Attacker can distribute his malware in bulk. In classical way of malware uploading and waiting for a victim to come and download is not effective. It also takes too much time.

How to prevent this attack

This attack is mostly done while a DNS request to other DNS. So this attack can be prevented on DNS by less trusting on information sent by other DNS servers. The most basic defense against this attack is use of latest version of DNS. Latest DNS uses port randomization with transaction ID so it’s hard for attacker to guess for the port. DNS based on BIND 9.5.0 or above perform these checks. Transaction ID is also cryptographically secure which reduce the probability of attack. But BIND version must be hidden within the query packets

Remove unnecessary services running on the DNS servers. Attackers can use these unnecessary services to attack on DNS.

Recursive queries should be limited and DNS should only store information about the domain it has requested. It must be configured not to add additional domains information in a query response. Most of the DNS servers are vulnerable to this attack.

DNSSEC: DNSSEC (Domain Name System Security Extension) is developed by Internet Engineering Task Force (IETF) which is an extension to DNS to provide a secure authentication of DNS data. It is designed to protect resolvers from DNS forging. This suit is mainly designed to prevent DNS cache poisoning. But DNSSEC does not provide confidentiality of data so DNSSEC responses are authenticated not encrypted.

Conclusion: DNS cache poisoning is a large risk for all those organizations which are still using older version of DNS. In recent mass bank account hacking cyber crimes, attackers use DNS cache poisoning to redirect bank users to their phishing website. Every year, this attack causes million dollar loss to bank users. So careful use of latest DNS and DNSSEC can prevent this attack and help in creating secure internet. DNS server must be configured properly. This is the main cause of unsecure DNS servers.

Sursa: http://resources.infosecinstitute.com/dns-cache-poisoning/

[Cheater]

DNSSEC is the best!

Folosesc de mult, dar partea mai putin buna, daca providerul clientului are serverele dns cu soft invechit, nu iti rezolva siteul. Este posibil acelasi lucru daca ai os ff vechi ca user.