Person-in-the-Middle via ARP spoofing

File: hacking/arp-poisoning.pdf

Solo or with a partner. Probably more fun with a partner.

Goals

• Work through a real technique for setting up an adversary-in-the-middle attack
• Learn about the Address Resolution Protocol and routing tables
• Learn a little bit about one of the many, many hacking tools (Ettercap, in this case) available for Linux

Rubric

Background

We have spent a lot of time this term worrying about Mal and how to thwart adversary-in-the-middle attacks. What we haven't done, however, is discuss practical techniques for becoming an adversary-in-the-middle. This assignment concerns a well-known AITM attack: ARP cache poisoning.

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). 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 (medium access control) addresses. 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.

(One caveat about the "hardware address" idea. There are many situations in which a device will pretend that its MAC address is actually something different than the one burnt into its circuitry. One such situation was developed by Apple for iOS, ostensibly to protect users' privacy. This week, news has come out that Apple's system hasn't been working.)

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 a response comes back saying that 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 adversary-in-the-middle from our Kali virtual machine.

To connect this fairly complicated setup with our past work, here are the characters in our drama:

• Alice: Metasploitable
• Mal: Kali
• Bob: cs338.jeffondich.com

Execution

With all that as background, do the following. Include answers to the questions in your report under the heading "Execution". Feel free to use images where appropriate.

1. What is Kali's main interface's MAC address? (The main interface is probably called eth0, but check ifconfig to be sure.)

2. What is Kali's main interface's IP address?

3. What is Metasploitable's main interface's MAC address?

4. What is Metasploitable's main interface's IP address?

5. Show Kali's routing table. (Use "netstat -r" to see it with symbolic names, or "netstat -rn" to see it with numerical addresses.)

6. Show Kali's ARP cache. (Use "arp" or "arp -n".)

7. Show Metasploitable's routing table.

8. Show Metasploitable's ARP cache.

9. Suppose the user of Metasploitable wants to get the CS338 sandbox page via the command "curl http://cs338.jeffondich.com/". To which MAC address should Metasploitable send the TCP SYN packet to get the whole HTTP query started? Explain why.

10. Fire up Wireshark on Kali. Start capturing packets for "tcp port http". On Metasploitable, execute "curl http://cs338.jeffondich.com/". On Kali, stop capturing. Do you see an HTTP response on Metasploitable? Do you see any captured packets in Wireshark on Kali?

11. 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 Metasploitable VM from the Host List
    • Add that host as Target 1
    • Start ARP Poisoning (including Sniff Remote Connections)
    • Do your stuff with wireshark and Metasploitable
    • 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.)

    So, to wrap up this step: start the ARP poisoning. You will keep the ARP poisoning attack active until you are done with your AITM attack. (Realistically, you will probably start and stop ARP poisoning several times as you gradually figure out what's going on while doing the steps below.)

12. Show Metasploitable's ARP cache. How has it changed?

13. Without actually doing it yet, predict what will happen if you execute "curl http://cs338.jeffondich.com/" on Metasploitable now. Specifically, to what MAC address will Metasploitable send the TCP SYN packet? Explain why.

14. Start Wireshark capturing "tcp port http" again.

15. Execute "curl http://cs338.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 cs338.jeffondich.com?

16. 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 AITM 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.)

17. 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.)

Synthesis

There's a lot of detail in the previous section. Now add a "Synthesis" heading to your report. Under this heading, answer the following questions to try to identify the essential ideas to help you clearly articulate how this attack works.

1. Explain in detail Mal's strategy for intercepting the traffic between Alice and Bob. Use any of your observations from the Execution section to clarify your explanation. But be careful not to just reiterate all the steps, and not to focus on specific tools. (For example, I would not expect you to refer to Ettercap in this explanation, since it is merely one of many available tools for generating suitable ARP messages.) Your goal here is to explain to a technical audience (e.g., other CS majors who have not studied security) what Mal is up to, and how ARP cache poisoning works.
2. From Alice's perspective, is this attack detectable? If not, why not? If so, how would Alice's setup need to change to detect the attack?
3. From Bob's perspective, is this attack detectable?
4. Could Alice or Bob detect and/or prevent this attack if the website in question was using HTTPS instead of HTTP? Explain.

What to hand in

Answer the questions in the Execution and Synthesis sections above, and label each answer accordingly.

Have fun!