Fun with Raw Sockets in Erlang: ARP Poisoning

On IP ethernet networks, hosts use a peer to peer method called ARP (address resolution protocol) to discover the hardware address of the peer with which they intend to communicate.

IPv4 ethernet ARP packets are specified as:

• Hardware Type:16
• Protocol Type:16
• Hardware Length:8
• Protocol Length:8
• Operation:16
• Sending Hardware Address:48
• Sending IP Address:32
• Target Hardware Address:48
• Target IP Address:32

The numbers after the colon represent the size in bits of the field.

• The Hardware Type of the network is ethernet, so the value is set to ARPHRD_ETHER (1)
  
• The Protocol Type of the network is IPv4, so the value is set to ETH_P_IP (0x0800)
  
• The Hardware Length of an ethernet MAC address is 6 bytes
  
• The Protocol Length of an IPv4 address is 4 bytes
  
• Operation is usually an ARP request (ARPOP_REQUEST (1)) or reply (ARPOP_REPLY (2))
  
• The Sending Hardware Address is the MAC address of the host sending the ARP packet
  
• The Sending IP Address is the IPv4 address of the host sending the ARP packet
  
• The Target Hardware Address is the MAC address of the host receiving the ARP packet
  
  The target address may be the ethernet broadcast address (FF:FF:FF:FF:FF:FF or 00:00:00:00:00:00) which results in all hosts receiving the ARP packet.
  
  
• The Target IP Address is the IPv4 address of the host sending the ARP packet
  

The corresponding Erlang representation of an IPv4 ethernet ARP packet is:

<<Hrd:16, Pro:16,
Hln:8, Pln:8, Op:16,
Sha:48, Sip:32,
Tha:48, Tip:48>>

Behaviour of the ARP Cache

ARP caches are key/value stores holding a mapping of the protocol address to the hardware address. To prevent caching of stale data, entries eventually expire. The expiry timeout varies; for example, on MS Windows, arp entries are kept for 2 minutes if another session to the remote host is not initiated. If a session is initiated within the 2 minute period, the ARP cache expiry time is extended to 10 minutes.

ARP is opportunistic and trust-based. If a host sees an ARP request or reply for which it is not the target, the host may cache the information. However, caching all requests would be pointless, since arp lookup would be slow on a network with a large number of peers with which the host might never communicate.

Gratuitous ARPs

ARPs are gratuitous when no request was made for the information. Gratuitous ARPs are useful for:

• discovering IP conflict
  
• IP take over: in a high availability cluster of servers, one of the hosts is active (holding the service IP address). In the event of a failure of the active node, one of the slave nodes can assume the service IP address, sending a gratuitous ARP to inform the other nodes and the gateway that the IP address is associated with a new MAC address
  

An Erlang binary representing a gratuitous ARP looks like:

<<
1:16,                                 % hardware type
16#0800:16,                           % protocol type
6:8,                                  % hardware length
4:8,                                  % protocol length
2:16,                                 % operation: ARPOP_REPLY
0,1,2,3,4,5,                          % sending MAC address
192,168,1,100,                        % sending IPv4 address
16#FF,16#FF,16#FF,16#FF,16#FF,16#FF,  % target MAC address: ethernet broadcast
192,168,1,100                         % target IPv4 address: set to sending address
>>

Behaving badly by gratuitously arp'ing for all the IP addresses on the network will DoS the other hosts, eventually forcing them to report a network error condition and go offline.

Sending an ARP Reply

To send an ARP packet from Erlang, we'll use the procket module on GitHub. The functions in procket used for these examples are unfortunately Linux-only. For this example, the binaries are manually specified. The epcap_net module on GitHub has convenience functions for creating and decomposing ARP packets into a record structure. If the network was set up like:

• arping Erlang node: 10.11.11.9
  
• source host: 10.11.11.10
  
• target host (doesn't exist): 10.11.11.11
  

Login to another host on your network (the source node) and run tcpdump:

tcpdump -n -e arp

In another window, run the code:

$ erl -pa /path/to/procket/ebin
Erlang R14B01 (erts-5.8.2) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.8.2  (abort with ^G)
1> carp:send({10,11,11,11}). % Use an address on your network

If the MAC address of the Erlang node is 00:aa:bb:cc:dd:ee, then on the other host you should see something like:

00:59:35.051302 00:aa:bb:cc:dd:ee > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp reply 10.11.11.11 is-at 00:aa:bb:cc:dd:ee

Check the ARP cache on the source node:

arp -an

The ARP entry may not exist. Since ARP caching is opportunistic, it is up to a host to decide whether it will optimize future connections by caching an unsolicited entry. To force an ARP cache entry on the remote host, ping the fake IP address:

ping 10.11.11.11

Then, in the Erlang shell, run carp:send/1. Run "arp -an" again on the remote host. The ARP cache entry for 10.11.11.11 should now be there.

? (10.11.11.11) at 00:aa:bb:cc:dd:ee [ether] on eth0

If you run tcpdump on the host doing the ARP'ing, you should see ICMP traffic for 10.11.11.11:

01:13:36.075040 IP 10.11.11.10 > 10.11.11.11: ICMP echo request, id 35604, seq 17, length 64
01:13:36.088794 IP 10.11.11.10 > 10.11.11.11: ICMP echo request, id 35604, seq 18, length 64
01:13:36.106572 IP 10.11.11.10 > 10.11.11.11: ICMP echo request, id 35604, seq 19, length 64

Since this IP address is not bound to any interface on your host, there will, of course, be no reply.

Poisoning the ARPs

On old networks using hubs or open networks using 802.11 access points, data is broadcasted to all the hosts. Running a packet sniffer displays the network activity for everyone, not just yourself.

Switched networks learn the MAC address of the host connected to the port of the switch and send data only to the recipient. ARP poisoning or spoofing fools other hosts on the network to send data to the host under your control. If your host spoofs the gateway, you'll also see the internet traffic. Obviously, if your host is not somehow routing, the packets will go nowhere, performing a denial of service on your network. But you will be able to see the data other hosts are sending.

Using the code we ran earlier, we can test ARP spoofing. You'll need 3 hosts: one doing the poisoning and two victims, a source and a target. The process is the same as above. For example, if 10.11.11.11 were a real host, we would have convinced 10.11.11.10 to send its data through our host.

I've put my experiment in progress with ARP poisoning, farp, on GitHub. farp works by replying to ARP requests with our host's MAC address. It can also optionally send out gratuitous arps as the gateway to speed up the process.