Working in an assigned team of two or three students, you will explore how ARP spoofing can be used to redirect network traffic to go through an intermediate computer. This kind of redirection is commonly called a "man in the middle" attack. You'll also see how this attack might be visible if you examine addresses at both the link layer (MAC addresses) and the network layer (IP addresses).
Knowing how to do something is entirely different from knowing what is right to do and what is wrong. When you were a small child, you learned how to pass through an unlocked door: you just turn the knob, push the door open, and walk through. However, you also learned that there are circumstances where it is completely proper to use this knowledge (entering your own home) and others where it is utterly inappropriate (entering someone else's home without invitation). The same is true for ARP spoofing; there are situations where it is appropriate and many others where it isn't.
There are a lot of reasons not to enter other people's homes uninvited. If you are entering in order to do them some harm, such as though robbery, that's an obvious problem: harming other people isn't good. In fact, harming other people isn't good even when unintentional, which is another reason not to go wandering about uninvited. Stuff happens. How would you explain having accidentally let the cat out of a house you never should have been in? There's also another more subtle form of harm you may do even if nothing overtly goes wrong: you've violated someone's expectation of privacy. There's also a selfish reason not to wander into other people's homes uninvited; they might be alarmed and lash out at you.
All of these same considerations carry over into the computer security context. Testing the security of your own system, or of a system you've been explicitly invited to test, is generally OK, but uninvited "testing" is really a form of trespass and is definitely not OK, even if you aren't trying to do some harm (like stealing from someone's bank account). Once you've started using penetration tools, its really easy with a little slip to accidentally do some harm you never intended, like letting the cat out. (Once, when I intended to add a back-door user account to a system I had broken into, I made a one-character typo that resulted in replacing all the existing accounts so that all that was left was the one new account. Not good.) Of course, you never intend to slip, but the proper thing to do is to not get into situations where slipping can do such harm, or at very least, not get into such situations without being accountable for your actions. Plus, even if you manage to go in and out of someone else's computer system without any overt harm resulting, you've violated their expectations of privacy. That's not OK either. And if the system administrators happen to have some monitoring in place you didn't know of, you could be in a load of hot water, trying to explain your harmless intentions. Felony convictions are rare, but I've known people who were rendered essentially unemployable.
So, let's get concrete. What does this imply for the present lab? It would be a lot of fun to do our work on the college's wireless network, using one laptop as a man-in-the-middle between another laptop and the router. That way, all the traffic between the attacked laptop and any server whatsoever would be intercepted, because all the servers are on the other side of the router. If the attacked computer belonged to an unwitting person, this would definitely be bad; at a minimum, we'd be damaging their privacy. But what about if we used two of the lab laptops? The one being attacked would be intended just for that very purpose. It would only be accessing non-privacy-sensitive web sites just to demonstrate that the other laptop was successfully intercepting its traffic. Where would be the harm in that?
In testing network security (as opposed to the security of a stand-alone computer), one is breaking into two systems: the attacked computer and the network itself. If we attacked our own computers, but did so on the main college wireless network, we'd have been invited into one target (the attacked laptop), but not the other (the wireless network). Remember, uninvited security testing of someone else's system is never a good idea. The college's wireless is someone else's (even though we're part of the college too), and we haven't been invited to do a security test on it. It would be really easy for some small slip-up in the experiment to cause harm to other users of the network. Wouldn't you feel awful if you accidentally broadcast ARP packets that rendered the router unreachable for all the other wireless users? Your self-interest also points the same direction: if the network administrators see spoofed ARPs for the router, the attention you attract isn't likely to be the good kind.
For these reasons, even though its less fun, we're going to take the safe approach of working in an isolated wired network. As in the previous lab, you'll use three computers connected with an Ethernet switch. One will be the client, one will be the server, and one will be the "man in the middle" that interposes itself between the client and server. You'll have to trust me that the exact same techniques could be used on the college's wireless network. (In one detail, the results might be a little different; I'll point that out.)
Each team will use three computers I will provide that are running the Ubuntu distribution of Linux. (These three computers will play the roles of client, server, and attacker.) I have left these computers the way they were at the end of the prior lab (aside from recharging the batteries), so they should still have Wireshark installed and a "spoofcode" directory somewhere (perhaps in the Desktop, Downloads, or Documents) containing the UDPClient.py and UDPServer.py programs, which we'll use for testing. If any of your team's computers is missing Wireshark, you'll need to connect to the college network and install it. Likewise, you'll need UDPClient.py on one computer and UDPServer.py on another, so if you can't find them on at least two of the machines, you'll need to download them.
Connect the Ethernet switch to a power outlet.
Do the following on each computer:
Disable the wireless network if it is enabled.
Check that the configuration for the wired network has IPv4 set to "link local only"; if necessary edit it to this setting.
Use an Ethernet cable to connect the computer to the switch.
Wait until the display shows that the wired network is connected.
In a terminal window, run the ifconfig eth0 command to verify the computer now has an IP address ("inet addr") of the form 169.254.x.x. Make a note of each computer's IP address and MAC address ("HW addr").
Run the Wireshark program and start a packet capture running capturing packets on the eth0 interface. (You should leave this continuing to capture during all of the experimentation.) To show only the packets relevant to this lab, you can set a filter of udp.port==12000 || arp. For some portions of the lab, it may be convenient to focus in on only one or the other part of this filter.
On the client computer, edit UDPClient.py so that it has the server computer's IP address as the serverName to connect to.
In a terminal window on the server computer, run
python UDPServer.py
In a terminal window on the attack computer, run the following two commands:
sudo sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward' sudo sh -c 'echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind'
These turn on two settings that will prove useful later. The first arranges that if a packet comes in with the attack computer's MAC address but a different IP address, it will get sent back out to the proper MAC address. The second arranges that the attack computer can use IP addresses other than its own.
In a terminal window on the client computer, run the following command:
python UDPClient.py
Enter a distinctive lower-case string such as "test one". You should see it come back out in upper case ("TEST ONE").
Look at the packets that were captured by Wireshark on each of the three machines. You should see some ARP traffic as well as the exchange of UDP datagrams. Pay attention to what the source and destination MAC and IP addresses are in each of the UDP datagrams. You should see that they are the same on both the client and the server and indicate that the datagrams are being sent directly between these two machines. You should see that the UDP datagrams aren't captured on the attacker machine. Why not? Are there any other packets you see on the client and server but not the attacker? If so, make sure you understand why. Likewise, if any packets do show up on all three machines, make sure you understand that too.
In a terminal window on the attack computer, run a command of the general form shown below, but with the actual IP addresses for the server and client computers inserted in place of the placeholders "SERVER_IP" and "CLIENT_IP":
sudo arping -s SERVER_IP -I eth0 CLIENT_IP
Let arping run for 20 seconds and then in a terminal window on the client computer, run the UDPClient again but use a different lower-case string, such as "test two", so that you can more easily tell which packets in Wireshark came from each experiment. You should see your string printed in upper case.
Back on the attack computer, use control-C to stop the arping command.
Look at the packets that were captured on the three computers. If you focus on ARP packets, you'll see the direct results of the arping command. If you focus on the UDP packets, you'll see the indirect result. Remember to look at the source and destination MAC and IP addresses on all three computers. You should see that the client has been tricked into sending its lower-case string to the attacker's MAC address, even though it uses the server's IP address. Because the attacker's forwarding mode is turned on, you should see the lower-case UDP datagram captured twice on that machine: once coming in from the client, the other time going back out to the server. Note what the difference is between these two versions of the datagram.
You should notice that the server receives somewhat suspicious packets; they come in from the attacker's MAC address but with the client's IP address. In our experimental setting, that doesn't cause any particular alarm. Nor would it for many wireless routers in homes, coffee shops, etc. However, remember that the Gustavus network requires computers be registered. Therefore, the Gustavus router knows what MAC and IP addresses correspond. It can filter out any packets that come in with mismatched addresses. This is one place where our experiment might be different if done on the college's wireless network. In the next section, we'll see one way the attacker can avoid this red flag.
You should also notice that the returned UDP datagram with the upper-case string is not captured by the attacker. That's because the server is sending it back to the client's IP address, and the server has used ARP to find the correct MAC address for the client. If the attacker wants both directions of data to flow through the attack computer, arping could be used to trick the server the same way as the client. However, the approach given in the next section provides a less obtrusive alternative.
The 20-second delay in these instructions is there because when arping first starts up, its first ARP message provokes the server to make an attempt to defend its address by sending ARP messages of its own. However, after that attempted defense is over, the arping program will continue sending ARP messages, which will influence the client without provoking the server. You'll need to explain this in your report.
Instead of forwarding datagrams unchanged (aside from the source MAC address in the link-layer header), the attacker can enable Network Address Translation (NAT) using the following command in a terminal window:
sudo iptables --table nat --append POSTROUTING -j MASQUERADE
After running this command, repeat the experiment from the previous section, running arping on the attack computer, waiting, and then running UDPClient on the client computer. (I suggest that you change the lower-case string again, such as to "test three".) You should see some differences in the addresses contained in captured datagrams. In particular, the server should now receive datagrams that have matching MAC and IP source addresses, so that it won't notice anything amiss. Also, even though the server hasn't been given any spoofed ARP information, it sends its replies back by way of the attacker. Be sure you understand why.
You should be able to see that this technique can be used to eavesdrop on another computer's communication. Unlike with simple radio-frequency eavesdropping, it doesn't matter if the wireless network is using link-layer encryption such as WPA. You don't need to break the WPA encryption because each link in the chain from client to attacker to server (or router) is a perfectly legitimate link-layer communication, and the WPA encryption applies separately to each of them. The attacker's WiFi interface will automatically decrypt the frames directed to it and re-encrypt the new frames it sends out.
However, the attacker can do more than just eavesdrop. There is no reason why it needs to forward along the same data as it receives. It can modify the data before retransmitting it. This can be used to simulate your taking actions you would not actually want to take. Or it can be used to send you data that exploits some vulnerability in your own computer's security.
The fact that the attacker can change the data also can provide leverage for overcoming higher-level security mechanisms (such as https) that are intended to work end-to-end.
Your team should jointly author a report that answers the following questions, each worth 1 point:
In the experiment with no "man in the middle," which packets show up only on the client and server computers, and what prevents their capture on the computer that will be used for attack?
In the experiment with no "man in the middle," are there any packets that show up on all three computers? If so, which ones and why?
In the experiment with the simple "man in the middle" (no NAT), what are the source and destination IP and MAC addresses of each UDP datagram captured on each machine? You should show show these in an abbreviated format such as C/C->S/A to indicate that the source IP and MAC addresses are those of the client machine, the destination IP address is that of the server, and the destination MAC address is that of the attacker. Give a list of these abbreviations for the UDP datagrams captured on the client, another for those captured on the attacker, and a third for those captured on the server.
In the experiment with the simple non-NAT attack, does either the client or the server receive any sign of the attack other than the spoofed ARP messages and the mismatched addresses in the UDP datagrams? (Hint: the answer is "yes," but I'm looking for more detail.)
In the experiment with the NAT version of the "man in the middle" attack, what are the source and destination IP and MAC addresses of each UDP datagram captured on each machine? Show these in the same abbreviated form as for the previous experiment.
What is the difference between the first ARP message from arping and the subsequent ones that explains why the first provokes the server to defend its address but the subsequent ones don't?
Extra credit: how could arping be changed so that the server isn't provoked by even the first spoofed ARP message? (Keep in mind that until the attacker gets an ARP response, it doesn't know the client's MAC address.)
One student from each team should upload your report to Moodle.