Royal Military College of Canada

Department of Electrical and Computer Engineering

EEE473 Computer Network Design
Dr G.S. Knight
Dr S. Leblanc

Lab 5 - Man-in-the-middle Attacks, ARP Spoofing, TCP Hijacking

References

  1. WinDump Manual
  2. Ettercap README
  3. tcpdump Manual (available from your Linux VM)

Objectives

This lab aims to:

Introduction

In this lab you will examine some of the security flaws in existing network protocols.  The suite of network protocols in wide use, commonly implemented in the TCP/IP protocol stack on contemporary computer systems, was designed in an environment of trust.  Communicating network machines were trusted not to lie about who they were or to subvert the communications on the network. In our current global internet environment, this assumption of trust and honesty does not hold because the attackers are in control of some of the machines on the network. In this lab we will see how the attackers can manipulate packets and lie about who they are. Manipulation of the network can occur at any of the network layers of the OSI model. In this lab we will manipulate information in the link layer, internet layer, and the transport layer. These manipulations will allow us to eavesdrop, redirect communications and hijack TCP sessions. You will use a dated but illustrative hacking tool, ettercap, to perform the packet manipulations and you will capture and analyse the resulting traffic in order to better understand how the network vulnerabilities are being exploited.

Part 1 - Explanation of ARP Spoofing and TCP Hijacking

1a - The Address Resolution Protocol (ARP)

Recall the description of ARP from class and Lab 4.

In addition to specifically asking for a MAC-to-IP mapping when a machine needs to send a network packet, it also listens to all the other ARP traffic on the network. By "listening-out" to ARP traffic in this way a machine can come to know even more MAC-to-IP address mappings and store them in its ARP cache. In this way the machine may not have to delay network communication while it makes an ARP request as it already discovered the mapping by listening-out. These updates are done even for IP addresses that are already in the ARP cache. Note that this also reduces the network load / traffic slightly.  This scheme is called "Gratuitous ARP".

You can see that in order to populate its ARP cache, a machine trusts the senders of the ARP messages not to lie. Attackers can craft false ARP packets and cause a machine to alter the mappings in its ARP cache. In this way the attackers can convince the target machine to send packets anywhere. This is called "ARP spoofing" or "ARP Cache Poisoning."

1b - TCP Hijacking

If attackers can monitor an ongoing TCP connection they have access to all the information in the IP and TCP headers and to the packet payloads.  Of course attackers can eavesdrop on the connection, but by gathering the right information attackers can actually take over the connection (hijack it).  To do this the attackers need to know the IP addresses and port numbers that the connection is using. They also need to know the sequence numbers in the TCP headers that are being used to control the error correction mechanisms in the TCP stream communication. Recall that there is an incrementing series of sequence numbers (a different set of numbers for each direction of communication) that are used to make sure that:

  1. all packets are being received at the destination;
  2. the packets are reassembled in the correct order; and
  3. duplicated packets are only used once.

During synchronization (the initial TCP 3-way handshake) a random sequence number is chosen as the starting sequence number for each direction of the communication. As data is passed on the TCP connection the sequence numbers reported in each packet are incremented to indicate the number of bytes of data passed on the connection up to the point of that packet's transmission. The sequence numbers are used to sort the order of packets (and discover missing packets) at the other end.

Since the attackers are eavesdropping they have all the information they need to craft a false packet that looks like it is the next packet in the TCP connection. For example if a user is running a telnet session into a remote computer the attackers can craft packets to send their own commands to the remote machine. The packets will look like, and be executed, as if they came from the legitimate user. This is a "Simple TCP Hijack."

There are some problems associated with Simple TCP Hijack. It works fine for the first hijacking packet but not subsequent ones. When the attackers inject a packet, they increment the sequence numbers in the normal way so the packet is accepted properly at the destination. Unfortunately the original user's machine is not aware of the hijacking data that was injected and its sequence numbers have not been incremented by the injected packet. When the destination machine acknowledges the injected packet the original user's machine sees an acknowledgement for data that it never sent (the data was sent by the attackers). The sequence numbers are now out of synchronization between the legitimate user's machine and the remote host (destination machine). Different operating systems deal with this in different ways but there is danger of a continuous stream of ACK packets being generated between the machines as they hopelessly try to resynchronize. This is called an "ACK Storm" and can hang the systems.

If we combine this TCP hijacking technique with the ARP spoofing techniques discussed in the previous section we can solve the ACK Storm problems and inject data into the TCP stream, or take total control of the TCP connection.  The attackers use ARP spoofing to have the legitimate user's machine and the remote host both send their packets to their attacking machine, instead of their intended destinations. The attackers are now a man-in-the-middle; They control all the packet flow between machines. Initially, before the hijack, the attackers can simply relay the messages to the intended destination.

However, when they want to inject packets, the attackers can send crafted packets to one of the target machines. The crafted packets will spoof the correct sequence numbers so they will be accepted by the target machine. After this point the sequence numbers in the two machines that were originally communicating will be out of sync; one machine has received more data than the other machine has sent. Therefore the attacking machine as man-in-the-middle must modify the sequence numbers on-the-fly as they pass through to adjust them and keep the target machines in synchronization.

To completely take over the connection, the attackers stop forwarding packets for the legitimate user's machine associated with the hijacked TCP connection. The attackers now fully take the place of the legitimate user machine and the remote target host is not aware of the switch. To the legitimate user's machine the connection has gone dead. The legitimate user's connection will eventually time-out, or the attackers may try a more sophisticated resynchronization technique when they are done with the hijack.

Part 2 - Analysis of an ARP Spoofing/TCP Hijacking Attack

You are going to use a Linux tool called ettercap to ARP spoof on a network, and hijack TCP connections.

In the lab, set up the following network using the Common Hub:
Figure 1 - Lab 5 Network

Figure 1 - Lab 5 Network

2a - Activity 1

Start the Windows VM. For this lab we will refer to this VM as the User machine. Configure the external adapter according to the specifications above.  Make sure you can telnet to alice's account (password: secret) on the Server VM from the User.

Note that once again, we use IP aliasing to ensure that every group has a Server with a unique IP.  There is no guarantee that the hijacking sessions would work as designed if each team were to attack the same Server, ; at some point one instance of ettercap begins to attack another instance of itself. 

Log out of alice's account.

Start the Linux VM, which we will refer to as the Attacker machine.  Configure the external interface according to the specifications above. Recall that during the preamble (Lab 1) you learned how to display and configure an interface on the Linux VM.

Confirm your configuration settings by pinging the Server from the Attacker. Also make sure you can observe the telnet traffic between the User and the Server by using tcpdump on the Attacker machine.

Using tcpdump and/or arp identify the correct MAC-to-IP mappings for each of the 3 machines. Mark these on your diagram, which you must include in your lab report (#1).

2b - Activity 2

Start the ettercap program on the Attacker:

You should see ettercap's graphical user interface come up. First, configure the ettercap sniffer by selecting from the main menu: Sniff -> Unified sniffing. In the pop up dialogue specify the external network interface.  Then start sniffing by selecting from the main menu: Start -> Start sniffing.

On the User machine run telnet to log into the alice account on the Server (if you are already running a telnet session, logout then login again).

(#2) Look at the dialogue at the bottom of the ettercap screen on the Attacker machine. What do you see?

Now look at the connection data by selecting from the main menu: View -> Connections.

Use the ettercap console to browse around and see the following things (have fun, but don't mitm, inject data or inject file just yet):

Now we will use ettercap to inject our own commands into the connection. First we need to populate a list of hosts that we can use as targets for our attack. Do this from the Profiles tab by pressing the "Convert to Host List" button at the bottom of the screen. Then open the Hosts -> Host list tab.

You can view the targets in the Targets->Current Targets tab. Now select from the main menu: Mitm -> Arp poisoning. In the ARP poisoning tab select Sniff remote connections. You should see signs of success status at the bottom of the screen.

Go to the Connection data tab for the User telnet session (that is now man-in-the-middled). Type some commands at the User machine and make sure you can see them sniffed in ettercap.  

You can now also use the Inject Data button on the bottom of the screen to inject a command into the stream.

Stop the mitm attack, stop sniffing and exit the ettercap program.

2c - Activity 3

In this activity you will repeat the same sequence of events carried out in Activity 2 so as to repeat the TCP hijack. However, this time ensure that you capture the traffic using tcpdump on the Attacker. For each of the questions in Part 3, prepare small trace examples and include those in your lab report.

We highly suggest that you write your pcap to file (with tcpdump's -w switch) so that you may come back to it later; you will need to use sudo tcpdump to run your sniffing command (call an instructor after reading the man page if you need help). You may also wish to pipe the output of certain commands to a text file (using > file.txt) to capture the output of commands such as ARP.

Part 3 - Analysis

Read through the remainder of the lab carefully to ensure that you understand all that is required. Once you are confident that your pcap will allow you to produce all the traces you need, log out of alice's telnet session from the User to the Server  and exit the ettercap program on the Attacker. You will note that there are few aspect to discuss in this lab; the instructor will therefore expect each of them to be discussed very thoroughly.

Explain what has happened to the ARP cache on the User, using specific examples of ARP cache entries. Include a small portion of your trace with your report, no more than 1 page is necessary (#3).

Explain what packets from your tcpdump trace are associated with the ARP cache poisoning (#4). Note: some are the cache poisoning packets and some may be test packets to see if the spoofing is working. Include parts of your trace as an attachment to your lab submission.

Using example packets from your trace, explain how the Attacker is acting as a man-in-the-middle (#5). Pay careful attention to the MAC-to-IP address correspondence in the packet headers. For example, trace a portion of the telnet session from the User to the Attacker and then to the remote telnet Server.

Explain what packets in your tcpdump trace are associated with the TCP hijack (#6).  Again, pay careful attention to the MAC-to-IP address correspondence in the packet headers when explaining. Ensure that your discussion considers the TCP sequence number issues involved.

Conclusion

Once you are confident you have all you need for your lab report, do not forget to follow the instructions in the preamble to properly shut down your VMs and log out of your host machine. Ensure that the you leave the cage in the same state you found it.

Submit your lab report by e-mail. Place files together in a  zip file before sending. Include your report and network traffic dump files.