Work with one or two partners. If you said "keep assigning me a partner" on the most
recent partner survey, I'll set you up with a random partner--see Slack for that.
Any partner problems? Let me know.
Some background
We have spent a lot of time this term worrying about Mal and how to thwart person-in-the-middle
attacks. What we haven't done, however, is discuss practical techniques for becoming
a person-in-the-middle. This section of this exam concerns a well-known PITM attack: ARP spoofing.
In the questions below, I will refer to "network interfaces" and their attributes. An interface in this context
is a software object roughly analogous to a physical networking device. For example, when I open a
terminal on my Mac and run "ifconfig", I see a list of interfaces and their attributes. There's "en0"
which corresponds to my wireless network device. There's also en1, en2, en3, and en4, each of which
corresponds to one of my USB-C jacks in the sides of my laptop (they're all capable of connecting me
to an Ethernet if I have the right adapter). And there's lo0 (the "loopback interface"), which gives me
a way of treating my own laptop as just another computer on the network.
When I run ifconfig on my Kali virtual machine, I see two interfaces. There's lo (the "loopback" interface)
and eth0, which is
my Kali VM's interface to whatever network my actual hardware is connected to. As I type this,
eth0 on the VM is indirectly connected to my laptop's wireless card, but from Kali's point of view,
it doesn't matter—eth0 is just another network interface.
Network interfaces in all the contexts we're working in are associated with 48-bit "MAC addresses" (medium
access control). When the interface is associated with a hardware device, the MAC address is actually
physically built into the device. When an interface is a software entity (like eth0 on my Kali VM),
the MAC address is some sort of randomized 48-bit number. Either way, it generally works to think of
this as a "hardware address" that can't be changed. In contrast, an IP address is a more abstract
address that can be moved from device to device based on the needs of the owner of the IP address.
To give you a little sense of the uses of IP addresses and MAC addresses, consider this common
situation. Suppose you type "http://somenewwebsite.org/" in your browser's address bar. Then your
computer's network hardware has to do something like this:
- Check the DNS system to determine the IP address of somenewwebsite.org. (This
step can get pretty complicated, but let's consider it a one-step operation for now.)
Suppose the answer is 123.123.123.123.
- Check your routing table to determine which IP address on your local network
should be the first hop for packets you want sent to 123.123.123.123.
Suppose the answer is 10.10.10.10.
- Check your Address Resolution Protocol (ARP) cache to
determine the MAC address of 10.10.10.10. (If 10.10.10.10
isn't in your ARP cache, send out an ARP request to find out the MAC address of 10.10.10.10.)
Suppose the MAC address in question is 01:23:45:67:89:ab
- Assemble your first packet bound for 123.123.123.123 and wrap it in an Ethernet frame
with destination hardware address 01:23:45:67:89:ab.
- Write your frame to your outgoing interface (e.g. eth0).
The point is that you use an IP address to refer to any computer on the internet. But to actually
send any data packet to the first machine along the packet's path to its destination IP address, you
have to know the first machine's MAC address.
Setup
For this assignment, you will launch two virtual machines—one running Kali, and one
running Metasploitable 2.
Metasploitable 2 is a command-line-only version of Linux that is intentionally set up with a ton
of security holes that learners like us can use to practice our sytem-exploitation skills.
For this exercise, we're going to attack our Metasploitable virtual machine as a person-in-the-middle
from our Kali virtual machine.
If you're working in REMOTELAB or the Olin 3rd-floor labs, you're already set up with Metasploitable and Kali.
If you have your own VirtualBox setup, you'll need to add a new virtual machine for Metasploitable.
You can either use the official instructions
(substituting "VirtualBox" wherever they say "VMWare"), or you can use
these instructions
assembled by Mike Tie and his student workers.
Two things to keep in mind once you have a Metasploitable 2 virtual machine:
- When you start the Metasploitable VM, quickly resize the window to be convenient, before
it gets a chance to pick a bad window size for you. Once VirtualBox settles on a window size,
I have yet to figure out how to resize the contents of the window.
- The user name and password for Metasploitable are both "msfadmin"
Your tasks
With all that as background, please answer the following questions. Put your answers
into a PDF file named attacks/arp-spoofing.pdf, with text and images as appropriate.
- What is Kali's main interface's MAC address? (The main interface is probably
called eth0, but check ifconfig to be sure.)
- What is Kali's main interface's IP address?
- What is Metasploitable's main interface's MAC address?
- What is Metasploitable's main interface's IP address?
- Show Kali's routing table. (Use "netstat -r" to see
it with symbolic names, or "netstat -rn" to see it with
numerical addresses.)
- Show Kali's ARP cache. (Use "arp" or "arp -n".)
- Show Metasploitable's routing table.
- Show Metasploitable's ARP cache.
- Suppose the user of Metasploitable wants to get the CS231 sandbox page
via the command "curl http://cs231.jeffondich.com/".
To which MAC address should Metasploitable send the TCP SYN packet to get the whole
HTTP query started? Explain why.
- Fire up Wireshark on Kali. Start capturing packets for "tcp port http". On Metasploitable,
execute "curl http://cs231.jeffondich.com/". On Kali, stop capturing.
Do you see an HTTP response on Metasploitable? Do you see any captured packets in Wireshark on Kali?
- Now, it's time to be Mal (who will, today, merely eavesdrop).
Use Ettercap to do ARP spoofing (also known as ARP Cache Poisoning) with
Metasploitable as your target. There are many online tutorials on how to do this
(here's one). Find one you like, and start spoofing your target.
NOTE: most of these tutorials are showing an old user interface for Ettercap,
which may make them confusing. The steps you're trying to take within Ettercap are:
- Start sniffing (not bridged sniffing) on eth0
- Scan for Hosts
- View the Hosts list
- Select your Metasploit VM from the Host List
- Add that host as Target 1
- Start ARP Poisoning (including Sniff Remote Connections)
- Do your stuff with wireshark and Metasploit
- Stop ARP Poisoning
I'll post some screenshots on Slack of how I got Ettercap to do these things.
Honestly, I don't know who redesigned this user interface to make it so much
harder to do things, but they did. (Common enough in the Linux UI world.)
- Show Metasploitable's ARP cache. How has it changed?
- If you execute "curl http://cs231.jeffondich.com/" on
Metasploitable now, to what MAC address will Metasploitable send the TCP SYN packet?
Explain why.
- Start Wireshark capturing "tcp port http" again.
- Execute "curl http://cs231.jeffondich.com/" on Metasploitable.
On Kali, stop capturing. Do you see an HTTP response on Metasploitable? Do you see captured
packets in Wireshark? Can you tell from Kali what messages went back and forth between
Metasploitable and cs231.jeffondich.com?
- Explain in detail what happened. How did Kali change Metasploitable's ARP cache? (If you want
to watch the attack in action, try stopping the PITM/MITM attack by selecting "Stop mitm attack(s)" from
Ettercap's Mitm menu, starting a Wireshark capture for "arp", and restarting the
ARP poisoning attack in Ettercap.)
- If you wanted to design an ARP spoofing detector, what would you have your detector do?
(As you think about this, consider under what circumstances your detector might
generate false positives.)
Have fun!