|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: TCP/BGP vulnerability - easier than you think
> > A significant number of BGP sessions will be with a source > > port of 11000, 11001 or 11002; BGP sessions are generally > > quite stable and Cisco routers start the source port at > > 11000. So attackers could cause enough disruption just > > targeting these three source ports. The other thing the > > attacker has to guess is which router established the BGP > > session. As to IPs which sessions exist on, they can guess > > from traceroute each inter-provider hop. > > Really? I certainly hope an attacker tries those three ports on a > router I know about. Looking at a random cisco router at a random NAP > with a significant number of peers, there are a total of zero session > on those ports. > > Wow, this attack is even easier to avoid than I thought! > > Thanx for proving my point.... OK, if you look at half a dozen routers from vendor C, do a 'sh ip bgp nei | in port', depending on the stability of your network and peering sessions I would expect at least 1 in 4 will be in the 11000 to 11099 range based on some slightly wider searching. Granted it's not "the port is always X", but it's also not true randomization, and most OSs have some constrained range of ports which will be used (eg. Linux which has a sysctl tunable "ip_local_port_range") and sequential scanning. Admittedly, on one large looking glass, I couldn't find any peers in the 11000 to 11099 range; however that range has been quite popular in stable production networks I have looked at. My initial scan covered routers with _very_ stable BGP sessions (up for months) - for non-multihop BGP, the sessions often come up just after router reboot and stay up for a very long time. A few sessions had numbers nowhere near this - which would imply that once you've killed the existing BGP sessions once, the new session is likely to use a harder to predict port number if the router has been up a long time. Unless you can also extract the current port numbers from the router somehow (remembering that most routers use sequential allocation); there are some cases where you may be able to trick a router into making an outbound tcp connection and look at the source port (if rsh is enabled or there's any other way to trigger an outbound connection). Also if the router is a looking glass or is connected to a looking glass you can find the port number of the looking glass session and you can then attempt to kill the looking glass session and see what port number it comes back at, giving you a couple of hints as to the port number other sessions may be at. > And how do you track a thousand passwords? Okay, maybe that is not too > hard. But how do you guarantee a thousand peers will never screw up > and forget, lose, fat-finger, etc. a single one of them? This one I > would really like to know, 'cause I sure as hell can't figure it out. The passwords are saved in your router config CVS repository. They are not encrypted, they are only encoded or stored in plain text, so you can recover (decode) them if you need to move between platforms. You can also store them in your tracking system or wherever else you store such data. Or in the worst case you can negotiate new passwords if you've lost your records. And if you're thinking of customer passwords, worried about saving passwords in your config repository and don't want to augment your customer information systems with the data -- then you can make some kind of non-reversible hash (eg. md5-based) to generate the passwords based on the two BGP peers' IP addresses. > > [*] in any reasonable implementation. it is possible some old > > implementation does this wrong, though. > > Guess IOS counts as both old and unreasonable. I buy that. > > Again with the agreement! Well, three out of four ain't bad. :) If this is true, and more CPU is used in checking a MD5 signature than in checking the ports and sequence number, then I'm sure it won't be long until someone logs a bug with Cisco to change the situation. David.
|