From: Sam Quigley (osquigle@cs.uchicago.edu)
Date: Tue Jun 11 2002 - 20:32:20 EDT
It's not clear what you're testing *for*. HSRP is inherently
insecure, assuming you can get arbitrary packets onto the LAN where
the HSRP is being spoken. The RFC (2281 - (1)) has more info, but to
quote it:
7 Security Considerations
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).
All you need to do to shut down the link is to inject an HSRP packet
claiming a higher priority (110 will do, as most cisco-trained folk
will start with 100) from some non-existant router. The non-existant
router will be elected as active, and will receive all traffic,
resulting in a complete loss of communication. (Ok, so HSRP is
"authenticated" -- via a plaintext password. So, to exploit this, you
need write access to the wire as well as the password, or just
read/write access to the wire. If you have no read access, it can't
be hard to brute-force the password, though it could be slow: no
response is generated to falsely-auth'd packets, but (from what I've
seen) no alarms are raised either, so you can just keep trying...)
VRRP is smarter, and can use password hashes to prevent this sort of
havoc. Can does not mean does: VRRP can use no authentication,
plain-text authentication, or hashed authentication; of course, the
first two offer no protection when the attacker has access to the
wire. VRRP's RFC is here (2). (It should be noted that VRRP really is
*smarter* about this: it checks that TTL fields are 255; if a packet
has been forwarded from outside the LAN, it will have a TTL of <255,
and will be ignored.)
Similar problems exist in most routing protocols, so even if HSRP and
VRRP aren't in play, an attacker may be able to screw around with false
RIP/BGP/OSPF/whatever packets.
The wire-access issue is useless, though. If the attacker has access
to the wire, then she can do all kinds of crazy things, from
simple sniffing and gratuitous ARPs to all kinds of crazy session
hijacking and sniping. The only time this stuff should come into play
is when the firewalls surrounding the router LAN don't block packets
looking like HSRP/VRRP/etc. packets. So that's what needs to be
checked, not the fact that HSRP implementations are (by definition)
insecure from the wire.
And, to answer your question more directly, as far as I know, no
products test this stuff directly because there is nothing to be
gained by doing so. Unless you're trying to check Cisco's (or
whoever's) *implementation* of the protocol (ie, checking for
overflows and whatnot within the packet), there's really not much to
do. Just note the configuration, the firewall rules around the LAN,
and start writing the report. (If you are, however, checking the
vendor implementations, I'd love to hear any results you find....)
Hope I've helped,
-sq
(1) http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2281.html
(2) http://www.ietf.org/rfc/rfc2338.txt
>>>>On Tue, 11 Jun 2002 16:17:06 -0400, "Oliver Petruzel" <oliver.petruzel@corbett-tech.com> said:
OP> Does anyone have any actual testing software or scripts to test VRRP and HSRP specfically?
OP> Or does everyone do it manually if asked to do so?
OP> Which COTS or open-source scanning products offer layer 2 or 3 testing modules?
OP> thanks ahead of time!
OP> ./oliver p.
----------------------------------------------------------------------------
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:
https://alerts.securityfocus.com/
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:22 EDT