CVE-2017-3881 How to Mitigate CIA Vault 7 Exploits on Your Cisco Switches

The threat
Two weeks ago WikiLeaks released Vault 7, a large collection of documents that they claim were taken from the CIA. While the CIA has not confirmed this release, there’s little question that the leaked information comes from a nation state level intelligence service and contains extensive details regarding exploits and tradecraft targeting a wide variety of service providers, vendors, and equipment. Wikileaks has thus far attempted to redact detailed exploit information and has announced their intention to work with the impacted parties to address these vulnerabilities.

Cisco appears to have been reviewing the documents and CVE-2017-3881, the Cluster Management Protocol Remote Code Execution Vulnerability is their first major report referencing the vault 7 release. This vulnerability allows an unauthenticated attacker with access to a listening Telnet port on one of the impacted devices to execute commands on the device or reload it. While the advisory indicates that IOS XE is affected the vast majority of affected devices appear to be switches running IOS. You can find details on the advisory and impacted devices in their advisory.

Are you vulnerable?
If your switch is running the CMP protocol and you are listening for Telnet connections, then you are vulnerable to any device that can reach your switch using Telnet. You can validate if a device has the CMP service using the following command:

switch#show subsys class protocol | include ^cmp cmp Protocol 1.000.001

If you are running the CMP protocol, you should now validate your vty configuration to see if Telnet is enabled and accessible. Use the command: sh run | sec ^line vty in order to retrieve the line vty configuration. You should assume that, if you don’t see transport input ssh in any line vty configuration block, the switch is listening for the Telnet service. If no access-class is used to limit access, then the switch is vulnerable to any device that can reach it. Otherwise, devices permitting Telnet in the access-class will be able to exploit this vulnerability. Here are two vulnerable examples:

switch#sh run | s ^line vty line vty 0 4 logging synchronous login authentication vty length 0 transport input all line vty 5 15 logging synchronous login authentication vty transport input all switch2#sh run | s ^line vty line vty 0 4 logging synchronous login authentication vty length 0 line vty 5 15 logging synchronous login authentication vty

If you have a large number of devices in your environment you’ll want to use scripting to validate the state of the devices in your environment and later to rectify these issues. Take a look at one of our latest articles: Use of Scripting to Identify Devices Affected by the Clock Signaling Field Notice to get you started. If you need help implementing it our Managed Service Team is ready to help.

How to protect your network

While waiting for Cisco to release updated firmware that addresses this issue we can use configuration changes to mitigate it. There are two possible approaches, the first and preferred is to simply disable Telnet but this may not be possible in your environment. We summarize the two approaches below.

How to disable Telnet
If you don’t need to use Telnet to access your devices, you can use the following command to disable it. Ensure that you have access to the switch using ssh and that it’s functioning, then run the following commands:

switch#conf t Enter configuration commands, one per line. End with CNTL/Z. switch(config)#line vty 0 15 switch(config-line)#transport input ssh switch(config-line)#end

Use ACLs to restrict access

You may not be able to completely disable Telnet access as it may be required for specific purposes. Legacy tooling that only supports Telnet, devices that don’t support ssh or for any other reason.

While Cisco indicates that you can defend against this threat using ACLs they refer to a document that uses interface ACLs to restrict Telnet access. Our analysis indicates that the switch behavior is the same if the ACL is applied to the interface or on the access-class for the vty lines (RST generated on access). As such, we suggest using an access-class rather than attempting to configure ACLs on all possible routed interfaces. In this example, we want to permit Telnet from our management address space (10.1.0.0/24 ) and deny it from all other networks. We will not restrict non-Telnet access at this time. However it’s always a best practice to limit administrative access using all protocols to devices and networks that require it.

switch(config)#ip access-list extended Telnet-block switch(config-ext-nacl)# permit tcp 10.1.0.0 0.0.255.255 any eq Telnet switch(config-ext-nacl)# deny tcp any any eq Telnet switch(config-ext-nacl)# permit ip any any switch(config-ext-nacl)#line vty 0 15 switch(config-line)#access-class Telnet-block in