Last updated at Fri, 29 Sep 2017 18:07:10 GMT
By Deral Heiland, Research Lead, and Brian Tant, Senior Consultant, of Rapid7 Global Services
Over the past several years while conducting security research in the area of Simple Network Management Protocol (SNMP) and presenting those findings at conferences around the world we are constantly approached with the same question: “What are the best practices for securing SNMP”?
The first thing to remember about SNMP versions 1, 2, and 2c is that the community strings used for authentication are communicated in cleartext over the network and can potentially be captured while in transit and used to conduct subsequent attacks against other internal network infrastructure. In most cases, the first thing to consider when remediating this concern is: Enable and configure SNMPv3
Properly implementing SNMPv3 is not for the faint of heart, but is highly recommended and should be considered if the security of SNMP usage in the environment is approached seriously.
Whether the decision is made to leverage SNMP v3 or not, the next most pressing consideration is the premise that SNMP community strings are essentially used as “Passwords” for device authentication within the context of an SNMP management infrastructure. Engineers tasked with managing SNMP configurations often over look this concept, which leads to the creation of easily guessable community strings that fall outside the organization's password complexity policies. At a minimum any SNMP community string should meet the following requirements in order to assure it is not a liability to the organization's network security posture.
- Community strings should be at least 20 characters or greater in length.
- Community strings should contain characters from all four of the following categories:
- Uppercase characters (A through Z)
- Lowercase characters (a through z)
- Base 10 digits (0 through 9)
- Special characters (for example, &, $, #, %)
- Community strings should not be based upon or contain a dictionary word.
- Community strings should not contain or be based upon corporate culture or associated vernacular.
- Public and private community strings should not match, nor should any discernible similarities exist between the two community strings.
Many question the necessity of such measures, but there is a legitimate basis that these considerations are built upon. The SNMP protocol does not have an account lockout facility so a malicious actor can typically employ password-guessing attacks indefinitely without fear of locking out the community string. If short community strings or those flawed through predictable simplicity are relied upon, the odds of a malicious actor successfully brute-forcing a system's community string greatly increases. Also, when matching or very similar public and private community strings are used, it is possible to more readily identify a private community string by examining its public counterpart. This is a common scenario often encountered during a penetration test. For example, a public community string of “AcmeRO” may be identified during an assessment. Because “RO” is often an abbreviated expression of “Read Only” it is reasonable to infer that that the private community string is most likely “AcmeRW”. Such a simple gaffe, often made to simplify network management, can result in a devastating attack against the organization. Unfortunately, the practice of using company names, sports teams, and common dictionary words prefixed to RO to denote “Read Only: and RW to designate a “Read Write” community string remains prevalent. As networks grow in scope and complexity, the importance of using complex community strings becomes increasingly paramount.
Last but not least, when considering the security of SNMP management practices: Apply different SNMP community strings to devices having different security levels
To elaborate, critical devices such as routers, switches and firewall appliances should not share the same community strings as components of lesser importance such as IP cameras, managed power strips, or any other secondary device in use on the network. Often these devices are prone to a number of security issues, such as using default passwords or being subject to authentication bypass vulnerabilities. A malicious actor may be able to capitalize on these types of exposures to extract the community string name from the device and use it to attack operationally significant infrastructure components.
Targeting embedded devices for default or easily guessed passwords has become a regular part of our penetration tests. The typical targets encountered using default passwords include IP cameras, UPSs, or managed power strips. Nearly as often, such devices are running configured instances of SNMP, allowing the community strings to be extracted. If the community strings are reused, a skilled malicious actor can enumerate the running configuration of more sensitive network infrastructure components such as certain brands of routers, switches and firewalls. The advisable remediation is to remove this trust relationship between devices of different security levels and roles by setting different community strings on them based on their criticality.
In conclusion, if your organization leverages SNMP in any significant capacity, Rapid7 recommends moving forward with implementing these recommendations. In doing so, the likelihood of compromise via SNMP will be greatly reduced.