Eavesdropping and Intercepting

Networks are typically insecure and we need cryptography to protect information. We experiment simple attacks for intercepting and modifying data which is sent and received on a network.

Netcat, the tcp/ip swiss army knife

We use netcat (nc) to setup a simple network connection. Execute the following on one host where you have root privileges (for example your vulnerable host):

This starts netcat in server mode and listens on port 10000. You can connect to this netcat instance from a different host with:

This basically start a ‘commandline chat’ between the two hosts. netcat, in fact, is like ‘cat’ on the network: it redirects input/output from/to terminal and network.


We illustrate simple interception. To simplify we work directly on the host where the server nc is running. In practice, to intercept it is necessary to have access to the client-server connection. Either we are in the middle (e.g. on a router host) or we are on the same LAN and we perform some spoofing attack to force client-server packets to go through our host. We will discuss these techniques later on. For the moment, we “simulate” this by directly acting on the server host.

The program tcpdump is a simple but powerful tool that allows you to easily sniff. We report a few usage examples from the man page:

The following asciicast show how to use tcpdump to sniff the netcat chat:

We report below some useful options:

tcpdump shows the raw packets including headers. If you want to display just the payload you can use the tcpflow tool. For example, here we sniff a netcat chat:

Option -c prints on the console. Without this option output is saved on file whose name are the IPs and ports as above.

Exercise Try to sniff web or other connections in your own computer.

Man-in-the-middle (MITM)

So far, we have seen how to intercept packets and show their content. We now illustrate how to place a process in the middle of a communication so that it is possible to modify packets before forwarding them. Again, to simplify we work directly on the server. In a real scenario we would need spoofing to make packets pass through the attacker host (see below).

In order to simulate interception we need to instruct our host to receive (intercepted) packets on a certain port. We achieve this by setting up a Destination NAT (Network Address Translation) using iptables:

Intuitively, the above command forwards packets addressed to port 10000 to port 9999. All answers will be translated back as if they were from 10000. The client application will not notice the redirection since all packets will be to and from port 10000.
We will present iptables in a next class so the details will be clearer after that class.

To show the added rule you can do:

To delete the rule:

This deletes the first rule of the PREROUTING chain.

In the middle!

We are now able to redirect a connection to a different port. How can we run a program so that it is in the middle of the communication? In fact, we want that the connection reaches the real destination while we are in the middle so that we can read and modify all the packets.

If we write a program that listens on port 9999, connects on port 10000 and forwards back and forth packets we silently place ourself in the middle. Let’s simulate this with netcat:

We create a fifo ‘pipe’ that we use to redirect input/output. We listen on port 9999 with one instance on netcat taking input from the pipe; every incoming packet is processed and then given as input to another instance of netcat connected to the destination host on the expected port (10000). Thus any incoming packet from the victim will be processed and sent to the correct destination. The output from this latter netcat is the answer from the real destination and is redirected into the pipe so to be sent to the victim host using the former netcat.

Exercise: funny chat

Try to attack the chat. The target is to change on the fly some words. For example ‘nice’ with ‘ugly’, ‘funny’ with ‘sad’, … (you can use the sed command for this simple find-and-replace processing).

Try it yourself. If you have doubts watch the video:

Exercise: HTML injection

Try to mount a MITM attack on a web server running on your host. The goal is to add HTML source code in the web page (simulating a link to some malicious page, e.g., a funny image, …). Use the trick explained above (i.e., iptables) to redirect connection from port 10000 to port 9999, where you will perform the MITM attack.
HINT 1: you can run a simple HTTP server on port 10000 with command python -mSimpleHTTPServer 10000
HINT 2: Pay attention to the Content-Length header that states the length of the page returned from the server. If the content exceeds that length the page will be cut.

Switched versus unswitched networks

In unswitched networks packets are visible from any host on the LAN. Unswitched networks are, in fact, like a big bus. Modern LANs are typically ‘switched’: packets are routed by the switch to the destination host using the MAC address. The switch has a table of correspondences between links and MACs. On these networks, intercepting is not immediate but, as we will see, it is possible. So we should never consider a switched network secure against interception and Man-In-The-Middle attacks.

The ARP protocol

Address Resolution Protocol (ARP) translates IP addesses to MACs on LANs. You can inspect the arp table as follows:

Any host maintains a local ARP table that is updated when needed. To observe this, try to ping a IP address which is not already in the table:

The host has been added in the table. It is interesting to observe how this happens. We can use tcpdump to observe the packets. We first remove the host from the table:

On a different terminal we run tcpdump

When we start ping we observe the following output from tcpdump:

The first packet is a request ‘who-has tell’. The following answer contains the MAC address. If you check the table you will see that it is now updated with this mapping.

So, ARP protocol is very simple: the host asks and waits for the destination host to give the MAC address. This is what any honest host does by default. It is clear, however, that if we can forge a ARP answer we can give a different MAC address so to route traffic to that IP to our own host. This attack is called ARP spoofing (in Italian: ‘beffare’ or ‘imbrogliare’ ARP protocol). This very simple attack is quite powerful as it enables interception on switched networks and is at the based of Man-in-the-middle attacks (that we will see later).

Let us try a ARP spoofing attack. We use scapy, a powerful packet manipulation tool.

If the packets reaches the target host, from now on it will associate our MAC address to the source host IP: all the traffic from the target to the source will be directed to our host. This is NOT just sniffing: the traffic is rerouted to our host and is not delivered to the source host. This is already an active attack.

The attack also works when sending an ARP request, as the receiving host updates its arp table if the MAC address is different. Try the following and observe the effect:

NOTE: the traffic is rerouted to our host but the host will not accept it as the IP is wrong. For example, try to ping the source host IP: after the forged ARP packet the ping will stop to work since messages will be routed to our host but they will be rejected.

NOTE: to avoid that ARP fixes that table with the correct MAC we need to send the fake answer periodically. We can script that as follows:

This sends a ARP spoofing packet every 10 seconds, ‘poisoning’ the target host ARP table.


Once more, execute the following on one host:

And connect from a different host with:

As we have seen, this start a ‘commandline chat’ between the two hosts.

Try now the following:

  1. From a third host (with root privileges) you can try a ARP spoofing attack on the client host so that nc fails to connect;
  2. Try not to iterate the ARP spoofing attack and observe that nc connects after a while: the host has cleaned up its ARP table;
  3. Try to keep the spoofing active with a simple script and observe that in this case nc fails to connect even after some time;
  4. Try to make your attack passive/invisible by enabling IP FORWARDING. This can be done setting 1 in the file /proc/sys/net/ipv4/ip_forward

    You will now see that nc works even if all packets pass through your attacker host. You can check this with tcpdump. You have successfully mount a spoofing attack that might work even on a switched network! Your host is in fact in the middle.

MITM through ARP spoofing

So far, we have seen how to re-route network traffic (even on switched networks) to an attacker host. This is done by repeatedly sending fake ARP packets to the victim host so to ‘poison’ its ARP tables. This allows for intercepting packets on switched networks but can be used as a base for a man in the middle (MITM) attack.

The first thing to observe is that during ARP spoofing, connections from the victim are not automatically answered by the attacker host. Try, for example, to ping or to ssh, they will all time-out. What is the problem? The attacker host receives the packets but discards them because of the wrong IP address.

Let us consider an example. We try an ssh connection to while spoofed towards the attacker host By default the attacker host discards the packets as they are directed to 250 and host 250 will never receive packets (unless forwarding is on). We obtain a DoS: ssh stop working. If we enable IP forwarding, packets are rerouted to the correct destination. Everything works (ping and ssh) but we can sniff all the packets since they all pass through the attacker host.

The next step is to process packets before forwarding them. To do so we have to instruct the attacker host to accept these packets with wrong IP. One solution is to set up a NAT (Network Address Translation) using iptables:

The above command add a PREROUTING rule in the nat table: any tcp packet addressed to 100 (option -d, destination) are processed (-j, jump) in Destination NAT (DNAT) as they were addressed to 102. At the same time, NAT translates back answers from 102 as if they were from 100. With this rule any incoming connection to 100 will be processed by 102 in a transparent way.

Some useful iptable options: To show rules in table nat use -L

To delete rules use -D

This deletes the first rule of the PREROUTING chain.

Leave a Reply

Your email address will not be published. Required fields are marked *