A very popular topic for discussion in "Information Security" :
Download this whole article as PDF Guide : Download now
DNS Cache Poisoning
What is exactly DNS Poisoning?.. to study this we would first require to know little bit about DNS i.e Domain Name System.Firstly, let us have a brief look at DNS and then move to the main problem
What is Domain Name System?
In the world of the Internet and TCP/IP, IP addresses are used to route packets from source to destination. A single IP address, for example 203.192.135.234, is not difficult to remember. But trying to learn or track thousands of these addresses, including which server/node is associated with each address, is a daunting task. So instead, we use domain names to refer to systems with which we want to communicate
Let us take a real world example :
When you enter the "Google.com" into the address bar of your browser, the Google page appears. This is because your PC executed a process to resolve Google.com to an IP address. Only by having the IP address is a system able to initiate a session with another system across the Internet.
In simple terms what I mean to say is :
Whether you try
or you try :
both will deliver the same results ... if you try www.google.com then your browser resolves the appropriate ip address for the page by looking up into the DNS table which is just like an index and then process your request and display the page on your browser.
Now that we have a good idea how DNS is supposed to work, it’s time to look at how this process can be used to co-opt one or more DNS caches.
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.
To demonstrate how this might work, let’s step through Figure below
Figure : DNS Cache Poisoning
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. In this case, it isn’t authoritative for companyA.com. The next action it takes is to check its local cache to see if an entry for Farpoint.companyA.com exists. It doesn’t. So in Step 4 the 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 companyA.com domain is returned.
Step 6: A request is sent to the authoritative server for companyA.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 companyA.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 Farpoint.companyA.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 Farpoint.companyA.com will receive the rogue address listed in the internal DNS server’s cache. This continues until the entry is deleted.
Another method used to poison a DNS cache is the use of a recursive query sent by the attacker. The query can force the target server to connect to the authoritative source of the domain in the query. Once connected, rogue information about one or more domains might be sent to the querying server and posted to the server’s cache.
There are other methods attackers use to poison DNS caches, but the objective is the same.
Now we’ll explore the consequences of using a poisoned DNS cache
Potential Consequences of Cache Poisoning
Identity Theft
Once an attacker gets you to his site, he’ll try to trick you into leaving behind information he can use to impersonate you. One way to do this in our first example is to create a site identical to the real Farpoint.companyA.com. When the user connects using the poisoned cache information, she might be fooled into entering information about herself through apparently legitimate requests for her name, social security number, address, etc.
Distribution of Malware
Another of objective of attackers using cache poisoning is the automatic distribution of malware. Instead of releasing malicious code into the Internet and realizing random results, the use of rogue IP addresses to redirect unsuspecting users to the attacker’s site can be a more focused attack vector. Once a workstation initiates a session with the malicious site, malware is uploaded to the workstation without intervention by or the knowledge of the user.
Dissemination of False Information
This aspect of pharming is useful to attackers who want to spread self-serving information about an organization. It’s also been used to manipulate stock prices in an attempt to realize a large profit.
Man-in-the-middle Attack
In this attack type, the workstation initiates a session with the attacker’s server. The attacker’s server initiates a session with the actual target site. All information flowing between the workstation and the genuine site passes through and is intercepted by the cracker’s server.
There can be serious consequences when security is an afterthought during the configuration and deployment of DNS servers. The next section provides guidelines that can help prevent cache poisoning.
Explanation of DNS Cache Poisoning
Download this whole article as PDF Guide : Download now
DNS Cache Poisoning
What is exactly DNS Poisoning?.. to study this we would first require to know little bit about DNS i.e Domain Name System.Firstly, let us have a brief look at DNS and then move to the main problem
What is Domain Name System?
In the world of the Internet and TCP/IP, IP addresses are used to route packets from source to destination. A single IP address, for example 203.192.135.234, is not difficult to remember. But trying to learn or track thousands of these addresses, including which server/node is associated with each address, is a daunting task. So instead, we use domain names to refer to systems with which we want to communicate
Let us take a real world example :
When you enter the "Google.com" into the address bar of your browser, the Google page appears. This is because your PC executed a process to resolve Google.com to an IP address. Only by having the IP address is a system able to initiate a session with another system across the Internet.
In simple terms what I mean to say is :
Whether you try
Now that we have a good idea how DNS is supposed to work, it’s time to look at how this process can be used to co-opt one or more DNS caches.
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.
To demonstrate how this might work, let’s step through Figure below
Figure : DNS Cache Poisoning
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. In this case, it isn’t authoritative for companyA.com. The next action it takes is to check its local cache to see if an entry for Farpoint.companyA.com exists. It doesn’t. So in Step 4 the 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 companyA.com domain is returned.
Step 6: A request is sent to the authoritative server for companyA.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 companyA.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 Farpoint.companyA.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 Farpoint.companyA.com will receive the rogue address listed in the internal DNS server’s cache. This continues until the entry is deleted.
Another method used to poison a DNS cache is the use of a recursive query sent by the attacker. The query can force the target server to connect to the authoritative source of the domain in the query. Once connected, rogue information about one or more domains might be sent to the querying server and posted to the server’s cache.
There are other methods attackers use to poison DNS caches, but the objective is the same.
Now we’ll explore the consequences of using a poisoned DNS cache
Potential Consequences of Cache Poisoning
Identity Theft
Once an attacker gets you to his site, he’ll try to trick you into leaving behind information he can use to impersonate you. One way to do this in our first example is to create a site identical to the real Farpoint.companyA.com. When the user connects using the poisoned cache information, she might be fooled into entering information about herself through apparently legitimate requests for her name, social security number, address, etc.
Distribution of Malware
Another of objective of attackers using cache poisoning is the automatic distribution of malware. Instead of releasing malicious code into the Internet and realizing random results, the use of rogue IP addresses to redirect unsuspecting users to the attacker’s site can be a more focused attack vector. Once a workstation initiates a session with the malicious site, malware is uploaded to the workstation without intervention by or the knowledge of the user.
Dissemination of False Information
This aspect of pharming is useful to attackers who want to spread self-serving information about an organization. It’s also been used to manipulate stock prices in an attempt to realize a large profit.
Man-in-the-middle Attack
In this attack type, the workstation initiates a session with the attacker’s server. The attacker’s server initiates a session with the actual target site. All information flowing between the workstation and the genuine site passes through and is intercepted by the cracker’s server.
There can be serious consequences when security is an afterthought during the configuration and deployment of DNS servers. The next section provides guidelines that can help prevent cache poisoning.
Explanation of DNS Cache Poisoning
Example of DNS Posioning Attack
0 comments:
Post a Comment