Understanding Man-in-the-Middle Attacks

[patris1]

http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-Part1.html

Part1: ARP Cache Poisoning


The first part of an article series on some of the most widely used forms of MITM attacks, including ARP Cache Poisoning, DNS Spoofing, HTTP session hijacking, passing the hash and more.


Introduction

One of the most prevalent network attacks used against individuals and large organizations alike are man-in-the-middle (MITM) attacks. Considered an active eavesdropping attack, MITM works by establishing connections to victim machines and relaying messages between them. In cases like these, one victim believes it is communicating directly with another victim, when in reality the communication flows through the host performing the attack. The end result is that the attacking host can not only intercept sensitive data, but can also inject and manipulate a data stream to gain further control of its victims.
In this series of articles we will examine some of the most widely used forms of MITM attacks including ARP cache poisoning, DNS spoofing, HTTP session hijacking, passing the hash, and more. As you will mostly find in the real world, most victim machines are Windows-based hosts. That being the case, this series of articles will focus entirely on MITM exploitation of hosts running versions of Windows. When possible, attacks will also be performed from Windows based hosts. In cases when there are no tools available for the attack being presented we will be utilizing Backtrack Linux 4, downloadable as a live-CD or a virtual machine from here.
ARP Cache Poisoning

In the first article of this series we will take a look at ARP cache poisoning. One of the oldest forms of modern MITM attack, ARP cache poisoning (sometimes also known as ARP Poison Routing) allows an attacker on the same subnet as its victims to eavesdrop on all network traffic between the victims. I’ve deliberately chosen this as the first attack to examine because it is one of the simplest to execute but is considered one of the most effective once implemented by attackers.
Normal ARP Communication

The ARP protocol was designed out of necessity to facilitate the translation of addresses between the second and third layers of the OSI model. The second layer, or data-link layer, uses MAC addresses so that hardware devices can communicate to each other directly on a small scale. The third layer, or network layer, uses IP addresses (most commonly) to create large scalable networks that can communicate across the globe. The data link layer deals directly with devices connected together where as the network layer deals with devices that are directly connected AND indirectly connected. Each layer has its own addressing scheme, and they must work together in order to make network communication happen. For this very reason, ARP was created with RFC 826, “An Ethernet Address Resolution Protocol”.

Figure 1: The ARP Communication Process
The nitty gritty of ARP operation is centered around two packets, an ARP request and an ARP reply. The purpose of the request and reply are to locate the hardware MAC address associated with a given IP address so that traffic can reach its destination on a network. The request packet is sent to every device on the network segment and says “Hey, my IP address is XX.XX.XX.XX, and my MAC address is XX:XX:XX:XX:XX:XX. I need to send something to whoever has the IP address XX.XX.XX.XX, but I don’t know what their hardware address is. Will whoever has this IP address please respond back with their MAC address?” The response would come in the ARP reply packet and effectively provide this answer, “Hey transmitting device. I am who you are looking for with the IP address of XX.XX.XX.XX. My MAC address is XX:XX:XX:XX:XX:XX.” Once this is completed the transmitting device will update its ARP cache table and the devices are able to communicate with one another.
Poisoning the Cache

ARP cache poisoning takes advantage of the insecure nature of the ARP protocol. Unlike protocols such as DNS that can be configured to only accept secured dynamic updates, devices using ARP will accept updates at any time. This means that any device can send an ARP reply packet to another host and force that host to update its ARP cache with the new value. Sending an ARP reply when no request has been generated is called sending a gratuitous ARP. When malicious intent is present the result of a few well placed gratuitous ARP packets used in this manner can result in hosts who think they are communicating with one host, but in reality are communicating with a listening attacker.

Figure 2: Intercepting Communication with ARP Cache Poisoning
Using Cain & Abel

Let us take the given scenario and take it from theory to reality. There are a few different tools that will perform the necessary steps to poison the ARP cache of victim machines. We will use the popular security tool Cain & Abel from Oxid.it. Cain & Abel does quite a few things beyond ARP cache poisoning and is a very useful tool to have in your arsenal. The installation of the tool is pretty clear cut so I won’t go through that here.
Before beginning you need to collect some additional information. This includes the network interface you wish you to use for the attack, and the two IP addresses of your communicating victims.
When you first open Cain & Abel, you will notice a series of tabs near the top of the window. For our purposes, we’ll be working in the Sniffer tab. When you click this tab, you will see an empty table. In order to fill this table you will need to activate the program’s built-in sniffer and scan your network for hosts.

Figure 3: Cain and Abel’s Sniffer Tab
Click the second icon on the toolbar, which resembles a network card. The first time you do this you will be asked to select the interface you wish to sniff. This interface should be the one that is connected to the network you will be performing your ARP cache poisoning on. Once you’ve selected this interface, click OK to activate Cain & Abel’s built-in sniffer. At this point the toolbar icon resembling a network card should be depressed. If it isn’t, do so now. To build a list of available hosts on your network, click the icon that resembles a plus (+) symbol on the main toolbar, and click OK.

Figure 4: Scanning for Hosts
The once-empty grid should now be filled with a list of all the hosts on your attached network, along with their MAC addresses, IP addresses, and vendor identifying information. This is the list you will work from when setting up your ARP cache poisoning.
At the bottom of the program window, you will see a set of tabs that will take you to other windows under the Sniffer heading. Now that you have built your host list, you will be working from the APR tab. Switch to the APR window by clicking the tab.
Once in the APR window, you are presented with two empty tables: an upper and a lower one. Once you set them up, the upper table will show the devices involved in your ARP cache poisoning, and the lower table will show all communication between your poisoned machines.
Continue setting up your ARP poisoning by clicking the icon resembling the plus (+) symbol on the program’s standard toolbar. The window that appears has two selection columns side by side. On the left side, you will see a list of all available hosts on your network. Click the IP address of one of your victims. This will result in the right window showing a list of all hosts in the network, omitting the IP address you just selected. In the right window, click the IP address of the other victim, and click OK.

Figure 5: Selecting Victim Hosts for Poisoning
The IP addresses of both devices should now be listed in the upper table in the main application window. To complete the process, click the yellow-and-black radiation symbol on the standard toolbar. This will activate Cain & Abel’s ARP cache poisoning features and allow your analyzing system to be the middleman for all communications between the two victims. If you are curious to see what is happening behind the scenes try installing Wireshark and listen to the interface when you enable poisoning. You will see a flurry of ARP traffic to both hosts and immediately begin seeing the communication between them.

Figure 6: ARP Traffic Injection
When you are finished, simply click the yellow-and-black radiation symbol again to stop ARP cache poisoning.
Defending Against ARP Cache Poisoning


Looking at ARP cache poisoning from the defenders standpoint we are at a bit of a disadvantage. The ARP process happens in the background with very little ability to be controlled directly by us. There is no catch all solution, but proactive and reactive stances can be taken if you are concerned about ARP cache poisoning on your network.
Securing the LAN


ARP Cache Poisoning is only a viable attack technique when attempting to intercept traffic between two hosts on the same local area network. The only reason you would have to fear this is if a local device on your network has been compromised, a trusted user has malicious intent, or someone has managed to plug an un-trusted device into the network. Although we too often focus the entirety of our security efforts on the network perimeter, defending against internal threats and having a good internal security posture can help eliminate the fear of the attack mentioned here.
Hard Coding the ARP Cache


One way to protect against the unsecured dynamic nature of ARP requests and replies is to make the process a little less…dynamic. This is an option because Windows-based hosts allow for the addition of static entries into the ARP cache. You can view the ARP cache of a Windows host by opening a command prompt and type the command arp –a.

Figure 7: Viewing the ARP Cache
You can add entries to this list by using the command, arp –s <IP ADDRESS> <MAC ADDRESS>.
In cases where your network configuration does not change often, it is entirely feasible to make a listing of static ARP entries and deploy them to clients via an automated script. This will ensure that devices will always rely on their local ARP cache rather than relying on ARP requests and replies.
Monitoring ARP Traffic with a Third Party Program


The last option for defending against ARP cache poisoning is a reactive approach that involves monitoring the network traffic of hosts. This can be done with a few different intrusion detection systems (such as Snort) or through downloadable utilities designed specifically for this purpose (such as xARP). This may be feasible when you are only concerned about a single host, but can be a bit cumbersome to deal with when concerned with entire network segments.
Wrap Up


ARP Cache Poisoning is a great introduction into the world of passive man-in-the-middle attacks because it’s very simple to execute, is a very real threat on modern networks, and is difficult to detect and defend against. In the next article in this series we will focus on name resolution and the concept of DNS spoofing

---

موضوعات مشابه:

• stop DoS attacks
• معرفی SQL Injection Attacks و نحوه پیشگیری از آن
• 200+ Attacks blocked and more!

---

[patris1]

http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-Part2.html

Part2: DNS Spoofing


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 Google 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 Yahoo! (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 Yahoo! 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.

Wrap Up


DNS Spoofing is a very lethal form of a MITM attack when paired with the right skill level and malicious intent. Using this technique we can utilize phishing techniques to deceptively steal credentials, install malware with a drive-by exploit, or even cause a denial of service condition. In the next article in this series we will look at “pass the hash” attacks and how they can be used to login to Windows-based computers without known credentials

[patris1]

http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-Part3.html

Part 3: Session Hijacking


Taking a look at session hijacking; the theory behind it and a demonstration of it in practice, discussing its detection and prevention tips.


Introduction

In the first two articles of this series on man-in-the-middle attacks we examined ARP cache poisoning and DNS spoofing. As we have demonstrated with those examples, MITM attacks are incredibly effective and increasingly hard to detect. In the third part of this article we will examine session hijacking, which is no different. As with the previous two articles I will describe the theory behind session hijacking, demonstrate the technique in practice, and discuss detection and prevention tips.
Session Hijacking


The term session hijacking is thrown around frequently and encompasses a variety of different attacks. In general, any attack that involves the exploitation of a session between devices is session hijacking. When we refer to a session, we are talking about a connection between devices in which there is state. That is, there is an established dialogue in which a connection has been formally set up, the connection is maintained, and a defined process must be used to terminate the connection. When we talk about sessions theoretically it’s a bit confusing, so it may help to think of a session in a more practical sense.
In this article we will be talking about session hijacking through cookie stealing, which involves HTTP sessions. If you think about some of the common websites you visit that require login credentials, those are great examples of session-oriented connections. You must be authenticated by the website with your username and password to formally set up the session, the website maintains some form of session tracking to ensure you are still logged in and are allowed to access resources (often done with a cookie), and when the session is ending the credentials are cleared and the session ends. This is a very specific example of a session and even though we do not always realize it, sessions are occurring constantly and most communications rely on some form of session or state-based activity.

Figure 1: A normal session
As we have seen in previous attacks, nothing that goes across the network is safe and session data is no different. The principle behind most forms of session hijacking is that if you can intercept certain portions of the session establishment, you can use that data to impersonate one of the parties involved in the communication so that you may access session information. In the case of our earlier example, this means that if we were to capture the cookie that is used to maintain the session state between your browser and the website you are logging into, we could present that cookie to the web server and impersonate your connection. If that sounds too good to be true from an attackers standpoint, well….it is.

Figure 2: Session Hijacking
Now that we have a little bit of theory in the books, let us delve into a practical example.
Stealing Cookies with Hamster and Ferret


In our practical scenario we will be performing a session hijacking attack by intercepting the communication of a user logging into his Gmail account. Using this intercepted communication we will impersonate that user and access the account from our attacking machine.
In order to perform this attack we will be using two tools straight out of the pet store, named Hamster and Ferret. Both tools can be downloaded from here. These are both command-line tools so the hamster folder can be extracted to an easy to get to location.
Alternatively, you can download and use Backtrack 4. BT4 is a Linux live-CD distribution designed specifically for hacking and penetration testing that comes with a myriad of preinstalled and precompiled tools, with Hamster/Ferret being two of them. You can download BT4 from here. You will then find Hamster in the /pentest/sniffers/hamster folder. The screenshot examples used in the rest of this tutorial are taken from BT4.
The first step involved in this form of session hijacking is to capture the traffic of the victim user as he browses Facebook. This traffic can actually be captured using any packet sniffing application such as TCPDump or Wireshark, but in order to capture the right packets you will need to employ a technique such as ARP cache poisoning (discussed in the first article in this series).

Figure 3: Capturing traffic of the user browsing to Gmail
Once you have captured the traffic of the victim user browsing to Gmail you will need to save the captured file into the Hamster directory. For the purposes of this example, we have named our file victim_gmail.pcap. When that file is in place, we will use Ferret to process the file. This is done by browsing to the Hamster folder and running the command, ferret –r victim_gmail.pcap. Ferret will process the file and create a hamster.txt file that may be used by Hamster for the actual hijacking of the session.

Figure 4: Processing the capture file with Ferret
With our HTTP data intercepted and prepared for use, we can use Hamster to actually execute the attack. Hamster itself actually runs as a proxy that provides an interface for browsing and using stolen session cookies. In order to start the Hamster proxy you can simply execute Hamster with no command line options.

Figure 5: Starting Hamster
Once executed, you will need to open your browser and configure its proxy settings to match those provided to you by the Hamster output. By default, this means that you would configure your proxy settings to use the local loopback address 127.0.0.1 on port 1234. You can access these settings in Internet Explorer by selecting Tools, Internet Options, Connections, LAN Settings, and placing a checkbox in the Use a proxy server for your LAN box.

Figure 6: Configuring proxy settings for use with Hamster
Now that the proxy settings have been applied you can access the Hamster console in your browser by browsing to http://hamster. Hamster will use the file created by Ferret to produce a list of IP addresses for whom session information has be intercepted and display those IP address in the right pane of the browser. Our file we’ve created only contains a single IP address of the victim, so if we click that the left pane will be populated with the sessions available for hijacking.

Figure 7: The Hamster GUI
We see that facebook.com is listed, and if you click that link you will be pleased to be presented with a new window that has you logged in to the victims Facebook account!

Figure 8: Successfully hijacked Gmail account!
Defending Against Session Hijacking


There are many different forms of session hijacking so the defenses for them can vary. Just like the other MITM attacks we’ve evaluated, session hijacking is difficult to detect and even more difficult to defend against because it’s a mostly passive attack. Unless the malicious user performs some type of obvious action when he accesses the session being hijacked, you may never know that they were there. Here are a few things you can do to better defend against session hijacking:

• Save Online Banking for Home - The chance of somebody intercepting your traffic on your home network is much less than on your work network. This isn’t because your home computer is more secure (let’s face it, its probably less secure), but the simple matter of fact is that if you only have one or two computers at home, the most you have to worry about in terms of session hijacking is if your 14 year old son starts watching hacking videos on YouTube. On a corporate network you don’t know what is going on down the hall or in the branch office 200 miles away, so the potential attack sources multiply. One of the biggest targets for session hijacking is online banking, but this principal applies to anything.
• Be Cognizant - Smart attackers will not leave any evidence that they have been in one of your secure accounts but even the most seasoned hackers make mistakes. Being aware when you are logged into session-based services can help you determine if somebody else is walking in your shadow. Keep an eye out for things that seem out of place, and pay attention to “Last Logon Time” fields to ensure everything matches up.
• Secure your internal machines - Once again, 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 session hijacking attack.

Wrap Up


We have now covered three very lethal MITM attack types which could all have very grave consequences if successfully carried out against a victim. Using session hijacking someone with malicious intentions could access a user’s online banking, e-mail, or even a sensitive intranet application. In the next article in this series we will look at another lethal MITM attack, SSL spoofing