MAC address poisoning attack

The goal of this article is making  ARP poisoning attack (Part1) and configure Cisco switch to mitigate ARP poisoning attack (Part2).

You can read more theory behind ARP poisoning/spoofing attack on this page:

http://su2.info/doc/arpspoof.php

Part 1 - ARP poisoning attack on unsecured network infrastructure

The picture below shows a testing topology.  Click image to enlarge it.

Figure 1 ARP poisoning testing toplogy

1. Victim (PC A) needs to send packets outside  its VLAN 100. PC A has already learnt IP address of default router (172.17.100.1) from DHCP server but it doesn't know  MAC address of default router.

Figure 2 MAC address of default router is missing in  ARP cache of PC A

2. Victim sends ARP request to get MAC address default router. ARP request is L2 broadcast and switch sends it to every port in VLAN 100 so it can be easily captured on every host in VLAN 100.

Figure 3 ARP request sent from PC A  to VLAN 100 captured on PC B (attacker's PC)

3. Default router receives ARP request from PC A  and updates its ARP cache with MAC and IP address of PC A.  Router sends ARP reply to PC A as unicast (only PC A receives ARP reply message). PC A updates its ARP cache with MAC address of default router.

Figure 4 ARP cache of PC A with default router MAC and IP address

Figure 5 Captured ARP request and reply messages on PC A

4. Now it is attacker's  turn. He starts to  sends ARP reply messages to PC A with IP address of default router 172.17.100.1 and attacker's own MAC address (0011.0983.2173) in ARP reply.

[brezular@Vrescott ~]$ sudo arpspoof -i eth0 -t 172.17.0.1 172.17.100.1

0:11:9:83:21:73 0:1a:4b:79:70:b8 0806 42: arp reply 172.17.100.1 is-at 0:11:9:83:21:73
0:11:9:83:21:73 0:1a:4b:79:70:b8 0806 42: arp reply 172.17.100.1 is-at 0:11:9:83:21:73
0:11:9:83:21:73 0:1a:4b:79:70:b8 0806 42: arp reply 172.17.100.1 is-at 0:11:9:83:21:73
0:11:9:83:21:73 0:1a:4b:79:70:b8 0806 42: arp reply 172.17.100.1 is-at 0:11:9:83:21:73
0:11:9:83:21:73 0:1a:4b:79:70:b8 0806 42: arp reply 172.17.100.1 is-at 0:11:9:83:21:73
0:11:9:83:21:73 0:1a:4b:79:70:b8 0806 42: arp reply 172.17.100.1 is-at 0:11:9:83:21:73
0:11:9:83:21:73 0:1a:4b:79:70:b8 0806 42: arp reply 172.17.100.1 is-at 0:11:9:83:21:73
0:11:9:83:21:73 0:1a:4b:79:70:b8 0806 42: arp reply 172.17.100.1 is-at 0:11:9:83:21:73
0:11:9:83:21:73 0:1a:4b:79:70:b8 0806 42: arp reply 172.17.100.1 is-at 0:11:9:83:21:73

Example 1 ARP reply generated on attacker PC - 172.17.100.1 with attacker MAC address 0:11:9:83:21:73

Attacker keeps attacking with many ARP replies sent from attacker's PC (PC B) to PC  A.

Figure 6 PC A (victim) receiving many ARP replies with default router IP address  and MAC address of PC B

Victim is forced to change ARP cache - to bind default router IP address 172.17.100.1 with  attacker's MAC address - 0011.0983.2173.

Figure 7 Poisoned victim's ARP cache - attacker MAC address tied with default router MAC address

5. PC A has wrong ARP entry - he thinks that attackers PC is right place to send packets destined for default router.  If attacker convinces default router that his PC is PC A he makes successful man-in-the-middle attack. All the traffic between PC A and default router goes trough attacker's PC.

[brezular@Vrescott ~]$ sudo arpspoof -i eth0 -t 172.17.100.1 172.17.0.1

0:11:9:83:21:73 0:a:f4:34:92:0 0806 42: arp reply 172.17.0.1 is-at 0:11:9:83:21:73
0:11:9:83:21:73 0:a:f4:34:92:0 0806 42: arp reply 172.17.0.1 is-at 0:11:9:83:21:73
0:11:9:83:21:73 0:a:f4:34:92:0 0806 42: arp reply 172.17.0.1 is-at 0:11:9:83:21:73
0:11:9:83:21:73 0:a:f4:34:92:0 0806 42: arp reply 172.17.0.1 is-at 0:11:9:83:21:73
0:11:9:83:21:73 0:a:f4:34:92:0 0806 42: arp reply 172.17.0.1 is-at 0:11:9:83:21:73
0:11:9:83:21:73 0:a:f4:34:92:0 0806 42: arp reply 172.17.0.1 is-at 0:11:9:83:21:73

Example 2 ARP replies are sent from attacker PC to default router (172.17.100.1) - PC A IP address (172.17.0.1) is tied with  attacker MAC address (0:11:9:83:21:73)

Figure  8 ARP debugging on default router

Figure 9 show ARP cache of default router. It believes that PC A has MAC address 0011.0983.2173.

Figure 9 ARP cache of default router- 172.17.0.1 is tied with MAC address of attacker PC  0011.0983.2173

All the traffic from PC outside VLAN 100  firstly goes to attacker PC and from attacker PC to default router. Similarly traffic from default router to PC A goes trough attacker PC. Attacker makes successful man-in-the middle attack - he can start packet sniffer and capture traffic.

There is captured traffic on attacker PC in figure 10. Normally destination MAC address of default router (000a.f434.9200) should be in Ethernet frame header instead of MAC address attacker PC (0011.0983.2173).

Figure 10 Traffic sent from  PC A to default router captured on attacker PC

Part 2 - Mitigate ARP poisoning attack

Switch can stop ARP poisoning attack with inspecting  ARP reply messages going trough its switchports  and filtering ARP reply messages which have different IP-MAC binding  than switch expects.

To do that switch  compares sender IP address and sender MAC address in every ARP reply message to known IP-MAC bindings in DHCP snooping binding table. IP-MAC bindings can be statically configured  by administrator or dynamically learned when IP DHCP snooping feature is enabled.

The method that dynamically compares sender IP address and sender MAC address to known IP-MAC bindings from IP DHCP snooping binding table is called Dynamic ARP inspection (DAI).   If there is a conflict between what switch finds in ARP reply message comparing to what it finds in IP DHCP snooping binding table, switch  drops ARP reply message and log message is generated.  ARP reply checking is done only on  untrusted interfaces  there is not ARP messages checking on trusted interfaces.

By default all the interfaces are configured as untrusted after IP ARP inspection is enabled for particular VLAN.

Now configure Dynamic ARP inspection on Catalyst 3550 switch and make some tests:

a) Configure IP DHCP snooping

3550-I(config)#ip dhcp snooping

3550-I(config)#ip dhcp snooping vlan 100

b) Check if entries exists in IP DHCP snooping binding table

DHCP snooping feature was created for mitigate rogue DHCP server in network.  We don't have any rogue DHCP server in our network  but dhcp snooping feature  helps us to build IP-MAC bindings table inspecting DHCP messages going trough switch:

Figure 11 Catalyst 3550 IP DHCP snooping table

c) Enable IP ARP inspection for VLAN 100 and define trust uplink port Fa 0/1

3550-I(config)#ip arp inspection vlan 100

3550-I(config)#int fa 0/1

3550-I(config-if)#ip arp inspection trust

These commands enable Dynamic ARP inspection on all the ports in VLAN 100 except the port Fa 0/1 which is defined as trusted and no ARP reply messages inspection is done on this port.

d) Testing ARP inspection function before attack

I do ping from attacker PC (172.17.0.2) to PC A. (172.17.0.1). Because no arp entry  for PC A exists in attacker PC  ARP cache ARP (Figure 12), ARP request is broadcasted from Attacker PC to all ports in VLAN 100 and ARP reply message with MAC of PC A (00:1a:4b:79:70:b8) is sent from PC A to attacker PC (Figure 13).

Figure 12 ARP cache of attacker PC

Figure 13 ARP request and reply messages between attacker PC and PC A and vice versa, captured on attacker PC

Similarly PC A doesn't know MAC address of attacker PC so it has to send ARP request with IP 172.17.02 to VLAN 100 as L2 brodcast (FFFF.FFFF.FFFF). Attacker PC replies with own MAC address (00:11:09:83:21:73).

In both cases any ARP reply filtering isn't done because entries in ARP reply messages match IP DHCP snooping binding table (Figure 11)

e) Testing ARP inspection function during the attack

Attackers starts generating ARP reply messages wih own MAC address  tied with IP address of default router 172.17.100.1 (Figure 14, 15)

Figure 14 Attacker sends ARP replies to PC A  MAc address (00:1a:4b:79:70:b8) with default router IP 172.17.100.1 and attacker MAc address (00:11:09:83:21:73)

Figure 15 shows captured ARP reply messages with Wireshark on attacker PC.

Figure 15 Captured ARP fake replies on attacker's PC

Switch doesn't match attacker MAC address (00:11:09:83:21:73)  from ARP reply with  default router IP address 172.17.100.1 and loging message appears on console (Figure 16)

Figure 16 Catalust 3550 - Invalid ARP reply on attacker switchport Fa 0/4

Switch drops invalid ARP replies coming from attackers switchport Fa 0/4. Only ARP replies are dropped, switch forwards other attacker traffic without issue.

Captured ARP traffic on PC A shows that fake ARP replies are not received on PC A (Figure 17).

Figure 17 No fake ARP replies are received on PC A

End.