Penetration Testing mailing list archives
Re: Testing other prot's and layers.
From: Sam Quigley <osquigle () cs uchicago edu>
Date: 11 Jun 2002 19:32:20 -0500
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/
Current thread:
- Testing other prot's and layers. Oliver Petruzel (Jun 11)
- Re: Testing other prot's and layers. Sam Quigley (Jun 12)
- <Possible follow-ups>
- RE: Testing other prot's and layers. Oliver Petruzel (Jun 12)