Introduction
The Data Plane (DP) ARP Cache Poisoning attack is the first attack, and the basis for the other attacks, featured in the paper “Exploiting Pitfalls in Software-Defined Networking Implementation”[1]. This attack results in the target host’s ARP cache being poisoned without the Software-Defined Network (SDN) controller observing the attack. This article will look at the attack in detail and the conditions necessary for the attack to be possible.
ARP and SDN
ARP Cache Poisoning, or ARP Spoofing, is a problem in SDN networks the same way it’s a problem in conventional networks. In-fact the attack can be carried out the exact same way. However, the outcome of the attack is slightly different when it comes to SDN. In general, the network controller can be expected to observe any ARP traffic being sent in the network. Controllers like ONOS and OpenDaylight install static flow rules in switches to make sure all ARP traffic is sent to the controller as a packet-in message. When this technique is used the controller will send received ARP messages straight to the switch adjacent to the destination host as a packet-out message. The switch then delivers the ARP message to the destination host by forwarding it out the relevant switch port. This way, no flow is actually installed in the network for that ARP traffic.
Other controllers, like Floodlight, employ a more reactive forwarding method for ARP traffic. When a host sends a new ARP message, a table-miss will occur on the adjacent switch and the switch will send the message to the controller as a packet-in. The controller then installs a flow in the network to allow that ARP message to go from the sender to the destination. A second flow is then installed for the ARP reply that follows. This method has the benefit of reducing DP to Control Plane (CP) traffic.
Regardless of which technique is used to handle ARP traffic, the controller should still end up observing all ARP messages. Some controllers have leveraged this fact to build applications designed to reduce network traffic by having the controller respond to ARP queries itself. Once the controller has seen an ARP reply from a host, it can answer any ARP queries for that host itself using the information it learned from the ARP reply. This is known as proxy ARP. Proxy ARP helps reduce the amount of traffic in the network and also speeds up the response time for ARP replies.
For proxy ARP to function, the controller needs to implement it’s own ARP cache for hosts in the network. Performing a conventional ARP Cache Poisoning attack will poison both the target host’s cache as well as the controller’s ARP cache. Now in some ways this is great because by poisoning the controller’s cache an attacker ends up affecting the ARP caches of any hosts the controller sends an ARP reply back to. However, if the controller was to implement static ARP mappings or a defence against ARP Cache Poisoning then the attack will be defeated. Moreover, the controller could use a technique to detect the attack and subsequently block any further traffic from the attacker. To avoid these defences the attack must be carried out without affecting the network controller. This is where the DP ARP Cache Poisoning attack comes in.
The Attack
The DP ARP Cache Poisoning attack allows an attacker to poison another host’s ARP cache without the controller observing the attack. In other words, the attack stays on the DP without affecting any CP devices (i.e the network controllers). The previous section detailed 2 ways that a controller can handle ARP traffic. This attack will work on the latter technique which Floodlight uses.
As discussed previously, this technique involves dynamically installing flows in the network for ARP traffic. The flow rules Floodlight installs in the switches look like the following:
NXST_FLOW reply (xid=0x4): cookie=0x20000000000000, duration=1.357s, table=0, n_packets=1, n_bytes=42, idle_timeout=5, idle_age=0, priority=1,arp,in_port=2, dl_src=9e:79:f1:97:f1:68,dl_dst=66:5b:51:bb:ae:eb actions=output:1 cookie=0x20000000000000, duration=0.359s, table=0, n_packets=0, n_bytes=0, idle_timeout=5, idle_age=0, priority=1,arp,in_port=1, dl_src=66:5b:51:bb:ae:eb,dl_dst=9e:79:f1:97:f1:68 actions=output:2
The above rules allow the ARP request to traverse the network and the ARP reply to get back. There’s a few important things to note about these rules:
- Matching traffic is not sent to the controller
- The match conditions are:
– Is ARP
– Has a particular Ethernet source MAC address
– Has a particular Ethernet destination MAC address
The above points are what make this attack possible. Those flow rules match on traffic which is ARP and has the correct source and destination Ethernet MAC addresses. This means that any information contained within the ARP message (e.g. hardware source address) can be modified and the ARP message will still match the flow! So an attacker could send a legitimate gratuitous ARP reply to their victim, causing the above flow rules to be installed, and then follow that up with another ARP message with a modified hardware source address and source IP, causing the victims ARP cache to be poisoned. The second ARP message will piggyback on the flow, preventing the message from reaching the controller.
The attack process is shown in Figure 1.
Steps:
1-6) The attacker first sends a legitimate gratuitous ARP reply to a host. The controller implements a flow to allow this message to traverse the network to the target host.
7) The attacker now creates a new gratuitous ARP reply. This message maintains details needed to traverse the flow which now exists in the network, but also contains a modified ARP header. The source IP and hardware source address are changed in order to poison the recipient’s ARP cache. The attacker sends this message to the target.
8-9) The crafted ARP reply piggybacks on the existing flow, which conceals the traffic from the controller. The message then reaches the host and poisons its ARP cache with the details in the modified ARP header.
This attack can be carried out with sdnpwn using the dp-arp-poison module.
[+] Module Name: dp_arp_poison
[+] Description: Poisons a targets ARP cache without the controller observing the attack.
Relies on flows being installed for ARP traffic and this traffic not being sent to
the controller by the flow.
[+] Usage:
Option Description Required
----------------- ------------------------------------------ ----------
-i | --iface Interface to use Yes
-v | --victim IP address of victim Yes
-vM| --victim-mac MAC address of victim No
-t | --target-ip IP address to poison in victims ARP cache Yes
-m | --mac MAC address to insert in the victims cache Yes
-l | --loop Continue poisoning until stopped No
-d | --delay Delay between packets when looping No
The following command will execute the module and perform the attack:
./sdnpwn.py dp-arp-poison -i eth0 -v 192.168.56.102 -t 192.168.56.254 -m 'de:af:be:ef:de:ad'
This will poison the ARP cache of host 192.168.56.102. After the attack the entry for IP address 192.168.56.254 will be mapped to ‘de:ad:be:ef:de:ad’. The dp-mitm module extends this attack to perform the attack against several hosts and place the attacker in a Man in the Middle (MitM) position.
Mitigation
The most obvious way to defeat this attack is to make sure all ARP traffic is delivered to the controller. Controllers which provide proxy ARP functionality will do this anyway. Controllers which install flows in the network for the ARP traffic should ensure that the messages are still sent to the controller.
Conclusion
The DP ARP Cache Poisoning attack enables an attacker to poison the ARP cache of a target host without the controller observing the attack. This can allow the attack to avoid any prevention mechanisms designed to prevent such an attack. The attack can be prevented by ensuing that controllers observe all ARP traffic in the network. Future articles will look at how this attack can be extended to perform a firewall bypassing port scan known as the Phantom Host Scan, and a Denial of Service attack known as the Phantom Storm.
References
[1] https://www.researchgate.net/publication/306064144_Exploiting_pitfalls_in_software-defined_networking_implementation