Abusing ICMPv6 to manipulate network traffic

 In this blog I will explain the mechanics of the attack that uses ICMPv6 protocol, more particularly, two of its message types to redirect the network traffic over an arbitrary device.

ICMPv6 shares a lot of common functionality with its v4 equivalent. Even the two attacks I will describe in more details have been proven in the ICMPv4. It seems the reason that ICMPv6 remains vulnerable to them is vendors view that the desired behavior of the operating systems is such by design. 

The foundation of the attacks are two message types - Router Advertisement and ICMP Redirect. As one may infer, Router Advertisement is essentially telling the network devices that a new (attacker's) device is a router for a designated route. ICMP Redirect missuses the capability of ICMP protocol to redirect traffic over an alternative IP address if the network gets congested, for example, and the default gateway is no longer the best route.

Let us start with an example of Router Advertisement where an attacker device declares itself as being a legitimate router for an arbitrary route. In my attacks , I will use the "dead:beef" route as it's easy to remember. In the diagram below, this is the ATTACK 1.  

The attack constructs the Router Advertisement ICMP message , but it manipulates the parameters of the message so that the desired router for our "dead:beef" route is an attacker's device. I use Python in conjunction with Scapy, a network library, to construct the packet from the scratch as we need to modify some lower-OSI layer headers.

When the above script is run, the "dead:beef" route gets happily injected into the IPv6 routing table of the victim operating system. Both CentOS and Windows OSes were tested.

The above figure shows the injection into the CentOS , however, the same logic applies equally to the Windows. With a slight modification of the prefix being injected, you can still identify the newly inserted entry into the Windows routing table.

The root cause of these two vulnerabilities is the default setting of the kernel parameters that allow processing of the ICMP messages in question.  In Windows, the feature is labelled "Router Discovery" and is enabled by default.

Similarly, in CentOS it is the kernel parameter "accept_ra". Note they are set to "1" meaning "enabled".

The next attack is an example of ICMP Redirect whose logic is depicted in the below figure.

When user wants to load an external web page and the network is congested, for example, the default gateway may broadcast ICMP message instructing devices to reroute their traffic via an alternative gateway. This is an example of a network traffic redirection.

For this attack we are constructing a slightly different ICMP message, this time using the Redirect packet flag. Note the "tgt" now points to our attacking machine equipped with network monitor to view the traffic.

These two attacks can be combined so that we first instruct the victim to send the traffic for a particular route to the attacker's device and then superimpose another attack that will redirect the injected route over yet another device of our choice. A single attacking device can be used for both attacks - in my setup I had two attacking devices.

The first one was the Kali Linux simulating the legitimate routing device whereas the other device was Windows 10 with wireshark that was simulating the attacker's interception. When both attacks chained, the packet flows look as follows:

After experimenting with the attacks and trying to understand the underlying conditions that allowed those exploits, i contacted Microsoft Security to check their view. Apparently, this is by design.

Even though I do understand that every routing engine must have the capability to update its state based on the changes that may happen to the network topology, I am not sure that "regular" operating systems such as Linux and Windows should have these capabilities turned on by default.