HSRP MD5 Calculation

[brvkj]

Hello,

I know if MD5 authentication is not enabled then HSRP is vulnerable to a takeover attack. However, I am struggling to understand how MD5 prevents this. Perhaps someone more knowledgeable can correct any of my mistakes, but as I understand:

The same shared key is given to each router. This key is converted into an MD5 hash which is added to the outgoing packet. How is the MD5 hash derived from the key? If it is simply key -> hash then nothing would stop an attacker from just reading this MD5 hash, copying it, then replaying it to forge packets in the same way plain text authentication is abused. So, I assume there has to be more that goes into calculating this MD5. What other data is used? How do other routers verify the MD5 hash is valid?

I've tried looking through cisco documentation but I'm not finding any details anywhere.

[MHM Cisco World]

1- HSRP is use to protect your network from rogue router which try to become active and redirect traffic to other path making traffic expose to hacker 
2- hacker can disrupt traffic 

attacker can decrypt MD5, indeed that right, MD5 is not so secure, but you can use chain which add some more secure by change md5 hash each interval

MHM 

[brvkj]

Thank you, but I already understand points 1 and 2, which is why I am asking my question:
What data is HSRP using to calculate the MD5 hash? And how do the routers verify that this hash is valid?

Can you explain the below in more detail? How does MD5 chain work?

you can use chain which add some more secure by change md5 hash each interval

---

[MHM Cisco World]

Peer(1)-Peer(2)

Peer1 send hsrp hello include hsrp active router IP as 1.1.1.1' this hello will hash using md5 and this hash add to hello packet and send to Peer2

Hacker in middle capture traffic change active IP to be 5.5.5.5 and resend to Peer2

Peer2 receive packet and de-hash the packet' here hello message is ignore since hash use hello with active IP 1.1.1.1 but de-hash is hello with IP 5.5.5.5 so in not identical and ignore.

Now you will ask attacker can capture packet and add new hash and resend to Peer2

Here come to play Key-chain 

The Peer1 instead of hash only hello it will hash hello + key' 

Now Peer2 when receive hello it de-hash using key which is unknown from hacker so any change to hello will make Peer2 ignore it.

MHM

[MHM Cisco World]

MD5 hash for Hello from R1 not same as R2 
because the info inside the hello is different (Sender IP)

and as rule all hash not include the IP header it only hash the packet (i.e. Hello packet without IP header)

[David Ruess]

Hello,

MD5 is not as strong as other hashing mechanisms. Same with EIGRP Classic mode. It uses MD5 as an authentication protocol. While it's not the best it's supposed to counteract an attack if someone just connected another HSRP device. Without any authentication they have the possibility to take over your Active router. With authentication they would as you say" have to sniff your network to get the hash and break it".... which in my opinion means you have way bigger problems than your HSRP MD5 authentication. Your HSRP router will ignore any Hello packet not configured for the same authentication string. It's just to help mitigate rogue unauthenticated devices.

As far as hashing, if both HSRP routers have the same password configured they use the same MD5 process to hash/un-hash to authenticate their peers to make sure each has the valid password.

Hope this helps.

-David

[Joseph W. Doherty]

Cannot say for sure how Cisco is using the MD5 digest, but what would be expected is the digest is computed with key plus something else.  I.e. any one digest would (more or less) only be useful for the packet received.

However, if you can find a key collision that would allow you to generate the expected digest, then you can forge packets.

[Joseph W. Doherty]

BTW, in the other replies I see mention of the receiving host using terms like "decrypt" and "un-hash" to validate the digest.  Generally such hashing algorithms are considered one-way, i.e. hash cannot be undone, so what receiver does is also hash the same input and compare its results to what it received; match good, no match bad.

@MHM Cisco World mentioned using keychains which, in theory, limits how long a compromised key is valid.  It's good if it takes longer to compromise a key then how long it's used, otherwise it's less useful.

[brvkj]

What input from the packet is combined with the key to generate the MD5? Is it the entire packet? Is it only certain fields like the IP?

In my network I am seeing two routers, each broadcasting hello messages. Router 1 is using the exact same hash every time. Router 2 is using the exact same hash every time. These two hashes are different from each other though.

If one bit in the packet were to change would the hash become invalid? Or could some bits be changed and that same MD5 be used for replay?

[Joseph W. Doherty]

---

@brvkj wrote:

What input from the packet is combined with the key to generate the MD5? Is it the entire packet? Is it only certain fields like the IP?

---

Again, personally, I don't know.  However, it would be useless if it was just computed on the key alone, because then, you're correct, you could just copy the hash.

---

@brvkj wrote:

In my network I am seeing two routers, each broadcasting hello messages. Router 1 is using the exact same hash every time. Router 2 is using the exact same hash every time. These two hashes are different from each other though.

If one bit in the packet were to change would the hash become invalid? Or could some bits be changed and that same MD5 be used for replay?

---

Well, assuming R1 and R2 are using the same key, something else is being added that creates a different hash.  Very possibly, it's what @MHM Cisco World describes in his lab example, the change in source IP.

If just one bit in the input to the hash in changed, very, very likely, the digest would differ.  (In fact, one of the purposes of a message digest is to confirm a message that was received was not corrupted in transit.)

In theory, yes, some bits might be changed, and same digest generated, but again that's very, very unlikely.  Plus, for an attacker, they often want specific bits to be changed, which results in a different digest value, which, unless they know the original key, or a like collision key, will generate a digest different that the receiver expects.

What we can do, is "replay" identical valid packets.  So, doing that, we possibly could "spoof" a backup HSRP from not taking over from a failed active gateway.

The important takeaway, a hashing algorithm, like MD5, makes it difficult to mimic a valid source unless you can generate valid digests.  MD5, though, is considered "weak" in comparison to later hashing algorithms, i.e. it's more likely someone can generate valid MD5 digests without the original key.

If HSRP using MD5 is a concern, there are somethings you can do, using it, to make it "better".  First use the longest possible randomly character password.  Second, use a key chain to start using a new key, hopefully, before the current key is broken.

Besides using a "better" hashing algorithm, it supported, there are other things you can do to "protect" your gateways, and/or quickly determine if they've been tampered with.

However, I also often remind people, on any security issue, cost to protect should be weighed against value of what you're protecting.  Often I've seen the extremes, i.e. security is pretty much totally ignored or items of little value are overly secured.

[Ramblin Tech]

As an aside, authentication was removed from VRRP as it was considered to not be adding value to the protocol. If you buy into the IETF's position on VRRP, then it probably renders any questions of MD5 on HSRP moot.

From RFC 9568:

9.  Security Considerations

   VRRP for IPvX does not currently include any type of authentication.
   Earlier versions of the VRRP specification included several types of
   authentication, ranging from no authentication to strong
   authentication.  Operational experience and further analysis
   determined that these did not provide sufficient security to overcome
   the vulnerability of misconfigured secrets, causing multiple Active
   Routers to be elected.  Due to the nature of the VRRP protocol, even
   if VRRP messages are cryptographically protected, it does not prevent
   hostile nodes from behaving as if they are an Active Router, creating
   multiple Active Routers.  Authentication of VRRP messages could have
   prevented a hostile node from causing all properly functioning
   routers from going into the Backup state.  However, having multiple
   Active Routers can cause as much disruption as no routers, which
   authentication cannot prevent.  Also, even if a hostile node could
   not disrupt VRRP, it can disrupt ARP/ND and create the same effect as
   having all routers go into the Backup state.

[Joseph W. Doherty]

I would say IETF is correct FHRP authentication doesn't preclude "disruption" but don't agree with the reasoning that since it cannot, there's no benefit to precluding an illicit router from becoming the active router (which they admit it does preclude).

Laugh, interesting a reason given for not having any authentication is due to misconfiguration errors.

Basically, they've decided the benefit of having any authentication is out weighed by the cost of providing it.  Although not stated, I suspect part of the cost considered is the on-going crypto "arms race".

Whether Cisco will someday also consider authentication for its proprietary FHRPs likewise unnecessary remains to be seen as it now might be considered a "feature"; so I would be hesitant to say it's moot.  However, it indirectly, I believe, supports my prior reply comment about security features usage value should be considered.