Remote unauthenticated OS re-install is a feature, not a bug, says Cisco Cisco's taken umbrage at accusations that its Smart Install (SMI) protocol is vulnerable to abuse. The problem – if there is one, because “it's a feature, not a bug” – is that if netadmins are using SMI to auto-configure switches installed in branch offices they need to know it doesn't enforce authentication. If an attacker …
Yet another example of something with the moniker 'Smart' nailed to it, which is anything but smart.
I've resolved to try and avoid buying anything labelled as Smart as generally they are not fit for purpose due to basic design and/or security flaws being present. Security as an afterthought as usual, and shame on Cisco because they should know better.
Anything for your convenience is also for theirs.
In the mean time have fun with this.
https://github.com/marcan/takeover.sh
A script to completely take over a running Linux system remotely, allowing you to log into an in-memory rescue environment, unmount the original root filesystem, and do anything you want, all without rebooting. Replace one distro with another without touching a physical console.
They do know better!
Cisco switches are not bought by klooless home users. They are bought and installed by people who are allegedly IT professionals.
If IT "professionals" leave kit behind with open access from the internet and no control plane policing then they are not very professional.
IT as a profession is like medicine was 300 years ago. Too many idiots that really don't know what they are doing but who call themselves "IT professionals" and charge accordingly.
As you say, it basically is TFTP - the SmartInstall is just marketing dribble for allowing a switch to be connected to a suitable device (either another SmartInstall-capable Cisco switch or Cisco router) and detect the model/software version to deploy similar to the process for Cisco IP phones before that was deemed a security issue and IP phones allowed the use of encryption/certificates to improve security....
From what I can tell, the SmartInstall code only works if there is no config on the device, so it needs to either be exploited when the switch is first installed or someone needs to connect to the switch (using credentials that force a change during the initial install) and delete the config/reload the switch - if you can do that, you don't need SmartInstall to change the switch config.
Is this going to be the next IoT security disaster? Nope....
On a par with Brig. Gen. Jack D. Ripper "Exceeding his authority" when he starts WWIII in Dr. Strangelove.
"Oh it's alright, only another bit of Cisco kit can do this" is in fact patent BS.
Here's a hint. No device on internet that can be completely re imaged should allow that to happen without any authentication. Nor should it have hard coded account details. If you've f**ked it up that much you should have physical access to either the device or its paperwork, which means you have its serial number. That should be part of a process of generating a one time password.
Incompetent design or Ciscos way of helping a TLA "We won't install any backdoors, you'll have to write them and install them yourselves, but we won't stop you."
Perhaps some high security Cisco users should dump that code and find out if there have been any surprise software updates.
....because I actually agree with Cisco on this one, at least a little.
OK so It's not unreasonable to argue that this is a feature that should perhaps be off by default to prevent a gaping security hole existing if you weren't aware of the feature.
But equally it could be quite a useful function, and if you use it having to turn it on on every switch you deploy before you deploy it would be a not insignificant pain in the ass, and it isn't really a security problem if you properly configure your switches and secure the rest of your network as you should be doing anyway.
There is a case to be made that you shouldn't be deploying network infrastructure equipment unless you understand all the ways it can be accessed, and have secured them all sufficiently.
The process should still enforce some level of authentication however, I agree with the earlier poster that physical access or original paperwork should be required if a OTP is to be generated.
Unauthenticated access or hard coded, default, credentials should be barred by default from all enterprise class kit, regardless of any "smart" title flung at it. This is generally the point of buying enterprise in the first place...
"Unauthenticated access or hard coded, default, credentials should be barred by default from all enterprise class kit"
What's the point in having authentication hard coded when it's new and there's no config on the device?
A router/switch with no config won't be accessible remotely, only via the console (and you can reset the config register by console anyway), but it won't be on your network because it will have no config on it!
If someone has the ability to configure routing protocols and such, then they're more than capable of putting decent authentication on them whilst they're creating the config.
You can't blame the customers for this. Cisco could ship their kit secure by default - and let the pros and wannabes break security as they wish. If they really can't manage that they should probably stop selling stuff they don't understand and can't build properly.
"And when they come up with a compromise they are hammered for that. Everyone wants it the way they want it."
If the only way to prevent a convenience being a security nightmare is to turn it off completely you haven't compromised: you are presenting choices as a dilemma when there is no sensible reason to do so.
There are so many ways of avoiding this: physical switch on the device, unique password derived from the serial number, etc. etc. Shipping as insecure by default is not acceptable.
Did you read the article? Cisco said if you don't need it, turn it off.
Whilst I am all for making things secure, lets not forget that this feature is for new, unconfigured switches. Clue is in the name of the feature, install.
First paragraph from cisco:
Smart Install is a plug-and-play configuration and image-management feature that provides zero-touch deployment for new switches. You can ship a switch to a location, place it in the network and power it on with no configuration required on the device.
So really the idea is you ship a pallet of new switches (or replace one an identical SKU one for example) to your DC and the director flashes correct IOS imagea and your pre-created config. Then you turn the feature off. As much as I like things secure, there is not really much need for authentication in this situation as the kit is effectively unprovisioned until Smart Install has done its bit.
Doesn't sound like a bad way at all to install bunch of new kit (or replace broken kit).
I've been using Smart Install since 2011.
Let me explain how this works:
1. There are three characters in this plot: The Director, the slave and the TFTP server. The Director and the TFTP can be a single physical unit.
2. Straight out of the box, a slave appliance only knows of a single VLAN, VLAN 1. It doesn't know anything else.
3. Smart Install requires CDP to be enabled.
4. When a slave gets connected to a Director, the Director interrogates the slave. Some information the Director looks for are: What IOS is the slave running and what is the exact model number of the appliance.
5. The first thing the Director will do is push the configuration file into the slave's startup-config.
6. Next, the Director will upgrade the IOS of the slave.
7. The Director will then command the slave to reboot.
8. (Optionally) After the reboot, the Director can run some more commands when the slave re-joins the Smart Install.
All of this without anyone touching the keyboard. It is automatic.
Since using Smart Install, I've added "no vstack" command in my configuration templates. Another thing we've done is VLAN 1 is only present in that network. Nowhere else is VLAN 1 allowed anywhere. There's another thing too: The Smart Install network can only be reached using the Management port of the Director. There is no other way in.
Putting authentication in the process does not make any sense.
The only way to "abuse" this is when VLAN 1 is used in the production network and one must have physical access to the Director or the TFTP server (where all the configuration templates are stored).
Smart Install, in our work, is vital and critical to our work. In 2012, we deployed over 600 Cisco switches all of which were configured using Smart Install. Whether we configure one, ten or 100 switches, we will continue to use Smart Install and continue to find ways to improve it.
CDP is insecure, but on by default
SMI is insecure but on by default
Telnet is insecure but on by default
VLAN1 is on by default
all are insecure, but aid provisioning, but like switchzilla says, if you don't use it, turn it off!
once it pops up in your highly expensive Cisco Prime deployment, run the lockdown script.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
