SkipNavigation
US-CERT
American Flag
  Vulnerability
Notes
Database

Search Vulnerability Notes

Vulnerability Notes Help Information

Report a Vulnerability

 
 View Notes By
  Name

ID Number

CVE Name

Date Public

Date Published

Date Updated

Severity Metric



 Other Documents
  Technical Alerts

Technical Bulletins

Alerts

Security Tips

Vulnerability Note VU#228186

Hot Standby Router Protocol (HSRP) uses weak authentication

Overview

A denial-of-service vulnerability exists in the Hot Standby Router Protocol (HSRP) .

I. Description

HSRP is a protocol designed to provide transparent recovery of routing services when failures occur. Quoting from RFC2281 (the RFC describing the Hot Standby Router Protocol):

    The Hot Standby Router Protocol, HSRP, provides a mechanism which is designed to support nondisruptive failover of IP traffic in certain circumstances. In particular, the protocol protects against the failure of the first hop router when the source host cannot learn the IP address of the first hop router dynamically. The protocol is designed for use over multi-access, multicast or broadcast capable LANs (e.g., Ethernet). HSRP is not intended as a replacement for existing dynamic router discovery mechanisms and those protocols should be used instead whenever possible . A large class of legacy host implementations that do not support dynamic discovery are capable of configuring a default router. HSRP provides failover services to those hosts.

The following diagram depicts the topology of an IP network with two routers configured to use HSRP.


    Our thanks to Cisco for permission to use this diagram.
      HSRP-enabled routers operate by exchanging multicast messages amongst themselves that advertise their priority levels. By exchanging these messages, the participating routers determine which one of them is the default active router. The default priority level is typically 100, so if one of the participating routers is configured to have a priority of 101, that router will be the default active router. All HSRP-participating routers send a "hello" message using multicast every three seconds. If the default active router fails to send a "hello" message, the standby router with the next-highest priority will assume the role of being the active router. Because of this design flaw, it is possible for an attacker located on the same network segment as the routers participating in HSRP to disrupt network traffic. The vulnerability is best summarized in RFC2281:
        This protocol does not provide security. The authentication field found within the message is useful for preventing misconfiguration. The protocol is easily subverted by an active intruder on the LAN. This can result in a packet black hole and a denial-of-service attack. It is difficult to subvert the protocol from outside the LAN as most routers will not forward packets addressed to the all-routers multicast address (224.0.0.2).

      II. Impact

      An attacker located on the same LAN segment as the routers using HSRP can disrupt legitimate network traffic resulting in a denial-of-service attack against the network infrastructure for which the participating routers are responsible for.

      III. Solution

      The CERT/CC is currently unaware of a practical solution to this problem.

      Workaround

      Use HSRP in combination with IPsec as described in Advanced IPSec Deployment Scenarios.

      Systems Affected

      VendorStatusDate NotifiedDate Updated
      CiscoVulnerable13-Dec-2001

      References

      http://www.faqs.org/rfcs/rfc2281.html
      http://www.securityfocus.com/bid/2684
      http://www.cisco.com/warp/public/619/3.html
      http://www.cisco.com/warp/public/619/hsrpguidetoc.html
      http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c/ipcprt1/1cdip.htm#xtocid1715023
      http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs009.htm#xtocid122331

      Credit

      The CERT/CC thanks Cisco Systems for their help in understanding this vulnerability.

      This document was written by Ian A. Finlay.

      Other Information

      Date Public:98-03-01
      Date First Published:2001-12-13
      Date Last Updated:2001-12-18
      CERT Advisory: 
      CVE-ID(s):CAN-2001-0741
      NVD-ID(s):CAN-2001-0741
      US-CERT Technical Alerts: 
      Severity Metric:6.33
      Document Revision:85

      If you have feedback, comments, or additional information about this vulnerability, please send us email.
       

       
      Page Corner Image
      Copyright 2001 Carnegie Mellon University
      Disclaimers and copyright information
      Get a PDF Reader