Cisco Smart Install Exposure

Last updated at Tue, 26 Sep 2017 13:43:48 GMT

Cisco Smart Install (SMI) provides configuration and image management capabilities for Cisco switches. Cisco’s SMI documentation goes into more detail than we’ll be touching on in this post, but the short version is that SMI leverages a combination of DHCP, TFTP and a proprietary TCP protocol to allow organizations to deploy and manage Cisco switches. Using SMI yields a number of benefits, chief among which is the fact that you can place an unconfigured Cisco switch into an SMI-enabled (and previously configured) network and it will get the correct image and configuration without needing to do much more than wiring up the device and turning it on. Simple “plug and play” for adding new Cisco switches.

But, with the great power and heightened privileges comes great responsibility, and that remains true with SMI.

Since its first debut in 2010, SMI has had a handful of vulnerabilities published, including one that led to remote code execution (CVE-2011-3271) and several denial of service issues (CVE-2012-0385, CVE-2013-1146, CVE-2016-1349, CVE-2016-6385).

Things got more interesting for SMI within the last year when Tenable Network Security, Daniel Turner of Trustwave SpiderLabs, and Alexander Evstigneev and Dmitry Kuznetsov of Digital Security disclosed a number of security issues in SMI during their presentation at the 2016 Zeronights security conference. Five issues were reported, the most severe of which easily rated as CVSS 10.0, if risk scoring is your thing. Or, put more bluntly, if you leave SMI exposed and unpatched and have not followed Cisco’s recommendations for securing SMI, effectively everything about that switch is at risk for compromise. Things get even more gnarly quickly when you consider what a successful attack against a Cisco switch exposing SMI would get an attacker. Even an otherwise well-protected network could be compromised if a malicious actor could arbitrarily reroute a target’s traffic at will.

In direct response to last year’s research, Cisco issued a security response hoping to put the issue of SMI security to bed once and for all. They effectively claim that these issues are not vulnerabilities, but rather “misuse of the protocol”, even while encouraging customers to disable SMI if it was not in use. True, this largely boils down to a lack of authentication both in some of the underlying protocols (DHCP and TFTP) as well as SMI itself, which is a key part of achieving the aforementioned installation/deployment simplicities.

However, every SMI-related security advisory published by Cisco has included recommendations to disable SMI unless needed. Most recently, they’ve provided various coverage for SMI abuse across their product lines, updated the relevant documentation that details how to properly secure SMI, and released a scanning tool for customers to use to determine if their networks are affected by these SMI issues.

To further help Cisco customers secure their switching infrastructure, they’ve also made available several SMI related hardening fixes:

• CSCvd36820 automatically disables SMI if not used during bootup
• CSCvd36799 if SMI is enabled it must show in the running config
• CSCvd36810 periodically alerts to the console if SMI is enabled

Ultimately, whether we call this protocol a vulnerability or a feature, exposed SMI endpoints present a very ripe target to attackers. And this is where things get even more interesting. Given that up until recently there was no Cisco provided documentation on how to secure SMI and no known tools for auditing SMI, it was entirely possible that scores of Cisco switches were exposing SMI in networks they shouldn’t be without the knowledge of the network administrators tasked with managing them. Sure enough, a preliminary scan of the public IPv4 Internet by these same original SMI researchers showed 251,801 systems exposing SMI and seemingly vulnerable to some or all of the issues they disclosed. The Smart Install Exploit Tool (SIET) was released to help identify and interact with exposed SMI endpoints, which includes exploit code for a variety of the issues they disclosed.

As part of Cisco’s response to this research, they indicated that the SIET tool was suspected in active attacks against organizations’ networks. A quick look through Rapid7 Labs’ Project Heisenberg for 2017 shows only minimal background network noise on the SMI port and no obvious large-scale scanning efforts, though this does not rule out the possibility of targeted attacks.

As with many situations like this in security, it's like a case of “if you build it, they will come” gone wrong, almost a “if you design it, they’ll misuse it.” There are any number of ways a human or a machine could mistakenly deploy or forget to secure SMI. Until recently, SMI had little mention in documentation, and, as evidenced by the three SMI related hardening fixes, it was difficult for customers to identify that they were even using SMI in the first place. Plus, even in the presence of a timely patching program, any organization exposing SMI to hostile networks but failing to do their security due diligence are easy targets for deep compromise. To top it all off, by following the recommended means of securing SMI when it is actually being used for deployment, you must add specific ACLs to control who can speak to SMI enabled devices, thereby severely crippling the ease of use that SMI was supposed to provide in the first place.

With all of this in mind, we decided to reassess the public Internet for exposure of SMI with several questions in mind:

1. Have things changed since the publication of the SMI research in 2016 and the resulting official vendor response in 2017?
2. Are there additional clues that could explain why SMI is being exposed insecurely?
3. Can Rapid7 assist?

The methodology we used to assess public Internet for SMI exposure is almost identical to what the Zeronights researchers used in 2016, except that after the first-pass zmap scan to locate supposedly open SMI 4786/TCP endpoints, we utilized the logic demonstrated in Cisco’s smi_check to determine if the endpoint actually spoke the SMI protocol. Our study found ~3.2 million open 4786/TCP endpoints, the vast majority of which are oddly deployed SSH, HTTP and other services, as well as security devices. It is worth noting that while the testing methodologies between these two scans appear nearly identical, both are relying on possibly limited public knowledge about the proprietary SMI protocol. Future research may yield additional methods of identifying SMI. Using the same logic as in smi_check, we identified 219,123 endpoints speaking SMI in July and 215,317 endpoints in a subsequent scan in August 2017.

Answering our first question, we see there was a ~13% drop in the number of exposed SMI endpoints between the Zeronights researcher’s original study and Rapid7 Labs’ Sonar scan in July of 2017, but it is hard to say what the cause was. For one, the composition of the Internet has changed in the last year. Two, Sonar maintains a blacklist of addresses whose owners have requested that we cease scanning their IPs and it is unknown if the Zeronights researchers had a similar list, which means that there were likely a few fundamental differences in the target space between these two disparate scans.

So, despite a history of security problems and Cisco advising administrators to properly secure SMI, a year later things haven’t really changed. Why?

Examining SMI exposing IPs by country, as usual it is no surprise that countries with a large number IPv4 IPs and significant network infrastructure are at the top of those exposed:

Repeating this visualization but examining the organizations that own the IPs exposing SMI, a possible pattern appears -- ISPs:

Unfortunately this is where things get a little complicated. The data above seems to imply that the bulk of the organizations exposing SMI are ISPs or similar, however that is also an artifact of how the attribution process happens here. In cases where a given organization is its own ASN and they expose SMI, our reporting would attribute any of the IPs that that ASN is responsible for to the organization in question. However, in cases where a given organization is not its own ASN, or if it uses IP space that it doesn’t control, for example it just gets a cable/DSL/etc router from their ISP, then the name of that organization will not be reflected in our data.

Proprietary protocols are interesting from a security perspective and SMI is no exception. Being specific to Cisco switches, you’ll only find this in Cisco shops that didn’t properly secure the switch prior to deployment, so there are limited opportunities for researchers or attackers to explore this. While proprietary protocols are not necessarily closed, SMI does appear that way in that there is almost no public documentation on the protocol particulars beyond what the Zeronights researchers published in 2016. Despite the lack of documentation at the time, these researchers employed a simple method for understanding how the protocol works and it turned out to to be highly effective -- exercising SMI functionality while observing the live protocol communication with a network sniffer.

There are several areas for future research which may provide value:

• When properly secured, including applying all the relevant IOS updates and following Cisco’s recommendations with regards to securing SMI, what risks remain in networks that utilize SMI, if any?
• When improperly secured, are there are additional risks to be explored? For example, what about the related SMI director service that exposes 4787/TCP?
• Are there safer or quieter ways to carry out the attacks described by the Zeronights researchers such that more accurate vulnerability coverage could exist?
• Is there a need for vulnerability coverage similar to SIET’s in Metasploit?
• What is current state of the art with regards to post-compromise behavior on network switches like this? What methods are (or could) attackers employ to establish advantageous footholds in the networks and devices serviced by a compromised switch?

In order to ensure that Rapid7 customers are able to identify assets exposing SMI in their environments, we have added SMI fingerprinting and vulnerability coverage to both Metasploit as of September 1 in auxiliary/scanner/misc/cisco_smart_install, and InsightVM as of the August 17, 2017 release via cisco-sr-20170214-smi.

Interested in this research? Looking to collaborate? Questions? Comments? Leave them below or reach out via research@rapid7.com!