DNS Cache Poisoning- Part 5

Hey awl in diz tut i will be telling you all about DNS Cache Poisoning.

 

What is DNS Cache Poisoning

DNS cache poisoning consists of changing or adding records in the resolver caches, either on the client or the server, so that a DNS query for a domain returns an IP address for an attacker’s domain instead of the intended domain.

Ok so now i will be providing basic and brief idea about DNS Cache Poisoning in step by step process.



Step 1: The resolver checks the resolver cache in the workstation’s memory to see if it contains an entry for Farpoint.companyA.com.

 Step 2: Having found no entry in the resolver cache, the resolver sends a resolution request to the internal DNS server.  

Step 3: When the DNS server receives the request, it first checks to see if it’s authoritative.If it founded then its ok and if not then the next action it takes is to check its local cache to see if an entry for target .com exists. If it does then ok anf if not thenthe  internal DNS server begins the process of iteratively querying external DNS servers until it either resolves the domain name or it reaches a point at which it’s clear that the domain name entry doesn’t exist

. Step 4: A request is sent to one of the Internet root servers. The root server returns the address of a server authoritative for the .COM Internet space.

 Step 5: A request is sent to the authoritative server for .COM. The address of a DNS server authoritative for the target.com domain is returned.

 Step 6: A request is sent to the authoritative server for target.com. This is identical to the standard process for an iterative query – with one exception. A cracker has decided to poison the internal DNS server’s cache. In order to intercept a query and return malicious information, the cracker must know the transaction ID. Once the transaction ID is known, the attacker’s DNS server can respond as the authoritative server for target.com. Although this would be a simple matter with older DNS software (e.g. BIND 4 and earlier), newer DNS systems have build-in safeguards. In our example, the transaction ID used to identify each query instance is randomized. But figuring out the transaction ID is not impossible. All that’s required is time. To slow the response of the real authoritative server, our cracker uses a botnet to initiate a Denial of Service (DoS) attack. While the authoritative server struggles to deal with the attack, the attacker’s DNS server has time to determine the transaction ID. Once the ID is determined, a query response is sent to the internal DNS server. But the IP address for target.com in the response is actually the IP address of the attacker’s site. The response is placed into the server’s cache.

 Step 7: The rogue IP address for Farpoint is returned to the client resolver.

 Step 8: An entry is made in the resolver cache, and a session is initiated with the attacker’s site. At this point, both the workstation’s cache and the internal DNS server’s cache are poisoned. Any workstation on the internal network requesting resolution of target.com will receive the rogue address listed in the internal DNS server’s cache. This continues until the entry is deleted.