---------------------[ ARP poisoning live ]--------------------- In this exercise, we will attempt to capture traffic on a wireless LAN that is not supposed to cross your computer. Recall that every Ethernet frame starts with the destination MAC address, and switches use this MAC address to choose the port to which they direct this frame. On a typical Ethernet switch, the port your machine is connected to will not receive unicast frames that are exchanged between other computers connected to other ports on the same switch. The situation is somewhat more complex for Wi-Fi, but Wi-Fi frames similarly include a destination MAC, and the Wi-Fi access point (AP) uses it for delivering frames. Packets exchanged between other computers on the same WLAN should not be delivered to you by the AP (although you may hear them in the air in the so-called Monitor Mode). In this exercise, we will cause packets exchanged between other computers on a WLAN to be sent to us; we will forward, drop, or modify them at our convenience. ---------------------[ Setup ]--------------------- 0. Work in groups. Let one of you perform the attack, which others provide the "victims". 1. There will be 5 APs serving WLANs named cs60ap1, ..., cs60ap5. You will be instructed to join the wireless network of one of these APs and provided with the password for that network. For the attacker: do that with your host computer that has the Linux VM. For the "victims", do it either with your laptops or smart phones. It will be easiest if one of the victim machines is a laptop and can ping the other. If you cannot use your wireless interface, you can connect to the AP via a cable through your Ethernet interface. 2. Start your Linux VM in VirtualBox. On the right of the bottom bar of the VirtualBox window, select the icon for "Network Settings" (it looks like a pair of monitors, one behind the other). Click "Network Settings", and change the "Host-only Adapter" to "Bridged Adapter". Select your wireless interface. If you prefer to connect to the AP view a cable, select your wired interface. Click OK. 3. Now your eth0 in your VM is bridged to your outside interface. Obtain an IP address from the AP. Open a root shell, and first kill any DHCP client process ("killall dhclient"), then start a new one: "dhclient -v eth0". You should see your requests, and then a reply from the DHCP server on the AP. Your VM may first request the IP address it used to have, 192.168.56.100---in which case you will see a DHNACK from the AP (denying that request), then a new offered address. If you see requests but not responses, check that you are not connected to Dartmouth Public or Dartmouth Secure---these do not work with virtual machines. 4. Pick two machines connected to the same WLAN that you'd like to listen to. These could be laptops or smart phones connected to the same network. All you need is to know for the attack is their IP addresses. On the attacker VM, check that you have connectivity and can ping your victims. Stop the ping after you succeed. Start pinging one victim from the other. 5. Start tcpdump on eth0 in your VM (you'll need a root shell). E.g.: "tcpdump -i eth0 -n icmp" You should _not_ be seeing victim machines pinging each other. These pings flow through the AP the same way they flow through an Ethernet switch: bypassing your machine. Our objective is to make these packets flow through your VM, and sniff them. 6. In your VM start another rootshell. Run scapy in it. Scapy has a built-in function arpcachepoison. Use is as follows: >> arpcachepoison( victim1_IP, victim2_IP, interval=10) For example, if you want to intercept packets that 192.168.1.155 sends to 192.168.1.138, use >> arpcachepoison( "192.168.1.155", "192.168.1.138", interval=10) This will poison .155's ARP table with your MAC pretending to be that of .138, every 10 seconds. 7. You will see ping requests appearing in your tcpdump. You will also see the ping between the victims failing. This is because your VM now gets the pings, but does not forward them! 8. Configure forwarding. Before you do that, also tell your VM kernel to NOT send ICMP redirects, saying, "hey, you are trying to talk through me, but you could talk directly to each other!". Your kernel is being honest, but we don't want that. To disable redirects: "echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects" To start forwarding packets: "echo 1 > /proc/sys/net/ipv4/ip_forward" You should now see you ping between the victims resume, AND your tcpdump showing these ping requests still. Check ARP tables on the victim laptop "arp -an". What do you see? 9. Think of what you need to do to see the replies as well. Hint: you are ARP-poisoning one victim, but not the other. 10. Observe the MAC addresses of the pings coming and going on your system: use "tcpdump -e -i eth0 -n icmp". Note the MAC addresses of incoming and outgoing packets. You are seeing packet forwarding in action. 11. Stop your ARP poisoning of the victim pair ping. Try to snoop on the communication of a victim with the outside world. Which machines and IPs do you need to ARP poison to do this? 12. (Extra credit). Write a tool in C using AF_PACKET raw sockets that will achieve the same as Scapy's arpcachepoison function.