Continuing our look at man-in-the-middle attacks, focusing this time on another type of MITM attack called DNS spoofing.
Introduction
In the first installment of this series we reviewed normal ARP communication and how the ARP cache of a device can be poisoned in order to redirect machines network traffic through a another machine with possible malicious intent. This seemingly advanced man-in-the-middle (MITM) attack known as ARP Cache Poisoning is done easily with the right software. In this article we will discuss a similar type of MITM attack called DNS Spoofing. If you have not read the previous article on ARP Cache Poisoning then I would recommend doing so now, as this article builds upon techniques learned in that article.
DNS Spoofing
DNS spoofing is a MITM technique used to supply false DNS information to a host so that when they attempt to browse, for example, www.bankofamerica.com at the IP address XXX.XX.XX.XX they are actually sent to a fake www.bankofamerica.com residing at IP address YYY.YY.YY.YY which an attacker has created in order to steal online banking credentials and account information from unsuspecting users. This is actually done quite easily and here we will see how it works, how it is done, and how to defend against it.
Normal DNS Communication
The Domain Naming System (DNS) protocol as defined in RFC 1034/1035 is what some consider one of the most important protocols in use by the Internet. This is because DNS is the proverbial molasses that holds the bread together. In a nutshell, whenever you type in a web address such as http://www.google.com into your browser, a DNS request is made to a DNS server in order to find out what IP address that name resolves to. This is because routers and the devices that interconnect the Internet do not understand google.com, they only understand addresses such as 74.125.95.103.
A DNS server itself works by storing a database of entries (called resource records) of IP address to DNS name mappings, communicating those resource records to clients, and communicating those resource records to other DNS servers. The architecture of DNS servers throughout enterprises and the Internet is something that can be a bit complicated. As a matter of fact, there are whole books dedicated to DNS architecture. We will not cover architectural aspects or even all of the different types of DNS traffic (you can review the various DNS related RFC’s here), but we will look at a basic DNS transaction, seen in Figure 1.
Figure 1: A DNS Query and Response
DNS functions in a query/response type format. A client wishing to resolve a DNS name to an IP address sends a query to a DNS server, and the server sends the requested information in its response. From the clients’ perspective, the only two packets that are seen are this query and response.
Figure 2: DNS Query and Response Packets
This scenario gets a slight bit more complex when you consider DNS recursion. Due to the hierarchical nature of the DNS structure of the Internet, DNS servers need the ability to communicate with each other in order to locate answers for the queries submitted by clients. After all, it might be fair to expect our internal DNS server to know the name to IP address mapping of our local intranet server, but we can’t expect it to know the IP address correlated with Google or Dell. This is where recursion comes into play. Recursion is when one DNS server queries another DNS server on behalf of a client who has made a request. Basically, this turns a DNS server into a client itself, seen in Figure 3.
Figure 3: A DNS Query and Response Using Recursion
Spoofing DNS
There is more than one way to skin a cat and there is definitely more than one method available for performing DNS spoofing. We will be using a technique called DNS ID spoofing.
Every DNS query that is sent out over the network contains a uniquely generated identification number that’s purpose is to identify queries and responses and tie them together. This means that if our attacking computer can intercept a DNS query sent out from a target device, all we have to do is create a fake packet that contains that identification number in order for that packet to be accepted by that target.
We will complete this process doing two steps with a single tool. First, we will ARP cache poison the target device to reroute its traffic through our attacking host so that we can intercept the DNS request, and then we will actually send the spoofed packet. The goal of this scenario is to get users on the target network to visit our malicious website rather than the website they are attempting to access. A depiction of this attack is seen in Figure 4.
Figure 4: The DNS Spoofing Attack Using the DNS ID Spoofing Method
There are a few different tools available that can be used to perform DNS spoofing. We will be using Ettercap, which has both Windows and Linux versions. You can download Ettercap from here. If you do a bit of research on this website you will find that Ettercap has a great deal of functionality beyond DNS spoofing and is commonly used in many types of MITM attacks.
If you are installing Ettercap on a Windows machine you will notice it has a GUI which works great, but for this example we will be using the command-line interface.
Prior to executing Ettercap, a bit of configuration is required. Ettercap at its core is a packet sniffer which utilizes various plug-in to do the various attacks it can perform. The dns_spoof plug-in is what will be doing the attack in this example, so we have to modify the configuration file associated with that plug-in. On a windows system, this file can be located at C:\Program Files (x86)\EttercapNG\share\etter.dns, and at /usr/share/ettercap/etter.dns. This file is fairly simple and contains the DNS records you wish to spoof. For our purposes, we would like any user attempting to go to yahoo.com to be directed to a host on the local network, so we will add the entry highlighted in Figure 5.
Figure 5: Adding a spoofed DNS record to etter.dns
These entries basically tell the dns_spoof plug-in that when it sees a DNS query for yahoo.com or www.yahoo.com (for an A type resource record) it should supply the IP address 172.16.16.100 in response. In a realistic scenario the device at 172.16.16.100 would be running some form of web server software that would present the user with the fake website.
Once the file is configured and saved we are free to execute the command string that will launch the attack. The command string uses the following options:
-T – Specifies the use of the text-based interface
-q – Runs commands in quiet mode so that captured packets are not output to the screen
-P dns_spoof – Specifies the use of the dns_spoof plug-in
-M arp – Initiates a MITM Arp poisoning attack to intercept packets between hosts
// // - Specifies the entire network as the targets of the attack
The final command string for our purposes would be:
Ettercap.exe –T –q –P dns_spoof –M arp // //
Running the command would begin the two phased attack, first poisoning the ARP cache of the devices on the network and then transmitting the fake DNS query responses.
Figure 6: Ettercap actively listening for DNS queries
Once initiated, anybody attempting to access www.yahoo.com is redirected to our malicious site.
Figure 7: The result of the DNS spoofing attempt from the users perspective
Defending Against DNS Spoofing
DNS spoofing is difficult to defend against due to the attacks being mostly passive by nature. Typically, you will never know your DNS is being spoofed until it has happened. What you get is a webpage that is different than what you are expecting. In very targeted attacks it is very possible that you may never know that you have been tricked into enter your credentials into a false site until you receive a call from you bank wondering why you have just purchased a new boat off the shore of Greece. That being said, there are still a few things that can be done to defend against these types of attacks:
Secure your internal machines: Attacks like these are most commonly executed from inside the network. If your network devices are secure then there is less of a chance of those compromised hosts being used to launch a spoofing attack.
Don’t rely on DNS for secure systems: On highly sensitive and secure systems that you typically won’t be browsing the Internet on its often a best practice to not use DNS. If you have software that relies on hostnames to function then those can be specified manually in the devices hosts file.
Use IDS: An intrusion detection system, when placed and deployed correctly, can typically pick up on most forms of ARP cache poisoning and DNS spoofing.
Use DNSSEC: DNSSEC is a newer alternative to DNS that uses digitally signed DNS records to ensure the validity of a query response. DNSSEC is not yet in wide deployment but has been widely accepted as “the future of DNS”. This is so much so that the United States DOD has mandated that all MIL and GOV domains begin using DNSSEC within the next year. You can read more about DNSSEC here.
Source: http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-Part2.html
thanks !!
Introduction
In the first installment of this series we reviewed normal ARP communication and how the ARP cache of a device can be poisoned in order to redirect machines network traffic through a another machine with possible malicious intent. This seemingly advanced man-in-the-middle (MITM) attack known as ARP Cache Poisoning is done easily with the right software. In this article we will discuss a similar type of MITM attack called DNS Spoofing. If you have not read the previous article on ARP Cache Poisoning then I would recommend doing so now, as this article builds upon techniques learned in that article.
DNS Spoofing
DNS spoofing is a MITM technique used to supply false DNS information to a host so that when they attempt to browse, for example, www.bankofamerica.com at the IP address XXX.XX.XX.XX they are actually sent to a fake www.bankofamerica.com residing at IP address YYY.YY.YY.YY which an attacker has created in order to steal online banking credentials and account information from unsuspecting users. This is actually done quite easily and here we will see how it works, how it is done, and how to defend against it.
Normal DNS Communication
The Domain Naming System (DNS) protocol as defined in RFC 1034/1035 is what some consider one of the most important protocols in use by the Internet. This is because DNS is the proverbial molasses that holds the bread together. In a nutshell, whenever you type in a web address such as http://www.google.com into your browser, a DNS request is made to a DNS server in order to find out what IP address that name resolves to. This is because routers and the devices that interconnect the Internet do not understand google.com, they only understand addresses such as 74.125.95.103.
A DNS server itself works by storing a database of entries (called resource records) of IP address to DNS name mappings, communicating those resource records to clients, and communicating those resource records to other DNS servers. The architecture of DNS servers throughout enterprises and the Internet is something that can be a bit complicated. As a matter of fact, there are whole books dedicated to DNS architecture. We will not cover architectural aspects or even all of the different types of DNS traffic (you can review the various DNS related RFC’s here), but we will look at a basic DNS transaction, seen in Figure 1.
DNS functions in a query/response type format. A client wishing to resolve a DNS name to an IP address sends a query to a DNS server, and the server sends the requested information in its response. From the clients’ perspective, the only two packets that are seen are this query and response.
This scenario gets a slight bit more complex when you consider DNS recursion. Due to the hierarchical nature of the DNS structure of the Internet, DNS servers need the ability to communicate with each other in order to locate answers for the queries submitted by clients. After all, it might be fair to expect our internal DNS server to know the name to IP address mapping of our local intranet server, but we can’t expect it to know the IP address correlated with Google or Dell. This is where recursion comes into play. Recursion is when one DNS server queries another DNS server on behalf of a client who has made a request. Basically, this turns a DNS server into a client itself, seen in Figure 3.
Spoofing DNS
There is more than one way to skin a cat and there is definitely more than one method available for performing DNS spoofing. We will be using a technique called DNS ID spoofing.
Every DNS query that is sent out over the network contains a uniquely generated identification number that’s purpose is to identify queries and responses and tie them together. This means that if our attacking computer can intercept a DNS query sent out from a target device, all we have to do is create a fake packet that contains that identification number in order for that packet to be accepted by that target.
We will complete this process doing two steps with a single tool. First, we will ARP cache poison the target device to reroute its traffic through our attacking host so that we can intercept the DNS request, and then we will actually send the spoofed packet. The goal of this scenario is to get users on the target network to visit our malicious website rather than the website they are attempting to access. A depiction of this attack is seen in Figure 4.
There are a few different tools available that can be used to perform DNS spoofing. We will be using Ettercap, which has both Windows and Linux versions. You can download Ettercap from here. If you do a bit of research on this website you will find that Ettercap has a great deal of functionality beyond DNS spoofing and is commonly used in many types of MITM attacks.
If you are installing Ettercap on a Windows machine you will notice it has a GUI which works great, but for this example we will be using the command-line interface.
Prior to executing Ettercap, a bit of configuration is required. Ettercap at its core is a packet sniffer which utilizes various plug-in to do the various attacks it can perform. The dns_spoof plug-in is what will be doing the attack in this example, so we have to modify the configuration file associated with that plug-in. On a windows system, this file can be located at C:\Program Files (x86)\EttercapNG\share\etter.dns, and at /usr/share/ettercap/etter.dns. This file is fairly simple and contains the DNS records you wish to spoof. For our purposes, we would like any user attempting to go to yahoo.com to be directed to a host on the local network, so we will add the entry highlighted in Figure 5.
These entries basically tell the dns_spoof plug-in that when it sees a DNS query for yahoo.com or www.yahoo.com (for an A type resource record) it should supply the IP address 172.16.16.100 in response. In a realistic scenario the device at 172.16.16.100 would be running some form of web server software that would present the user with the fake website.
Once the file is configured and saved we are free to execute the command string that will launch the attack. The command string uses the following options:
-T – Specifies the use of the text-based interface
-q – Runs commands in quiet mode so that captured packets are not output to the screen
-P dns_spoof – Specifies the use of the dns_spoof plug-in
-M arp – Initiates a MITM Arp poisoning attack to intercept packets between hosts
// // - Specifies the entire network as the targets of the attack
The final command string for our purposes would be:
Ettercap.exe –T –q –P dns_spoof –M arp // //
Running the command would begin the two phased attack, first poisoning the ARP cache of the devices on the network and then transmitting the fake DNS query responses.
Once initiated, anybody attempting to access www.yahoo.com is redirected to our malicious site.
Defending Against DNS Spoofing
DNS spoofing is difficult to defend against due to the attacks being mostly passive by nature. Typically, you will never know your DNS is being spoofed until it has happened. What you get is a webpage that is different than what you are expecting. In very targeted attacks it is very possible that you may never know that you have been tricked into enter your credentials into a false site until you receive a call from you bank wondering why you have just purchased a new boat off the shore of Greece. That being said, there are still a few things that can be done to defend against these types of attacks:
Secure your internal machines: Attacks like these are most commonly executed from inside the network. If your network devices are secure then there is less of a chance of those compromised hosts being used to launch a spoofing attack.
Don’t rely on DNS for secure systems: On highly sensitive and secure systems that you typically won’t be browsing the Internet on its often a best practice to not use DNS. If you have software that relies on hostnames to function then those can be specified manually in the devices hosts file.
Use IDS: An intrusion detection system, when placed and deployed correctly, can typically pick up on most forms of ARP cache poisoning and DNS spoofing.
Use DNSSEC: DNSSEC is a newer alternative to DNS that uses digitally signed DNS records to ensure the validity of a query response. DNSSEC is not yet in wide deployment but has been widely accepted as “the future of DNS”. This is so much so that the United States DOD has mandated that all MIL and GOV domains begin using DNSSEC within the next year. You can read more about DNSSEC here.
Source: http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-Part2.html
thanks !!
No comments:
Post a Comment