This exercise crafts a man-in-the-middle attack by using-- without abusing-- arp. arp is the address resolution protocol. Its design lends itself to the attack. A substantial category of network attacks operate by using protocols per design, but for different purposes than motivated the design. To make the attack, no attempt to change the protocol behavior is needed, only to use it as-is. This attack, arp spoofing, is in that category. arp is a mechanism designed to let one computer tell another how to reach it. The mechanism's workings are inherently suitable for one computer to wrongly tell another to reach it, when the other really wants to reach some 3rd machine.

arp's operation is usually implicit in other network activities, transparent to users. Among other things the arp protocol maintains an in-memory table of IP-to-ethernet address mappings derived from its operation. There is a related command that's also named arp. Its focus is the table, and it is a tool whereby maintenance of the arp table can be done manually. Another command of interest is arping. It is for explicitly, manually triggering the arp protocol to action, emitting arp packets. ettercap is a utility that can use arp to set up a man-in-the-middle attack.

This exercise demonstrates arp spoofing by surfacing normal arp mechanics to view, then using arp as the central component of a man-in-the-middle attack. Students will observe both the normal, implicit operation of arp with tshark watching the ping program, and the explicit operation by using the arping utility. Then they will manipulate arp with ettercap specifically to jockey one computer into position between two others. The others' conversation then flows through that computer as a man-in-the-middle. This is without damaging, debasing, or deforming arp in any way. Arp itself, turned to deliberate usage, is the attack tool.

1. Setting up the topology and tools

It is assumed here you already have a DETER account and password, created following these instructions. Please log in to DETER and "Begin an Experiment," naming it "arpspoof-xxx" (where xxx is some suffix like your initials likely to be unique to avoid name conflict with other students' experiments) and loading in this network specification (.ns) file. When you upload the file, click the checkbox "Do Not Swap In." The file produces this internetwork:

Examine the file, compare it with the diagram, and note the correspondence. This is a 2-subnet internetwork with node0 serving as a router that joins the subnets. The main, lower network is:

10.1.1.0 / 255.255.255.248 or alternatively 10.1.1.0 / 29

Swap your new experiment in.

You gain a terminal window interface to any of the nodes by "double ssh," connecting to users.isi.deterlab.net and from there to the node. For example, to connect to node1:

ssh <your account name>@users.isi.deterlab.net
ssh node1.arpspoof.USCCSci530.isi.deterlab.net

(This documentation is written as if the experiment name is "arpspoof". The real name of your experiment being the variation arpspoof-xxx, you should substitute the real name for your particular experiment wherever you see this document using "arpspoof".) We have things to install on nodes 1, 2, and 4. I suggest you open a terminal window to each of the 4 nodes. Then make the adjustments below.

On node1

This will be the ettercap attack platform. It's the "man" who will position himself in the middle between other nodes.

sudo su
yum install ettercap
yum install wireshark

You will need a script "make-realmappings." A shared copy of it is already in directory /proj/USCCSci530/exp. You also need an ettercap filter. Put copies of them in your home directory:

cp /proj/USCCSci530/exp/make-realmappings ~
cp /proj/USCCSci530/exp/laughingskull.filter ~

On node2

We want node2 to offer an image file to web browsers:

sudo su
yum install httpd   (httpd is the apache web server)
cp /proj/USCCSci530/exp/laughingskull.gif    /var/www/html/   (apache serves content out of /var/www/html)
chmod 644   /var/www/html/*
service httpd start

On node4

node4 must provide ftp and http servers:

sudo su
useradd joe
passwd joe (establish a password of your choosing and remember it)

yum install vsftpd
service vsftpd start

yum install httpd
cp /proj/USCCSci530/exp/index.html    /var/www/html
cp /proj/USCCSci530/exp/congratulations.jpg   /var/www/html
chmod 644   /var/www/html/*
service httpd start

2. Manipulating the arp table

Operate on node1. Examine, populate, and depopulate the arp table. To print the arp table:

arp -n

The table might be empty, especially if you just started your machine or haven't been using it for a little while. It gets populated with machines' address pairs in the course of machine interaction. So populating the table calls for a little interaction. Pinging nearby machines will do. But you can't ping a machine if you don't already know its address. The nmap utility could automatically ping the entire range of addresses in your subnet for you. node1's subnet is supposed to be 10.1.1.0/255.255.255.248. Verify:

ifconfig eth0 | grep "inet addr"

("eth0" might not be the right interface name. DETER nodes have 5 or 6 NICs. One of yours bears the 10.1.1.x address. Here I assume it to be eth0 but it could be eth1, or eth2,.... Ascertain. If you want to do so by examination, run "ifconfig -a" and find the one that possesses the address. If you want to do it programmatically:

ifconfig -a | grep -1 10.1.1 | grep eth | gawk '{print $1}'

Use the name of that NIC interface in these instructions wherever I have used eth0, as in the above command for example.)

The netmask value shown by the command above half-identifies your subnet. Convert it from a dotted quad (e.g., 255.255.255.0) into a corresponding CIDR bit count (e.g., 24) using the rules of CIDR. To fully identify your subnet, it remains to determine its network address. Note the IP address for your machine, which was also shown. Determine your subnet's network address:

ipcalc -n <your machine's IP address> <the netmask>

Now have nmap ping all the other machines on your subnet (by trying all the address in the subnet):

nmap -sP -n --send-ip <subnet network address>/<CIDR bit count>

When this is done, again view the arp table. It should contain some fresh, further enries:

arp -n

Now that the table has entries, choose one to manually delete (not an "incomplete" one and absolutely not the "192.168" one). Note its IP address. Delete it:

arp -d <IP address>

Re-examine the arp table:

arp -n

If you don't delete an entry manually (you hardly ever do), it will disappear after a certain timeout period (seconds or minutes by default).

3. Recording actual address mappings

4. Triggering arp activity both implicitly and explicitly

5. Manual IP spoofing with arping

arping can compose and send an arp request that represents the machine to have an arbitrary (e.g., false) IP address. To allow that in the kernel, on node1:

echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind

then choose both an IP address within your subnet that is not in actual use by any computer (e.g., 10.1.1.5), and one that some other computer uses (e.g., 10.1.1.3), and while running tcpdump or wireshark in another terminal:

arping -c 1 -U -s 10.1.1.5 -I eth0 10.1.1.3

Observe the outgoing arp request, and in particular the value in its sender IP field (which IP it claims to come from). It would be interesting to view the arp table on target machine 10.1.1.3, and what impact this command may have had on it. Remotely (and without great delay) run the command to do so:

ssh <your account name>@10.1.1.3 "sudo arp -n"
cat realmappings

Note you are using ssh here as a remote command executor. (That's actually ssh's essential but overlooked purpose. Running it the usual way, for a remote command session, is really just the special case where the to-be-executed remote command happens to be a shell.) The arp table output by the above command is not yours. It is that of the other machine. This way, you can view the arp tables of linux machines in your subnet on demand without having to log in to them. Note his arp table contains a mapping for 10.1.1.5. Is that mapping valid or invalid? (Big hint: there is no 10.1.1.5.) Huh? What ethernet address is non-existent 10.1.1.5 supposed to have then? Is it too non-existent? Check the realmappings file. Whose ethernet address does the poisoned arp table on 10.1.1.3 claim that 10.1.1.5 has?

To our deceived machine (10.1.1.3), arping is able to (mis)represent that the ethernet address in the machine where arping runs (10.1.1.1) belongs with some other machine's IP (10.1.1.5). It does not. Once that falsehood is lodged in the deceived machine's arp table, that machine will send frames wrongly to arping's machine (10.1.1.1) whenever it wishes to reach the other IP (10.1.1.5). Instead of sending to the machine that actually holds that IP (if any). That's what "spoofing" means. I tell you that I'm Joe. Every time you have something to say to Joe you turn to me and say it unaware that I'm not him.

How does arping get away with this injustice? By following the design operation of arp. arp intentionally provides that whenever machines get requests for their own ethernet-to-IP mapping (i.e., when somebody else arps them), they should then and there record in their table the sender's mapping. That's always embedded in the incoming arp request. So there are 2 ways a machine can get another machine's mapping into its table-- actively by asking for it, or passively as side-effect of being asked. When being asked, the embedded incoming sender mapping is taken at face value, no questions asked. Straight into the arp table it goes. Why?? Because arp is smart. It reasons that the requestor is not requesting idly, but because it is about to initiate communication which will require responses and so also the sender's mapping. It's a sure bet his mapping info will be needed so, now that it's in hand, don't discard it but put it in the table immediately for efficiency. So I can manipulate your arp table by composing any mapping I want and embedding it as the sender mapping into an arp request to you. The arping utility is one tool that can do this for you.

In the "dump" window, terminate tshark (ctrl-C).

6. Arp-spoofing your way into the middle of a traffic stream with ettercap

Ettercap can do the same thing you just did with arping among multiple nodes in a net. Just as I could do it among multiple people. I could tell you I'm Joe. And I tell Sally I'm you. Now the both of you will turn to me whenever you want to talk to each other and say it to me unaware I'm not the other. If I parrot your stuff on to her, and hers back to you, neither of you will notice anything out of the ordinary. I would become a man in the middle. Optionally, I could record all your secrets or insert lies. Ettercap does exactly the same thing for ethernet frame conversations.

Let's insert node 1 in the middle between node2 and node0 then watch 2 and 0 ping each other. You have two node1 terminal windows open. On node1:

ettercap -T -M arp /10.1.1.2/ /10.1.1.6/

From node1's other terminal window look at the arp tables on both ettercap target nodes:

ssh <your account name>@10.1.1.2 "sudo arp -n"
ssh <your account name>@10.1.1.6 "sudo arp -n"
cat realmappings

and compare appearance (in those two nodes' eyes) with reality (in realmappings). Nodes 2 and 0 appear to have a certain hardware address. Whose? On node1 (from 2nd terminal window) run tshark:

tshark -c 4 -i eth0 icmp

Then concurrently on node2:

ping -c 1 10.1.1.6

The above 1-count ping should evoke a single request and corresponding, single reply between nodes 2 and 0. The tshark trace shows 2 of each in terms of their IP addresses. What's going on? IP addresses are unreliable; ethernet addresses are fundamental. Find out the real comings and goings of these 4 frames by rerunning the tshark command as follows:

tshark -c 4 -i eth0 icmp -T fields -e eth.src -e eth.dst -E header=yes

Again from node2:

ping -c 1 10.1.1.6
cat realmappings

The trace again shows 4 frames, but in terms of their ethernet addresses this time. Study the trace with meticulous attention to the addresses and the nodes they belong to. Follow which node each frame comes from and which it goes to. How does traffic between node2 and node0 get from node2 to node0?

7. Manipulating the traffic stream once you have it - sniffing it

8. Manipulating the traffic stream once you have it - altering it

1. If node1 is a "man in the middle" then node4 is an "odd man out." In particular, node 4 was unaccounted for in section 3 "Recording actual address mappings." Later you arp poisoned node2 and node0 from node1; how about arp poisoning node 4 from node1? You accomplish poisoning by sending a crafted arp message to a node. Comment on the ways and means of poisoning node4 from node1.

2. Answer the question at the end of section 6. Under the circumstances of that section, "How does traffic between node2 and node0 get from node2 to node0?"

3. Answer the question at the end of section 7, "How?" Recall that node2 logged into ftp on node4 and somehow node1 figured out the user password given by node2. How?

4. Imagine you run a web hosting company. The manager at one of your clients, a medium sized business, calls you in alarm and reports the apparent defacement of his website running on your host machine. Images on the site have all been replaced with various hacker images like the laughing skull. He heard about it from several of his employees, then saw it with his own eyes on their terminals. His website has fallen victim to the same mischief as the one on our node4. What is your course of action?

The University of Southern California does not screen or control the content on this website and thus does not guarantee the accuracy, integrity, or quality of such content. All content on this website is provided by and is the sole responsibility of the person from which such content originated, and such content does not necessarily reflect the opinions of the University administration or the Board of Trustees

Crafting man-in-the-middle founded on arp

Synopsis

Background and recommended reading materials

Project specification

1. Setting up the topology and tools

2. Manipulating the arp table

3. Recording actual address mappings

4. Triggering arp activity both implicitly and explicitly

5. Manual IP spoofing with arping

6. Arp-spoofing your way into the middle of a traffic stream with ettercap

7. Manipulating the traffic stream once you have it - sniffing it

8. Manipulating the traffic stream once you have it - altering it

What can go wrong

Questions for you to answer