By Christian Motta
The Simple Network Management Protocol (SNMP) is a widely-used protocol for device monitoring and management, and has gone through a number of iterations since its inception. The three major versions currently available for users to choose from are versions 1, 2c, and 3. Versions 1 and 2c require only a plaintext community string to be defined in order to function, while version 3 offers support for user-based authentication and the use of secure data transport protocols. SNMP can be a very useful tool for administrators, as it not only provides an easy, standardized way to receive device status information, but can also be used to configure some devices as well.
However, one can also immediately see major security issues with this protocol, especially in environments using versions 1 and 2c. It effectively allows users access to device information and configuration with only a plaintext string to limit their visibility. Surely, version 3 helps to address these concerns with better authentication and data transit security, but versions 1 and 2c remain the most popular versions in use today. Being able to view the configuration data of a targeted device would already make an attacker’s job substantially easier, but being able to push configuration to one without the need for its credentials would be a dream come true for any adversary. One may believe that the ability to push configuration changes via SNMP would be disabled on the vast majority of devices in use today, however, that is also not the case. Many Cisco products, for example, allow administrators the option to configure them via SNMP, and allow them to choose which version they wish to use. Theoretically, then, it should be possible to take control of a poorly-configured Cisco appliance with relative ease.
For the purpose of testing this hypothesis, a Cisco 2900 series router will be used as the test device. Cisco routers are a common staple in many network infrastructures, so they should help to clearly illustrate why SNMP should not be used if the experiment is successful. The router used in this experiment was configured with SNMP v2c, with an insecure community string, read-write functionality enabled, and a number of traps in place that allow for configuration data to be sent to a specific host.
Router SNMP Config Snippet:
As shown in the above screenshot, Cisco has implemented a clever solution to prevent simply anyone from receiving SNMP data by forcing the administrator to specify the device that will do so. However, this will only prevent an attacker from using their device as the entry point, and not stop someone already in the network from pivoting further. Assuming an attacker was successfully able to gain access to the authorized system, NMAP will help to make guessing the community string a trivial affair.
NMAP comes with a built-in script called “snmp-brute” that will attempt to guess the community strings of any devices with SNMP open that are encountered during a scan. While it has a built-in wordlist that it uses to this end, it is rather short and appears to mostly contain the most common string names available. In this experiment, the theoretical system administrator has used a string that is not a common community string, but will make anyone familiar with password attacks nervous nonetheless. This is no problem for our attacker, however, as snmp-brute allows the user to select their own wordlist to use. In this case, NMAP’s built-in “passwords.lst” was used in the attack.
As demonstrated above, NMAP was able to find the community string within minutes. While the device was scanned directly in this instance in the interest of time, this attack will work for NMAP scans of any size. Now that the attacker knows the community string, they can begin interfacing with the device using the snmpset program that should be installed on any machine set to manage devices via SNMP. The process for receiving device configuration information over SNMP is relatively simple, requiring the use of a single management information base (MIB) entry. The MIB in question is the “ciscoConfigCopyMIB” MIB, and it is designed to transmit config information to and from Cisco devices by defining variables for the various object identifiers (OID)s within the MIB hierarchy. The process our attacker uses to transfer the router’s configuration data to a TFTP server of their choosing is carried out with just a few commands, and they immediately receive the configuration upon command execution.
Stolen Configuration Snippet:
As shown, the configuration is transferred and stored in plaintext and can easily be edited by the attacker. The full configuration was transmitted, so theoretically any edits could be made, or a premade file with all the attacker’s ideal configuration can be substituted in. The router enable password is not needed at any part of this process, and the attacker now has it even if changing the configuration required it. For this experiment, however, the attacker simply wants to play a prank on the on the administrator to make them aware of the flaws in their security, and simply changes the router’s hostname in the configuration file.
Changed Configuration File:
Using snmpset and the same MIB as before, the attacker uploads the new configuration file from the TFTP server.
Configuration Upload Process:
As before, the configuration is transferred immediately after the last command is entered, and is eventually changed on the router after a few short seconds.
Router Configuration Change Occurring:
While the attack in this experiment is relatively benign, anything could have been changed on that router to make persistence or another pivot further into the network easier. The attacker did not need any device credentials, just the IP address and plaintext community string gathered from methods even the most novice of adversaries would have no problem using.
This experiment is not meant to a critique of Cisco’s products, as other manufacturers allow for configuration changes to be made over SNMP as well. A Cisco router was only used in this experiment due to its ready availability, and this experiment is not attempting to make the claim that Cisco devices are somehow fundamentally insecure, as such a claim would be completely false. The criticism, rather, is of the protocol itself. While this example is rather simplistic, similarly insecure configurations are hardly uncommon in practice, and such an attack would potentially be just as trivial to carry out on an actual target. SNMP, especially versions 1 and 2c, are simply insecure and put networks at unnecessary risk for attack. Administrators should simply avoid using SNMP if at all possible, as there are other, more secure methods for remotely managing and monitoring devices. If SNMP absolutely must be used, then version 3 should be implemented due to its added security. There is really no reason to use versions 1 or 2c today, and doing so is tantamount to intentionally opening one’s network up to attackers, as this experiment has hopefully demonstrated.
- “Catalyst 2960 and 2960-S Software Configuration Guide, 12.2(55)SE – Configuring SNMP [Cisco Catalyst 2960 Series Switches].” Cisco. Cisco, 18 Oct. 2016. Web. 02 May 2017.
- Ellingwood, Justin. “Contents.” An Introduction to SNMP (Simple Network Management Protocol) | DigitalOcean. DigitalOcean, 18 Aug. 2014. Web. 14 Mar. 2017.
- Pickering, Philip, Gorjan Petrovski, Patrik Karlsson, and Gioacchino Mazzurco. “NSEDoc.” Snmp-brute NSE Script. NMAP, n.d. Web. 14 Mar. 2017.
- Semperboni, Fabio. “Fabio Semperboni.” CiscoZine. CiscoZine, 15 July 2014. Web. 02 May 2017.
- Semperboni, Fabio. “Fabio Semperboni.” CiscoZine. CiscoZine, 28 May 2014. Web. 02 May 2017.
- Zobel, Daniel, and David Fabian. “How Do SNMP, MIBs and OIDs Work?” How Do SNMP, MIBs and OIDs Work? | Paessler Knowledge Base. Paessler, 9 Feb. 2010. Web. 02 May 2017.