Cisco SMI: Still Tippin'

Intro

Configuration management is hard, expecially at scale. Cisco IOS and IOS XE software has a feature which allows for simpler deployment of a new switch, allowing for easy plug-and-play configuration. The feature is known as Cisco Smart Install (SMI), and makes it less painful to configure new switches.

The core of Cisco SMI is a network of Smart Install devices, a director, and any number of clients. The director acts as the manager for images and device configurations for clients. When a switch is brought online, the director will detect it, and begin configuring the device according to specifications. The key feature of this is that this network of SMI device is ad hoc, and as a result, there is no authentication, and implicit trust given by clients.

Back in 2017, there had been a number of vulnerabilities disclosed regarding Cisco Smart Install, leading to several CVEs and PoCs for exploiting an exposed SMI service. These allowed for DoS, configuration changes, and even a full rewrite of the firmware image on the device.

In 2018, a buffer overflow vulnerability was disclosed in Cisco SMI, leading to remote code execution on a given router. Cisco came out with an advisory about the vulnerability, and it was given a CVE. This upgraded the severity from “protocol misuse” to full blown vulnerability.

In April 2018, a US-CERT advisory was released regarding the discovery of Russian State-Sponsored actors targeting this specific vulnerability, and using it to attack critical infrastructure.

This vulnerability is easily exploitable, is being actively exploited, and can have devastating effects on networks for organizations, governments, and entire countries.

What’s out there?

Given all of this information, how many vulnerable devices do you think are still out there in the wild?

To put it simply…a lot. The shodan search “Cisco Smart Install Client active” yields over 50,000 results as of this writing.

Some of these results come and go, as devices are configured and quickly locked down. Many of them stay online for a while without the knowledge of the admins of the network.

What have I found?

I have found and disclosed a number of vulnerable Cisco switches to various organizations. These include government, defense, and tier-1 network targets, all of whom have had vulnerable devices sitting on their networks. This ultimately led me to writing about the lasting effects of this vulnerability for organizations who may be unaware, and researchers who are interested in network infrastructure.

What are the implications?

The routers with vulnerabilities that I have reported have typically been ones that are connected to things that appear to be on the sensitive side in terms of overall impact. If a malicious actor wanted to exploit these, there are a few approaches they could take.

The first stage would involve identifying the target. Connecting to port 4786 will inform an attacker if the SMI banner is visible. From there, the SIET tool can be used to determine if the target is vulnerable.

The following is a list of possible attack vectors for a Cisco SMI device once it is determined to be vulnerable.

DoS

The simplest thing an attacker can do is a Denial of Service. This can be done in a number of ways, including tampering with device configurations, and issuing commands to shut down the device.

The impact of this is immediate, anything that the router is responsible for routing will no longer have access to the internet.

Change Configuration

Changing the device configuration is also another trivial attack vector. The configuration files contain a lot of information. You can find network mappings, acls, passwords, certificates, and other parameters relevant to the network in a given config file.

Changes to this can be used for all sorts of nefarious purposes. Compromising certificates and keys, hijacking routing, and locking the administrators out of the switch.

GRE Tunnel

GRE tunnels can easily be configured by modifying the device configuration. GRE tunnels in hijacked SMI routers have been used to reroute DNS queries to an attackers infrastructure. Router level DNS hijacking on sensitive networks can have devastating effects that are not easy to detect.

Malicious Firmware

A feature of SMI is the ability for a SMI director to load a new firmware image onto a client device. There are many implications for loading a new image. While this might be the most challenging thing to pull off, it could be the most costly in terms of a persistence.

Remote Code Execution

An RCE is possible through a stack overflow when sending a discovery message to a given client. The size of the message is not properly checked by the device, leading to remote code execution. More information on the technical details and a PoC can be found here.

Why should I care?

This vulnerability has been known for over two years, and it is still quite common. Even in the wake of US-CERT advisories, vendor patches, and tools built to exploit this, many large organizations in all sectors continue to deploy vulnerable switches.

Taking a look at the Greynoise visualizer tool, we can get a better look at how many people are scanning for these devices as well.

There is still quite a lot of activity for this service, and some of my own honeypots have picked up activity on this port. Since there is widespread tooling for exploiting SMI, it’s likely that most attackers are simply scaling these tools.

What does an attack look like?

Depending on the tooling used, your typical attack will look something like this:

The first message is the command configure tftp-server nvram:startup-config, which attempts to start up the tftp server on the router with the system’s configuration file.

The second message is attempting to copy the running configuration file into flash memory, and then transfer it to a remote server over tftp. This command sequence is straight out of the SIET tool’s get-config option.

What can we do about it?

• Disable SMI if a switch is on a public network.
• Upgrade your switch.
• Report vulnerable devices on sensitive networks if you find them.

greetz

As always, thanks to my buddies at ThugCrowd for letting me rant and confirm my suspicions. Shoutout hermit, dnz, notdan, readme, sshell, protoxin, phreck, hexadecim8, casey @ bugcrowd, hackerone, Level3, and all the orgs who didn’t threaten me when I came to them with this information.

Special shoutout goes to Andrew Morris of GreyNoise for letting me use their sweet visualizer while it was still in development while researching this.