The title is no longer required.
Really no excuse for not using SSH these days.
It looks like Cisco won't be chasing up a partnership with WikiLeaks: it's combing the "Vault7" documents itself, and has turned up an IOS / IOS XE bug in more than 300 of its switch models. The vulnerability is in the Cisco Cluster Management Protocol (CMP) in IOS and IOS XE. The protocol passes around information about …
Really no excuse for not using SSH these days.
Sure there is... from the management handbook.... "We've never done it that way before." Usually followed by the PHB saying something along the line of: "And I do need to Telnet in and keep an eye on things.".
"Well I tried connecting via SSH and it warned me about the security of some 'unknown fingerprint'. So I tried again with telnet and - whaddayaknow? - no security warnings there! You kids knock yourselves out with this unsafe SSH stuff and I'll get on with the known, proven, security of good ol' telnet..."
I find it funny that you use mongo as a nick... and speak about security!
How long did the spooks know of these problems? It appears they did not tell anyone if Cisco is using a document dump to find the problem.
Could Cisco afford to be behaving any differently?
I judge Cisco way more than anyone else in that regard.
That's not some super-secret hackery.
They have damn unencrypted open-packet interface enabled by default whether or not an option is explicitly set, that accepts commands from ANY packet.
Why the hell is that not just sheer negligence in creating a product?
That someone found it "before they did"? No... someone found the UTTER TRIPE that they were pushing as an interface to a modern device and just left in there.
fix that component!
This is one of those functional results from having all processes documented that no one credits. First you have to have someone research/investigate and write it all down. At that point some quiet words might be had, resulting in an updated release. Else during the documentation review with at least one warm-brained tech in attendance there might be a burst of laughter, and a change order. Otherwise, when the code/mental defect is eventually found, the words aren't quiet and nobody is laughing.
Who's looking for the "apocryphal stories" in your company?
Yes yes, I'm sure Cisco is shocked, utterly shocked, to discover there are 'bugs' like this in its routers.
I'm sure Cisco is shocked,
Looking for the bright side, I presume the vulnerability doesn't work above 2,000m.
Formerly coming out of US embassies.
Now also coming out of your router.
On the link in the article to the Cisco Advisory -
on the page top right - remember to log out after reading it. ;-)
"Until fixes are available, Cisco says Telnet should be disabled in favour of SSH."
What do people not understand about Telnet - username and password and all data sent in clear over the wire....
Telnet should ALWAYS be disabled in favour of SSH......
We were preaching this way back 15 years ago. (Jericho Forum Commandment #4)
I was recommending it 20 years ago. and trashing FTP too.
Sadly - we still have idiots asking us to turn on both......
Just log into any IOS router and use the online CLI help to marvel at the swathes of protocols and features that you've a) never heard of and b) nobody uses. Many of which were probably written 15 years ago with little or no thought of security. It doesn't surprise me at all that there are vulnerabilities in there. It's practically impossible to remove features from IOS, so the crud just builds up over time.
Think yourself lucky, when learned my trade we had to be able to set up all of those odd little protocols etc. Decnet/Banyan Vines/Appletalk/ IPX/SPX etc. etc.
So much easier now it's all just IP - you'd think they'd be able to focus their efforts and reduce the number of vulnerabilities. Personally I would like to see *one*department dedicated to simplifying an existing (reasonable) feature-set, rather than trying to stick bits on here, there and everywhere all the time.
How many people think this is a newly discovered flaw that Cisco found in the Vault7 documents?
Now, how many people think this is a known exploit that Cisco only went public with because it was exposed in the Vault7 documents?
Pardon me while I get my tinfoil hat....
"Newly discovered" for me. Here's why; no one uses Telnet. Not since the 1990s. If you do allow it, you are; 1) doing yourself no favors and probably think firewalls will protect you from any problems, and 2) a clueless network wonk who got the job because you're cheap, not good. No one uses Telnet for any valid reason. You can do everything with ssh and still have a modicum of security to protect your sessions. Last time I touched a Cisco router was in the 1990s, and we turned off Telnet as one of the first configurations. I don't even use it at home. Everything has ssh available, and it is dead easy to setup and maintain. There is simply no valid case for telnet being available as a session protocol in a modern networking device, other than to fall back on when people forget/loose their ssh keys (which isn't necessary since you can merely pop the box with the motherboard "wipe me" setting, then reload the config you should have saved already, or setup new if those keys in the config file are not known). And for new installs that need hand-holding, then you turn it off. Cisco knows this, and this is why this bug went unnoticed for years; no one using "best practices" for their data center would allow this to run without some really great exception, and even then I seriously doubt any use of Telnet as being a valid method to connect to anything, other than as a back-to-back connection for simple, local setup usage. It's a holdout from the past and really should be unbundled, not merely set to disabled by default. For ssh, do the key exchange/build at the system setup via the serial console, or use a key configured from the factory, then force the update when the system is setup. And don't get me started on their use of tftp as the transport for the remote config save. :P
Biting the hand that feeds IT © 1998–2018