---------------------[ 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.