Hijacking HSRP Status

Only for educational purposes!!!

I am sure that you are going to love this post :-)

When tacking about Hackers, We always talk about protecting our network from external people, what about the one on the internal network? In fact internal hackers possess high risk then then external hackers. Because then are already in your network and have access to it.

Today we are going to see about hijacking a HSRP state. It's simple and effective. Once a HSRP state is hijacked the entire network / subnet for which the router is acting as a First hop redundancy will be down.

First hop redundancy protocols including HSRP, VRRP, and GLBP can be used to emulate a virtual router on a subnet, typically host's default gateway. However, if preventive measures are not taken, 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 posses this vulnerability, but the following example demonstrates exploitation of only HSRP.


Scenario

Consider the following topology, in which routers R1 and R2 provide a redundant virtual default gateway at 1.1.1.1 for LAN hosts in the 1.1.1.0/24 subnet.

1.1.1.0/24

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

R1:

interface FastEthernet1/0
ip address 1.1.1.253 255.255.255.0
standby 1 ip 1.1.1.1
standby 1 priority 100

R2:

interface FastEthernet1/0
ip address 1.1.1.254 255.255.255.0
standby 1 ip 1.1.1.1
standby 1 priority 90

Lets verify the HSRP status on R1 router by using the show standby command:

R1#show standby
FastEthernet1/0 - Group 0
  State is Active
      1 state changes, last state change 00:00:02
  Virtual IP address is 1.1.1.1
  Active virtual MAC address is 0000.0c07.ac00
      Local virtual MAC address is 0000.0c07.ac00 (v1 default)
  Hello time 3 sec, hold time 9 sec
      Next hello sent in 0.644 secs
  Preemption disabled
  Active router is local
  Standby router is 1.1.1.254, priority 90 (expires in 9.104 sec)
  Priority 100 (default 100)
  IP redundancy name is "hsrp-Fa1/0-0" (default)

Both routers exchange HSRP hello packets at the default interval of three seconds. Because these packets are multicast to 224.0.0.2  they are flooded to all hosts in the multicast 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.

To change the state of the active router to standby, 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 millisecond.
Priority - We'll need to claim a higher priority than the active router to take over.
Group Number - This value tells the multicast packet is for which HSRP Group.

A number of tools are available to emulate an HSRP router, but for this example we'll use HyenaeFE. HyenaeFE provides a very convenient interface for constructing & transmitting packets.

HyenaeFE begins repeatedly transmitting the packet we built onto the wire. Aside from the source IP address and increased HSRP priority, our injected packets are virtually identical to the ones coming from R1  & R2 (including the default authentication string of "cisco"). When R1 & R2 begins receiving our forged hellos, we see R1 transition state from "active" to "speak", then from "speak" to "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.

R1
*Feb 10 07:36:24.883: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 0 state Active -> Speak
*Feb 10 07:36:25.711: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 0 state Speak -> Standby

R2
*Feb 10 07:36:26.803: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 0 state Standby -> Listen

The output of "show standby" on R1 & R2 show the HSRP status is hijacked:

R1#show standby
FastEthernet1/0 - Group 0
  State is Standby
    4 state changes, last state change 00:00:26
  Virtual IP address is 1.1.1.1
  Active virtual MAC address is 000c.299d.da4e
    Local virtual MAC address is 0000.0c07.ac00 (v1 default)
  Hello time 3 sec, hold time 9 sec
    Next hello sent in 0.360 secs
  Preemption disabled
  Active router is 1.1.1.2, priority 110 (expires in 8.556 sec)
  Standby router is local
  Priority 100 (default 100)
  IP redundancy name is "hsrp-Fa1/0-0" (default)


R2#show standby
FastEthernet1/0 - Group 0
  State is Listen
    2 state changes, last state change 00:00:46
  Virtual IP address is 1.1.1.1
  Active virtual MAC address is 000c.299d.da4e
    Local virtual MAC address is 0000.0c07.ac00 (v1 default)
  Hello time 3 sec, hold time 9 sec
  Preemption disabled
  Active router is 1.1.1.2, priority 110 (expires in 6.292 sec)
  Standby router is 1.1.1.253, priority 100 (expires in 7.068 sec)
  Priority 90 (configured 90)
  IP redundancy name is "hsrp-Fa1/0-0" (default)

At this point, we have achieved an eventual denial of service attack, as neither router will answer ARP requests for 1.1.1.1 as long as we are seen as the active router. Although our example ends here, we could opt to begin answering ARP requests for 1.1.1.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.


Solution
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 f1/0
R1(config-if)# standby authentication md5 key-string spiceup.net.in

R2(config)# interface f1/0
R2(config-if)# standby authentication md5 key-string spiceup.net.in

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:


Hijacking HSRP Status video tutorial. 

Leave your comment below