from managed to mangled - · pdf filefrom managed to mangled: snmp exploits for network...

From Managed to Mangled: SNMP Exploits for Network Management Systems

Deral Heiland, Research Lead, Rapid7, Inc.

Matthew Kienow, Independent Security Researcher

Tod Beardsley, Senior Security Research Manager, Rapid7, Inc.Rapid7, Inc. | September 7, 2016

mailto:deral_heiland%40rapid7.com?subject=

mailto:mkienow%40inkoii.com?subject=

mailto:todb%40rapid7.com?subject=

Executive SummaryIntroduction to NMSsIntroduction to SNMPXSS Injection Attacks ExplainedPassive SNMP Agent XSS Injection

Proven XSS Attacks via SNMP Agent ResponsesR7-2015-18, XSS via SNMP Agent Responses in Spiceworks DesktopR7-2015-19.1, XSS via SNMP Agent Responses in Ipswitch WhatsUp GoldR7-2015-20.1, XSS via SNMP Agent Responses in Castle Rock SNMPcR7-2016-02, XSS via SNMP Agent Responses in ManageEngine OpUtilsR7-2016-11.1, XSS via SNMP Agent Responses in CloudView NMSR7-2016-13, XSS via SNMP Agent Responses in Paessler PRTGR7-2016-14.2, XSS via SNMP Agent Responses in Opmantek NMIS

Active SNMP Trap XSS InjectionProven XSS Attacks via SNMP Traps

R7-2015-19.1, XSS via SNMP Trap Messages in Ipswitch WhatsUp GoldR7-2015-20.1, XSS via SNMP Trap Messages in Castle Rock SNMPcR7-2015-21, XSS via SNMP Trap Messages in Opsview MonitorR7-2016-11.2, XSS via SNMP Trap Messages in CloudView NMSR7-2016-12, XSS via SNMP Trap Messages in Netikus EventSentryR7-2016-14.1, XSS via SNMP Trap Messages in Opmantek NMIS

Format String Attacks via SNMPFormat String Attacks, ExplainedProven Format String Attacks via SNMP

Testing MethodologyBuilding an Attack SNMP Client

Generating Custom SNMP Agent ResponsesGenerating Custom SNMP Trap Messages

Conclusions

CONTENTS

From Managed to Mangled: SNMP Exploits for Network Management Systems

| Rapid7.com From Managed to Mangled: SNMP Exploits for Network Management Systems 3

This paper explores attacking Network Management Systems (NMSs) over the Simple Network Management Protocol (SNMP), a protocol used extensively by NMSs to manage and monitor a wide variety of networked devices. Three distinct attack vectors are explored:

1. Passively injecting Cross-Site Scripting (XSS) attacks over SNMP agent-provided data, which is passed unprocessed from the SNMP server service and rendered on an NMS web-based administration console.

2. Actively injecting XSS attacks over SNMP trap alert messages, intended for NMS consoles.

3. Format string processing on the NMS web management console, when format strings passed unprocessed from SNMP agent-provided data.

While user-provided input is a common design flaw described by The MITRE Corporation as CWE-201, the thirteen vulnerabil-ities across nine different vendors discussed here are all a result of a lack of validation of machine-provided input. Machine-to-machine communications often escape the scrutiny afforded to more typical user-to-machine communication, and as a result, the NMSs described here were initially released as failing to adequately validate data delivered via SNMP. These varied failures to inspect resulted in exposing NMS web-based administration consoles to persistent XSS and a format string exploit.

All nine of the vendors were notified of these issues by Rapid7 well before the publication of this paper, and they worked with Rapid7 researchers to ensure that all of the reported vulnerabilities were patched in later versions of the affected products. Users of these products are urged to ensure they are running the latest versions of the software.

EXECUTIVE SUMMARY 01

1 https://cwe.mitre.org/data/definitions/20.html

https://cwe.mitre.org/data/definitions/20.html


Network Management Systems, or NMSs, are software (and occasionally, hardware) systems designed to discover and monitor network entities, including both endpoint machines such as servers, desktops, and printers, as well as core network infrastructure components like switches, routers, and security hardware. They are a critical part of any enterprise network’s asset management system, and they collect and maintain near real-time data about the monitored network components. They are usually accessed and maintained by an IT staff with exceptional access privileges on the monitored network.

As such, these systems are attractive targets for attackers looking to learn more about new environments. A compromised NMS can serve as a treasure map, leading attackers to the most valuable — and perhaps non-obvious — targets, such as the printer that is responsible for payroll runs, or HR’s central server containing personally identifiable information on the employee base. Besides, why spend time and risk detection by scanning the network from a compromised system controlled by the attacker, when one could just piggyback on a working NMS that’s already designed to monitor the entire network population?

Given that NMSs make excellent points of compromise to extend an attacker’s privileges, the next step is to determine the easiest, cheapest method to attack them. To answer that question we have to visit the original purpose of our research. We have been researching various aspects of SNMP for over the past 24 months, ranging from SNMP-leveraged data extraction techniques2 to attacking systems that rely heavily on SNMP data streams. We formed a hypothesis that a malicious actor might be able to deliver persistent XSS via SNMP data fields to a web-based management console, and NMSs appeared to be ideal target candidates for this line of research, given the way they operate:

1. Virtually all modern NMSs are managed using web-based interfaces.

2. Most NMSs track and manage networked systems via SNMP by default.

3. Most NMSs can be configured to receive SNMP traps from networked systems.

4. NMSs are likely to initially trust the data received from new devices on the network.

INTRODUCTION TO NMSs02

2 See the Rapid7 blog post at https://community.rapid7.com/community/services/blog/2016/05/05/snmp-data-harvesting-during-penetration-testing, as well as the advisories at https://community.rapid7.com/community/metasploit/blog/2014/05/16/r7-2014-01-r7-2014-02-r7-2014-03-disclo-sures-exposure-of-critical-information-via-snmp-public-community-string and https://community.rapid7.com/community/metasploit/blog/2014/08/21/more-snmp-information-leaks-cve-2014-4862-and-cve-2014-4863

https://community.rapid7.com/community/services/blog/2016/05/05/snmp-data-harvesting-during-penetrat

https://community.rapid7.com/community/services/blog/2016/05/05/snmp-data-harvesting-during-penetrat

https://community.rapid7.com/community/metasploit/blog/2014/05/16/r7-2014-01-r7-2014-02-r7-2014-03-d



https://community.rapid7.com/community/metasploit/blog/2014/08/21/more-snmp-information-leaks-cve-20




The Simple Network Management Protocol (SNMP) was designed and deployed in the early days of the internet, with version 1 in production by 1988. It was intended to provide a temporary, modular approach to network management, and has since been included in virtually every networked operating system as a standard means to centrally3 monitor networked devices. For more detail on the history of SNMP, the Python library, pysnmp, is an excellent source.

While SNMP is now well into version 3, the original version 1 is also nearly universally supported, since resource constrained legacy systems continue to operate in many network enterprises, and a new generation of low-power, low-resource Internet of Things (IoT) devices are making their way into otherwise modern networks. Today, Network Management Systems rely heavily on SNMP for managing and monitoring all sorts of networked equipment, including servers, routers, switches, uninterruptible power supplies, printers, and cable/DSL modems, and while these NMSs may prefer the more modern SNMPv3, SNMPv1 interfaces to NMSs are nearly always available for backwards compatibility.

The network manager-to-agent communication involves retrieving or setting the value of management objects with unique object identifiers (OIDs). RFC 1156 and RFC 1213 mandate the System group OID, which contains a collection of common objects under the System group OID (1.3.6.1.2.1.1). In order to be “in spec,” the System group must be implemented by all systems supporting SNMP. These System group objects consist of regular ASCII character data, such as the common objects detailed in the table below.

INTRODUCTION TO SNMP03

3 https://github.com/etingof/pysnmp/blob/master/docs/source/docs/snmp-history.rst

Name OID Description

sysDescr 1.3.6.1.2.1.1.1Description of the entity, a largely free-form field that can include its full name and its operating system version information.

sysContact 1.3.6.1.2.1.1.4 Contact information for the person responsible for the entity.

sysName 1.3.6.1.2.1.1.5 Name assigned to the entity. Typically, the fully qualified domain name.

sysLocation 1.3.6.1.2.1.1.6 The physical location of the entity.

Table 1: Common OIDs


Much of the normal operation involving SNMP involves reading and recording system objects by periodically scanning the monitored network for new and already catalogued devices. As a result, these values are frequently queried and displayed by Network Management Systems.

Beyond responding to manager requests, the agent-to-network manager communication can be initiated by the agent as notifications. SNMP “trap” messages are used by SNMP agents to notify the network manager of abnormal conditions or other status changes without waiting to be polled. A trap might simply be represented by an object identifier (OID), or it might enclose object-value pairs relevant to the specific notification.

At the time of its design, there was a worry that an already troubled network, in the grip of failure, should not devote the extra resources needed by TCP to get network status information out to a central management server. After all, SNMP gets chatty precisely when things are going wrong on the network as devices are trying to report their specific failure conditions. There-fore, the unacknowledged, fire-and-forget nature of UDP was preferred over reliability-focused and more resource-intensive TCP. Unfortunately, this decision means that SNMP messages are trivially spoofed by attackers, as this paper will explore later.

The rather weak security controls involved in SNMPv1 are also markedly dated to 1980s thinking about the internet. Pass-words, called “community strings” in the SNMP parlance, offer two levels of access: RO, or read-only, and RW, or read-write. But, because these passwords are transmitted in cleartext, an attacker on the local network can easily discover them. Modern encryption is only supported in SNMPv3 implementations.

Finally, SNMP “should” not be available on the public internet, but that’s a pretty weighted “should.” Many studies demon-strate that numerous protocols are inappropriate for use on public networks.4 While the vulnerabilities and exploits explored in this paper presume a LAN-local attacker, misconfigured firewalls and poor network segmentation can enable remote attackers.

4 One such study is Rapid7’s National Exposure Index at https://information.rapid7.com/national-ex-posure-index.html , which goes into some detail about many old, cleartext protocols exposed on the internet. The IETF’s 2014 best practice document, “Pervasive Monitoring Is An Attack” at https://tools.ietf.org/html/rfc7258 voices similar concerns over cleartext protocols.

https://information.rapid7.com/national-exposure-index.html

https://information.rapid7.com/national-exposure-index.html


Cross-site scripting (XSS) vulnerabilities are not new; in fact, they are among the earliest application vulnerabilities involving web browsers. As described by Michael Barrett’s 2010 retelling of the discovery of XSS5 , XSS vulnerabilities and attacks have been with us since the late 1990s and are pernicious enough that we expect they will continue to haunt web-based applica-tions for the foreseeable future.

While the first XSS attacks involved providing a custom URL for victims to click on, the more valuable vulnerabilities for attackers are persistent (or stored) XSS vulnerabilities. In a persistent XSS exploit, the malicious data is stored in a way the web application will later retrieve it and display it to another user.

For example, imagine that the comment section of a news site did not do anything to sanitize input or output; users could create annoying comments6 that changed colors, font sizes, or embedded images. More dangerously, they could also include <script> and <embed> tags to run custom code, not authored by the news site, on all viewers’ browsers. Once an attacker can embed their own executable code on other people’s websites, the utility of such an exploit can range from session cookie theft and impersonation, to automatically downloading malware, to complete browser window control, all without the use of browser-based vulnerabilities or exploits.

XSS INJECTION ATTACKS EXPLAINED

04

5 http://www.thesecuritypractice.com/the_security_practice/2010/11/how-cross-site-scripting-was-discovered.html

6 Technically, “more annoying” than the usual comments found on news sites.

http://www.thesecuritypractice.com/the_security_practice/2010/11/how-cross-site-scripting-was-discovered.html

http://www.thesecuritypractice.com/the_security_practice/2010/11/how-cross-site-scripting-was-discovered.html


As described by OWASP, XSS is typically exploited via an HTTP request to the targeted web application.7 However, the concept of these attacks being delivered via a non-HTTP-based protocol for eventual execution over an HTTP channel has only been discussed in the industry literature a handful of times, and rarely in any depth. Adrian Pastor from ProCheckUp presented the first published research on SNMP injection attacks in October of 2008.8

Pastor’s white paper addressed an attack method where SNMP was utilized to write persistent XSS into various parameters in embedded platforms using the SNMP write community strings. When the web management interfaces of those embedded devices were viewed, the XSS attack would trigger. Although interesting, this attack technique requires the adversary to already know the SNMP write community string. In addition, the attacker must wait for someone to actually log in to the embedded device’s web console in order to trigger the XSS, which is a fairly rare occurrence when it comes to embedded systems management.9

In contrast, the research presented in this paper took a very different path when it came to leveraging SNMP for injection attacks. First, our attack focuses on targeting Network Management System (NMS) Applications, which are typically used on a day-to-day basis for managing devices installed on corporate networks. Second, these NMS products utilize SNMP for their discovery and management processes. The discovery process, in particular, tends to trust the SNMP data being delivered from the newly discovered networked devices. This presents an opportunity for attackers who have the capability of adding malicious devices to the monitored network.

The examples discussed in this paper show how quickly this becomes a liability for Network Management System products that are not configured to properly validate input data before processing and rendering it. By placing a rogue device on a network and allowing the Network Management Systems discovery process to request and process the SNMP data of the malicious device, XSS attacks can successfully be delivered to these products. Since Network Management Systems are often closely monitored through a web-based administrative interface, any persistent XSS payload will tend to be triggered quickly, and when triggered, often by a user that enjoys application administration access.

Proven XSS Attacks via SNMP Agent Responses

All NMSs encountered during this research had the functional capability to discover new network devices. This capability appeared to be integral to the product’s effectiveness, especially in enterprise networks, as enterprise networks naturally exist in a state of flux. The network discovery process typically leverages several different forms of device identification, ranging from simple IP discovery to automatic SNMP-based discovery. SNMP discovery appears to be the most effective method, since SNMP is designed to provide more detailed device identification without complex fingerprinting or other educated guesswork.

PASSIVE SNMP AGENT XSS INJECTION

05

7 https://www.owasp.org/index.php/XSS8 http://www.procheckup.com/media/41537/snmp_injection.pdf9 When was the last time you logged into your home router?

https://www.owasp.org/index.php/XSS

http://www.procheckup.com/media/41537/snmp_injection.pdf


Vulnerability Identifier Product Versions Affected Version Fixed

R7-2015-18 Spiceworks Desktop 7.3.00065, 7.3.00076, 7.4.00075

7.5.00050

R7-2015-19.1 Ipswitch WhatsUp Gold 16.2.6,16.3.1 16.3.2

R7-2015-20.1 Castle Rock SMNPc Enterprise 9.0, OnLine 12.1 Available from Castle Rock Support

R7-2016-02 ManageEngine OpUtils 8.0, 12.0 Service Pack 80011,

Service Pack, 12100, 12.1

R7-2016-11.1 CloudView NMS 2.07b, 2.09b 2.10a

R7-2016-13 Paessler PRTG 16.2.24.3791 16.2.24.4045

R7-2016-14.2 Opmantek NMIS 8.5.10G, 4.3.6f 8.5.12G, 4.3.7c

Table 02: Products demonstrating XSS via SNMP agent responses

Seven of the NMSs trusted the SNMP data supplied by the device during routine discovery and displayed this information in the web-based management application making them vulnerable to XSS attacks, as summarized in table 2.

The following examples explore how the implied manager-agent trust relationship was exploited to inject various per-sistent XSS attacks into the NMSs using SNMP data requested during the network discovery process.

R7-2015-18, XSS via SNMP Agent Responses in Spiceworks Desktop

Vulnerability Summary

Due to a lack of input validation during network entity discovery, Spiceworks Desktop versions 7.3.00065, 7.3.00076, and 7.4.00075 are vulnerable to persistent XSS attacks. In particular, the following OIDs were found to be effective vectors for exploitation:

• sysDescr (1.3.6.1.2.1.1.1)

• sysName (1.3.6.1.2.1.1.5)

The screenshot below shows the result of discovering a network device where the sysName OID has been set to <script>alert(‘sysname xss test’);</script>.

Product: Spiceworks Desktop Vulnerable Versions: 7.3.00065, 7.3.00076, 7.4.00075 Fixed Version: 7.5.00050 CVE: CVE-2015-6021 Disclosure Date: December 16, 2015 Disclosure URL: https://community.rapid7.com/community/infosec/blog/2015/12/16/multiple-disclo-sures-for-multiple-network-management-systems

Figure 01: R7-2015-18 for Spiceworks Desktop


R7-2015-19.1, XSS via SNMP Agent Responses in Ipswitch WhatsUp Gold


Due to a lack of input validation during network entity discovery, Ipswitch WhatsUp Gold versions 16.2.6 and 16.3.1 are vulnerable to persistent XSS attacks. In particular, the following OIDs were found to be effective vectors for exploitation:

� sysContact: 1.3.6.1.2.1.1.4.0

� sysLocation: 1.3.6.1.2.1.1.5.0

� sysName: 1.3.6.1.2.1.1.6.0

The screenshot below shows the result of discovering a network device where the sysName OID has been set to <IFRAME SRC=”javascript:alert(‘XSS-TEST1-Name’);”>.

Product: Ipswitch WhatsUp Gold Vulnerable Versions: 16.2.6, 16.3.1 Fixed Version: 16.3.2 CVE: CVE-2015-6004 Disclosure Date: December 16, 2015 Disclosure URL: https://community.rapid7.com/community/infosec/blog/2015/12/16/multiple-disclo-sures-for-multiple-network-management-systems

Figure 02: R7-2015-19.1 for WhatsUp Gold


R7-2015-20.1, XSS via SNMP Agent Responses in Castle Rock SNMPc


Due to a lack of input validation during network entity discovery, Castle Rock SNMPc Enterprise 9.0 and OnLine 12.1 are vulnerable to persistent XSS attacks. In particular, the following OIDs were found to be effective vectors for exploitation:

• sysDescr: 1.3.6.1.2.1.1.1

• sysName: 1.3.6.1.2.1.1.6.0

The screenshot below shows the result of discovering a network device where the sysDescr OID has been set to <SCRIPT>alert(“XSS-sys-Descr”)</SCRIPT>.

Product: Castle Rock SNMPc Vulnerable Versions: Enterprise 9.0, OnLine 12.1 Fixed Versions: Available from the vendor CVE: CVE-2015-6027 Disclosure Date: December 16, 2015 Disclosure URL: https://community.rapid7.com/community/infosec/blog/2015/12/16/multiple-disclo-sures-for-multiple-network-management-systems

Figure 03: R7-2015-20.1 for Castle Rock SNMPc


R7-2016-02, XSS via SNMP Agent Responses in ManageEngine OpUtils


Due to a lack of input validation during network entity discovery, Mana-geEngine OpUtils version 8.0 is vulnerable to persistent XSS attacks. In particular, the following OIDs were found to be effective vectors for exploitation:

• sysDescr 1.3.6.1.2.1.1.1

• sysLocation 1.3.6.1.2.1.1.5.0

• sysName 1.3.6.1.2.1.1.6.0

The screenshot below shows the result of discovering a network device where the sysDescr OID has been set to <SCRIPT>alert(“XSS-sys-Descr”)”></SCRIPT>.

Product: ManageEngine OpUtils Vulnerable Version: 8.0 Fixed Version: 8.0 Service Pack 80011 Disclosure Date: March 17, 2016 Disclosure URL: https://community.rapid7.com/community/infosec/blog/2016/03/17/r7-2016-02-multi-ple-vulnerabilities-in-mangeengine-oputils

Figure 04: R7-2016-02 for ManageEngine OpUtils


R7-2016-11.1, XSS via SNMP Agent Responses in CloudView NMS


Due to a lack of input validation during network entity discovery, Cloud-View NMS versions 2.07b and 2.09b are vulnerable to persistent XSS attacks. In particular, the following OIDs were found to be effective vectors for exploitation:

• sysDescr 1.3.6.1.2.1.1.1

The screenshot below shows the result of discovering a network device where the sysDescr OID has been set to <SCRIPT>alert(“XSS-sys-Descr”)<SCRIPT>.

Product: CloudView NMS Vulnerable Versions: 2.07b, 2.09b Fixed Version: 2.10a CVE: CVE-2016-5073 Disclosure Date: September 7, 2016 Disclosure URL: https://community.rapid7.com/community/infosec/blog/2016/09/07/multiple-disclo-sures-for-multiple-network-management-sys-tems-part-2

Figure 05: R7-2016-11.1 for CloudView NMS


R7-2016-13, XSS via SNMP Agent Responses in Paessler PRTG


Due to a lack of input validation during network entity discovery, Paessler PRTG version 16.2.24.3791 is vulnerable to persistent XSS attacks. In particular, the following OIDs were found to be effective vectors for exploitation:

• sysDescr 1.3.6.1.2.1.1.1.0

• sysLocation 1.3.6.1.2.1.1.6.0

• sysContact 1.3.6.1.2.1.1.4.0

The screenshot below shows the result of discovering a network device where the sysDescr OID has been set to <embed src=//ld1.us/4.swf>.


Figure 06: R7-2016-13 for Paessler PRTG


R7-2016-14.2, XSS via SNMP Agent Responses in Opmantek NMIS


Due to a lack of input validation during network entity discovery, Opman-tek NMIS versions 8.5.10G and 4.3.6f are vulnerable to persistent XSS attacks. In particular, the following OIDs were found to be effective vectors for exploitation:

• sysDescr (1.3.6.1.2.1.1.1)

• sysContact (1.3.6.1.2.1.1.4)

• sysLocation (1.3.6.1.2.1.1.6)

The screenshot below shows the result of discovering a network device where the sysDescr OID has been set to <script>alert(‘sysLoca-tionTest’);</script>

Product: Opmantek NMIS Vulnerable Versions: 8.5.10G, 4.3.6f Fixed Versions: 8.5.12G, 4.3.7c CVE: CVE-2016-5642 Disclosure Date: September 7, 2016 Disclosure URL: https://community.rapid7.com/community/infosec/blog/2016/09/07/multiple-disclo-sures-for-multiple-network-management-sys-tems-part-2

Figure 07: R7-2016-14.2 for Opmantek NMIS


In a normal SNMP-based network management environ-ment, SNMP traps are used to deliver status and alerts from managed agents. Rather than waiting to be polled by the SNMP-based management system, the client instead proactively sends trap messages to communicate events such as cold start boot ups, authentication failures, and custom enterprise-specific alerts. SNMP traps can also be used to inject persistent XSS into Network Management Systems with devastating effect. Recall that SNMP is traditionally UDP-based, and as discussed above, is trivially spoofable by an attacker on the same network. By spoofing SNMP traps from otherwise benign, catalogued devices, attackers are able to success-fully inject persistent XSS attacks into six of the NMS products we tested. Further, many of the NMSs were shown to allow fully unsolicited trap input, accepting trap information from any IP address using any SNMP community string; in effect, the

attacker need not perform any reconnaissance on the target network to learn the correct community string, but only needs to know (or learn) the IP address of the central NMS. In the worst case, the attacker can simply employ a “spray and pray” strategy and send unsolicited trap messages to any listening UDP/162 port using a spoofed IP address, and trust that any affected NMS will pick up the XSS attack string and embed it in the web console of those NMSs.

Proven XSS Attacks via SNMP Traps

In October of 2013, Denis Andzakovic of Security Assess-ment, released an advisory for Solarwinds Server Application Monitor, version 6.0, showing it to be vulnerable to SNMP trap injection10. Building upon this line of research, we examined our nine Network Management Systems for trap-based injection vulnerabilities. The results of this broad audit of NMSs indicate that trap-based injection is a fairly reliable vector for attack, as shown in the table below.

ACTIVE SNMP TRAP XSS 06

Vulnerability Identifier Product Version Affected Version Fixed

R7-2015-19.1 Ipswitch WhatsUp Gold 16.2.6, 16.3.1 16.3.2

R7-2015-20.1 Castle Rock SNMPc Enterprise 9.0, OnLine 12.1 Available from Castle Rock Support

R7-2015-21 Opsview Monitor 4.6.3 4.6.4

R7-2016-11.2 CloudView NMS 2.07b, 2.09b 2.10a

R7-2016-12 Netikus EventSentry 3.2.1.8, 3.2.1.22, 3.2.1.30 3.2.1.44

R7-2016-14.1 Opmantek NMIS 8.5.10G 8.5.12G

Table 8: Products demonstrating XSS via SNMP trap messages

10 http://www.security-assessment.com/files/documents/advisory/Solarwinds%20SAM%206.0.0%20Multiple%20Vulnerabilties.pdf, fixed in version 6.0.2

http://www.security-assessment.com/files/documents/advisory/Solarwinds%20SAM%206.0.0%20Multiple%20Vulnerabilties.pdf

http://www.security-assessment.com/files/documents/advisory/Solarwinds%20SAM%206.0.0%20Multiple%20Vulnerabilties.pdf


The following examples discuss leveraging the SNMP trap-based alerting mechanism to inject various forms of persistent XSS attacks into the six systems’ web based management consoles by injecting Flash as part of an SNMP trap message.

R7-2015-19.1, XSS via SNMP Trap Messages in Ipswitch WhatsUp Gold


Due to a lack of input validation when processing SNMP trap messages, WhatsUp Gold versions 16.2.6 and 16.3.1 are vulnerable to persistent XSS attacks11.

The screenshot below shows the result of processing a trap message sent with the HTML code <embed src=//ld1.us/4.swf>.


Figure 09: R7-2015-19.1 for WhatsUp Gold (Trap Message Vector)

11 At the time of disclosure, both the passive and active versions of this WhatsUp Gold vulnerability were published under the same vulnerability identifier.


R7-2015-20.1, XSS via SNMP Trap Messages in Castle Rock SNMPc


Due to a lack of input validation when processing SNMP trap messages, Castle Rock SNMPc Enterprise 9.0 and OnLine 12.1 are vulnerable to persistent XSS attacks12.


Product: Castle Rock SNMPc Vulnerable Versions: Enterprise 9.0, OnLine 12.1 Fixed Versions: Available from the vendor CVE: CVE-2015-6027 Disclosure Date: December 16, 2015 Disclosure URL: https://community.rapid7.com/community/infosec/blog/2015/12/16/multiple-disclo-sures-for-multiple-network-management-systems

Further increasing the severity of this vulnerability, the session cookies in the SNMPc product contained the cleartext username and password for the application administrator. The web log entry in Figure 11 demonstrates the ability to capture the session cookie and thus, the username and password of the application administrator.

Figure 11: Captured session cookie for Castle Rock SNMPc

Figure 10: R7-2015-20.1 for Castle Rock SNMPc

12 At the time of disclosure, both the passive and active versions of this SNMPc vulnerability were published under the same vulnerability identifier.


R7-2015-21, XSS via SNMP Trap Messages in Opsview Monitor


Due to a lack of input validation when processing SNMP trap messages, Opsview Monitor version 4.6.3 is vulnerable to a persistent XSS attack

The screenshot below shows the result of processing a trap message sent with the HTML code <script>alert(‘Cookie: ‘ + docu-ment.cookie);</script>.

Product: Opsview Monitor Vulnerable Version: 4.6.3 Fixed Version: 4.6.4 CVE: CVE-2015-6035 Disclosure Date: December 16, 2015 Disclosure URL: https://community.rapid7.com/community/infosec/blog/2015/12/16/multiple-disclo-sures-for-multiple-network-management-systems

Figure 12: R7-2015-21 for Opsview Monitor


R7-2016-11.2, XSS via SNMP Trap Messages in CloudView NMS


Due to a lack of input validation when processing SNMP trap messages, CloudView NMS versions 2.07b and 2.09b are vulnerable to persistent XSS attacks.



Figure 13: R7-2016-11.2 for CloudView NMS


R7-2016-12, XSS via SNMP Trap Messages in Netikus EventSentry


Due to a lack of input validation when processing SNMP trap messages, Netikus EventSentry versions 3.2.18, 3.2.122, and 3.2.1.30 are vulnerable to persistent XSS attacks.


Product: Netikus EventSentry Vulnerable Versions: 3.2.1.8, 3.2.1.22, 3.2.1.30 Fixed Version: 3.2.1.44 CVE: CVE-2016-5077 Disclosure Date: September 7, 2016 Disclosure URL: https://community.rapid7.com/community/infosec/blog/2016/09/07/multiple-disclo-sures-for-multiple-network-management-sys-tems-part-2

Figure 14: R7-2016-12 for Netikus EventSentry


R7-2016-14.1, XSS via SNMP Trap Messages in Opmantek NMIS


Due to a lack of input validation when processing SNMP trap messages, Opmantek NMIS version 8.5.10G is vulnerable to a persistent XSS attack.

The screenshot below shows the result of processing a trap message sent with the HTML code <script>alert(‘SNMP Trap Test’);</script>.

Product: Opmantek NMIS Vulnerable Version: 8.5.10G Fixed Version: 8.5.12G CVE: CVE-2016-5642 Disclosure Date: September 7, 2016 Disclosure URL: https://community.rapid7.com/community/infosec/blog/2016/09/07/multiple-disclo-sures-for-multiple-network-management-sys-tems-part-2

Figure 15: R7-2016-14.1 for Opmantek NMIS


Using SNMP as a method to inject format string exploits seemed like the next obvious approach to launching attacks against NMSs. Similar to the XSS attacks, this method also leverages the SNMP OIDs such as sysDescr, sysName, and sysLocation. By crafting format string specifiers as OID-formatted responses (or trap alert messages), a malicious actor can deliver format string specifiers to an NMS application parsing engine. If vulnerable, this would lead to a series of format string vulnerability attacks as described next.

By leveraging format string vulnerabilities like this, a malicious actor can use specific format string specifiers, listed below, to carry out certain attacks against an application.

• %x - This format string specifier is used to read process stack information and return memory addresses as hex bytes.

• %s - This specifier uses the stack information as a pointer in memory allowing a malicious actor to read arbitrary memory or trigger a denial-of-service condition by attempting to read a non-existing memory address.

• %n - A special format string specifier that keeps a counter of format strings processed. A malicious actor can use this specifier to write that counter to arbitrary memory using stack information as a pointer to memory. A denial-of-service condition can also be generated by attempting to write to a non-existing memory address.

Format String Attacks, Explained

Format string attacks leverage application coding issues related to how format strings are defined, or better yet, incorrectly defined, in an application. Format strings are ANSI C specifiers used by an application to define the output of certain func-tions as expected by that application. For example, “%s” is a specifier used to define the output to be avstring data, “%x” defines the output data to be a hex number. While there are many format strings available to the enterprising attacker with a format string vulnerability, “%s” and “%x” are the most commonly leveraged to test the existence of a format string vulnera-bility. So, how can format strings lead to a format string vulnerability?

The best way to describe this is with some simple program examples showing the correct and incorrect use of format strings specifiers and the output of each of these examples.

FORMAT STRING ATTACKS VIA SNMP

07


The example in Figure 16 shows the correct use of a format string specifier. In this case, the output is defined by the “%s” specifier, which will output the data in string format. For example, if we enter “hello world,” the program would print out, unsurprisingly, “hello world.” Likewise, if we entered “%x %x %x %x,” the program would print out the literal “%x %x %x %x.”

In the next example, Figure 17 shows an incorrect use of a format string specifier. In this case, a specifier is not used at all to define the output. If a user were to enter “hello world,” the program would print out “hello world” and appear to function normally. The format string vulnerability only becomes apparent when format string specifiers are used for input to the argument “argv[1]”. So if we entered “%x %x %x %x,” the program would print output process stack data as shown in Figure 18.

What is happening here is that since no format string specifier was defined within the code, the code is evaluating the argument input data “%x” as a specifier, not as literal data, and attempting to read the stack location for the data, which leads to the stack data being outputted in hex format.

For more detail on the history and nature of format string vulnerabilities, see Team Teso’s excellent September 2001 paper, “Exploiting Format String Vulnerabilities.”13

Figure 16: A correct use of a format string Figure 17: Incorrect

Figure 18: %x %x %x %x Output

13 https://crypto.stanford.edu/cs155/papers/formatstring-1.2.pdf

https://crypto.stanford.edu/cs155/papers/formatstring-1.2.pdf


R7-2015-19.1, XSS via SNMP Trap Messages in Ipswitch WhatsUp Gold

Vulnerability Details

CloudView NMS versions 2.07b and 2.09b are vulnerable to a format string vulnerability. This vulnerability allows a malicious actor to inject format string specifiers into the product via the SNMP “sysDescr” field, provided when the NMS scans the attacker’s SNMP agent. When successfully exploited, this could allow a malicious actor to trigger a denial-of-service condition, and possibly execute code14 .

The below OllyDbg screen shot (Figure 19) shows a series of %x followed by a %s that were used as the SNMP sysDescr field of a discovered device to enumerate the stack data from the main process stack.


Proven Format String Attacks via SNMP

Format string vulnerabilities are relatively rare these days, much like proper stack-based buffer overflows, since they tend to surface only in custom-written and compiled code. Modern network applications tend to use libraries and other components that have been audited extensively for format string misuse. However, they are still occasionally discovered in modern shipping software, as we can see below.

• AAAABBBB%x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %x %s

The %s at the end read the address 2E323931 from the process stack, and attempted to read from that memory address. This caused an access violation when reading memory error, which lead to a denial-of-service condition when the applica-tion crashed.

Figure 19: R7-2016-11.3Format String Vulnerability in CloudView NMS

14 This may be a remote code execution (RCE) vulnerability as well as a DoS, but this has not been conclusively proven one way or the other at the time of this writing.


To begin this research project, the researchers set up three virtual machine (VM) host systems to mimic a NMS-monitored network environment. On the first VM host, we ran the NMS product under test. The operating systems for this VM varied between Linux and Windows 2008 server, depending on the common and allowed operating systems for each vendor. Most of the NMS products tested were Windows-based products, so Windows 2008 server was the primary operating system during testing. For this discussion, that will be referred to as the “NMS VM.”

The second VM host was set up to act as the administrator’s workstation, which we used to manage the product over the network using a web browser (which is the normal use case for these systems). This operating system was Linux and the browsers used for testing included both Chrome and Firefox.15 We will refer to this system as the “Admin VM.”

Finally, the third VM host was a Linux host used to simulate the attacker’s malicious device. On this host we ran snmpd and various SNMP tools such as snmpwalk and snmptrap, and it will be referred to as the “Malicious VM.”

For candidate selection and testing, we used the typical 30-day trial versions of NMS products that were easily available for download. These were installed on the NMS VM with all the defaults selected and accepted during the install process. The researchers referred to the available documentation to determine normal operation of the product, spending anywhere between a few hours to a few days to learn how the products are intended to function.

Each product tested was found to have a device discovery function, which scans the network and discovers devices. This was typically done using normal ICMP ping and SNMP protocols. The discovery function could be configured to run on predeter-mined schedules, configurable by the administrator. Once the NMS VM and product under test was configured and its features were understood, each was configured to scan the Malicious VM. For a control, the Malicious VM was configured to serve normal SNMP data, not attack data, so that we could map out the normal and expected functionality of each of the NMSs discovery phases.

TESTING METHODOLOGY08

15 Generally speaking, the browser and OS of the workstation is immaterial for per-sistent XSS attacks, since the browser has no way to tell if a snippet of javascript or embedded Flash is intended or injected by an attacker. However, some browsers have more stringent mitigations than others when it comes to specific attack vectors, espe-cially if those browsers are configured to allow (or deny) automatic execution of Flash (via click-to-play controls) or JavaScript (via a browser extension such as NoScript).


Building an Attack SNMP Agent

For the setup of the Malicious VM we used Ubuntu Desktop 14.04. Once the Ubuntu VM was created we installed the Net-SN-MP tools suite which provides programs such as snmpwalk and snmptrap with the usual apt-get method:

• sudo apt-get install snmp

After that was complete, we installed snmpd, which provides a discoverable SNMP agent we could use to deliver content to the NMS VM via network discovery function, like so:

• sudo apt-get install snmpd

The installed snmpd, by default, is configured to listen on the loopback address 127.0.0.1 as shown in Figure 20.

The bound interface is easily changed by modifying the agentAddress property in the snmpd service’s configuration file at /etc/snmp/snmpd.conf, and specifying the correct, non-localhost address, as shown in Figure 21.

Once saved, restarting the service will cause the SNMP agent to be bound to the correct interface:

• sudo service snmpd restart

After this is completed, a quick test will show that the Malicious VM is responding properly under the new address. This can be done using the snmpwalk command:

• snmpwalk –v1 –c public 192.168.2.41

Figure 21: snmpd.conf agentAddress Configuration

Figure 20: snmpd.conf agentaddress Default Configuration


Where “-v1” is the SNMP version being used (both 1 or 2c work), and “-c” is the community string (in this case, “public,” the default).

If everything is configured properly, the following response will be received:

Generating Custom SNMP Agent Responses

Examining the above, we can identify several OIDs, which are often enumerated and processed during NMS discovery and displayed in the management console of NMSs.

• sysDescr: iso.3.6.1.2.1.1.1.0 = “Linux ubuntu 4.2.0-42-generic #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC 2016 x86_64”

• sysName: iso.3.6.1.2.1.1.5.0 = “ubuntu”

• sysLocation: iso.3.6.1.2.1.1.6.0 = “Sitting on the Dock of the Bay”

Using the newly configured snmpd service on the Malicious VM, we can next configure the sysDescr, sysName, and sysLoca-tion in the snmpd.conf file to test the NMS for persistent XSS vulnerabilities, as shown:

Figure 23: snmpd.conf SYSTEM INFORMATION

Figure 22: Results from snmpwalk Command


As can be seen here, only sysLocation (and sysContact) of the three we listed is shown. The data for the others are generated by the operat-ing system, but we can override that by configuring them specifically. Since we are going to be testing for XSS, we’ll add HTML elements here, such as an <iframe> or a JavaScript alert box. Both of these work when testing for XSS. A sample of the snmpd.conf file with these changes is shown in Figure 24.

Once restarted, it’s easy to test with another:

• snmpwalk –v1 –cpublic 192.168.2.4

If everything is configured properly, the follow-ing response will be received:

Once this is all configured and restarted, it’s merely a matter of waiting for the NMS VM to query the Malicious VM for standard system data.

Generating Custom SNMP Trap Messages

Now that we have covered the injection of XSS via NMS SNMP discovery, it’s time to move on to SNMP traps. SNMP traps allow an SNMP managed device to notify the management system of noteworthy events. These SNMP messages are sent to the NMS via the SNMP trap listener on the usual SNMP port, UDP/162. The NMS receives these alerts, records them, and displays them in the NMS management console so the NMS administrator can view and act on these alerts. Since most NMSs are managed using a web browser, if the SNMP trap message contains XSS exploits and the NMS is vulnerable, then an attacker can deliver XSS attacks into the NMS console for exploitation.

The tool “snmptrap” is used for sending SNMP trap messages, and is installed on the Malicious VM as part of the SNMP tool suite (‘apt-get install snmp’).

For more detail on snmptrap’s many, many options, readers are encouraged to look at the Net-SNMP Tutoral16 and O’Reilly’s Essential SNMP17.

The following example of the snmptrap command is color-coded to show the various sections of the (somewhat Byzantine) construction of a trap mes-sage, with each section described.

Figure 25: snmpwalk Returned Information

Figure 24: snmpd.conf with XSS

snmptrap -v 1 \ -c public \ 192.168.0.72 \ ‘1.3.6.1.4.1.43555’ \ ‘192.168.0.68’ \ 6 99 \ ‘’ 1.3.6.1.4.1.43555 \ s “<script>alert(123)</script>”

• -v Version this can be 1, 2c, 3

• -c community string

• Trap server hostname

• Enterprise OID “This can be blank”

• Localhost

• Generic trap ID

• Specific trap ID

• OID type value “This can be any OID”

• String message sent

16 http://www.net-snmp.org/tutorial/tutorial-5/commands/snmptrap.html17 http://shop.oreilly.com/product/9780596008406.do

http://www.net-snmp.org/tutorial/tutorial-5/commands/snmptrap.html

http://shop.oreilly.com/product/9780596008406.do


Cross-site scripting and format string vulnerabilities are hardly new attack vectors, but they are surprisingly effective avenues of attack against modern, enterprise-level Network Management Systems. This is due to an inappropriately assumed and implied trust relationship between NMSs and the network entities the NMS is responsible for discovering and monitoring. Application developers today are more aware than ever before of the dangers of trusting user-supplied data without filtering, validation, or authentication, and most mature web application frameworks make it difficult to accidentally implement a persistent XSS vulnerability.

The cases described in this paper, however, appear to have exposed a designer blind spot across several vendors of similar products when it comes to interacting with newly discovered networked equipment.

First, it often does not occur to product designers that a local network would have an untrusted, malicious actor lurking on it, one who is either waiting for an automated process to swing by and start communications or one who is actively seeking to attack core network services. In the current era of the disintegration of network borders due to mobile and cloud computing, this is a dangerous assumption to make.

Second, the natural responsibility of validating user input isn’t immediately obvious. Most people don’t think of a switch or a router as a “user,” so the oft-repeated secure software design principle of “Do not trust user input directly” is less likely to come to mind when designing machine-to-machine interfaces. To complicate things further, XSS strings are harmless in the context of an SNMP service (so it has no existential reason to inspect values for this kind of maliciousness), and at the same time, the SNMP service and its data store is going to be “trusted” from the perspective of the web administration console.

These breakdowns in the assumed and implied trust relationships between software components are at the root of the vulnerabilities explored in this paper, and while they appear to have been systemic to the NMS product category, patches for these vulnerabilities came quickly from the vendors when the researchers contacted them with these findings.

Readers of this paper who may be responsible for similar products related to asset management are urged to consider the assumed and implied trust relationships they are engineering into their products.

About Rapid7

Rapid7 is a leading provider of security data and analytics solutions that enable organizations to implement an active, analyt-ics-driven approach to cybersecurity. We combine our extensive experience in security data and analytics and deep insight into attacker behaviors and techniques to make sense of the wealth of data available to organizations about their IT environ-ments and users. Our solutions empower organizations to prevent attacks by providing visibility into vulnerabilities and to rapidly detect compromises, respond to breaches, and correct the underlying causes of attacks. Rapid7 is trusted by more than 5,600 organizations across over 100 countries, including 37% of the Fortune 1000. To learn more about Rapid7 or get involved in our threat research, visit www.rapid7.com.

CONCLUSIONS09

from managed to mangled - · pdf filefrom managed to mangled: snmp exploits for network...

Documents