Four Network Management Systems Vulnerable to SQLi and XSS Attacks

Today, Rapid7 is disclosing several vulnerabilities affecting several Network Management System (NMS) products. These issues were discovered by Deral Heiland of Rapid7 and independent researcher Matthew Kienow, and reported to vendors and CERT for coordinated disclosure per Rapid7’s disclosure policy. All together, we’re disclosing six vulnerabilities that affect four NMSs, four of which are expected to be patched by the time of this disclosure. The table below outlines these issues, and we’ll keep it updated when we learn of patch releases.

Rapid7 Identifier	CVE Identifier	Class	Vendor	Patch Status
R7-2015-18	CVE-2015-6021	XSS	Spiceworks	Patched December 01, 2015
R7-2015-19.1	CVE-2015-6004	XSS	Ipswitch	Expected December 16, 2015
R7-2015-19.2	CVE-2015-6005	SQLi	Ipswitch	Expected December 16, 2015
R7-2015-20.1	CVE-2015-6027	XSS	Castle Rock Computing	Unknown
R7-2015-20.2	CVE-2015-6028	SQLi	Castle Rock Computing	Unknown
R7-2015-21	CVE-2015-6035	XSS	Opsview	Patched November 06, 2015

R7-2015-18, Spiceworks Desktop Stored XSS via SNMP (CVE-2015-6021)

Summary

A stored server cross-site scripting (XSS) vulnerability in the web application component of Spiceworks Desktop via the Simple Network Management Protocol (SNMP). Authentication is not required to exploit.

Credit

This issue was discovered by independent researcher Matthew Kienow, and reported by Rapid7.

Products Affected

The following versions were tested and exploited successfully.

• Desktop Version 7.3.00065
• Desktop Version 7.3.00076
• Desktop Version 7.4.00075

Earlier versions may also be affected.

Description

A stored (AKA, Persistent or Type I) server cross-site scripting (XSS) vulnerability exists in the Spiceworks Desktop web application. The vulnerability is due to insufficient filtering of Simple Network Management Protocol (SNMP) agent supplied data before the affected software stores and displays the data.

An unauthenticated adversary that has access to a network segment scanned by the affected software could cause arbitrary code execution in an authenticated user’s browser session, which could be leveraged to conduct further attacks. The code has access the authenticated user’s cookies and would be capable of performing actions in the web application as the authenticated user, allowing for a variety of attacks.

The stored XSS attack code is delivered to the affected software during the network scan operation. The attack host utilizes an SNMP agent to supply the desired attack code in response to SNMP GetRequest messages for either the sysDescr (1.3.6.1.2.1.1.1) or sysName (1.3.6.1.2.1.1.5) object identifiers (OIDs). Attacks leveraging sysDescr can only contain up to 50 characters, and the code will execute when the user navigates to the inventory page (https://host:port/inventory). Attacks leveraging sysName can contain up to 255 characters, and the code will execute while the network scan is in progress as well as when the user navigates to  the inventory page. The sysName attack code will be truncated at the first period character by the affected software before being returned in responses.

Exploit

An attack host on a network segment scanned by the affected software is operating an SNMP agent that returns<script>alert(‘sysName XSS Test’);</script> as the sysName value. Once the attack host has been scanned, the script is returned in a response to the user’s browser session and executed, which displays the alert box. Next, the user navigates to the inventory page where the script is returned in a response to the user’s browser session and executed, which displays the alert box again. The below screenshots illustrate these effects.

Mitigations

Affected users are advised to update to the latest version from the vendor.

Disclosure Timeline

This vulnerability advisory was prepared in accordance with Rapid7’s disclosure policy.6ktr`

• Mon, Aug 31, 2015: Discovered by Matthew Kienow
• Tue, Sep 01, 2015: Disclosed to vendor by Rapid7
• Wed, Sep 02, 2015: Vendor response
• Wed, Sep 02, 2015: Details provided to vendor security contact
• Thu, Sep 17, 2015: Disclosed to CERT
• Fri, Sep 18, 2015: CERT assigned VU#411472, CVE-2015-6021 for persistent XSS
• Tue, Dec 01, 2015: Fix and bulletin published by vendor
• Wed, Dec 16, 2015: Public Disclosure

R7-2015-19, XSS and SQLi via SNMP in Ipswitch’s WhatsUpGold

Summary

The Ipswitch product WhatsUpGold is vulnerable to a persistent Cross Site Scripting (XSS) vulnerability and a SQL injection (SQLi) issue. The XSS issues do not require any prior authentication, while the SQLi issue does require authentication as a regularly privileged user.

Credit

These issues were discovered by Deral Heiland, Principal Consultant at Rapid7’s Global Services.

Products Affected

The following versions were tested and exploited successfully.

• WhatsUpGold Version 16.2.6
• WhatsUpGold Version 16.3.1

Earlier versions may also be affected.

R7-2015-19.1, XSS via SNMP (CVE-2015-6004)

While examining the WhatsUpGold product, it was discovered that it was vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This vulnerability allows a malicious actor to inject persistence XSS containing JavaScript into a number of fields within the product. When this data (JavaScript) is viewed within the web management console the JavaScript code will execute within the context of the authenticated user. This will allow a malicious actor to conduct attacks which can be used to modify the system’s configuration, compromise data, take control of the product or launch attacks against the authenticated user’s host system.

These persistent XSS attacks were delivered to WhatsupGold product via a couple different means. The first method XSS was delivered using the WhatsUpGold’s discovery process. When discovering a network device, if that device is configured with SNMP and the following SNMP OID objects contain HTML or JavaScript code. The code will be delivered to the product for persistent display and execution

• 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 following example shows the results of discovering a network device where the SNMP sysName has been set to <IFRAME SRC=”javascript:alert(‘XSSTEST1-Name’);”>. In this example, when viewed within WhatsUpGold’s web management console the JavaScript executes rendering an alert box.

This JavaScript was found to execute in multiple locations everywhere the sysContact, sysLocation and sysName are viewable.

The second method of injection involved SNMP trap messages. By spoofing an SNMP trap message and altering the data within that trap message a malicious actor could inject HTML and JavaScript code into the product. When the trap information is viewed the code will execute within the context of the authenticated user. The below screenshot shows an example attack where a trap message was used with the following HTML code <embed src=//ld1.us/4.swf> to embed Flash into the WhatUpGold trap logs.

R7-2015-19.2: SQLi via UniqueID parameter in Reports (CVE-2015-6005)

Examination of the WhatsUpgold product also revealed an SQL Injection vulnerability within the “UniqueID” parameter within the URL:

This injection point requires authentication prior to exploitation. Once authenticated a malicious actor could extract all data from the database. Leveraging the open source tool SQLMAP this vulnerability was simple to exploit and extract data from the application’s database. The screenshot below shows the extraction of data from the CredentialTypeData table within the Whatsup database.

Mitigations

Until updated versions are available from the vendor, customers should carefully control which devices and subnets are scanned for using WhatsUpGold. In addition, login rights to the control console should be limited to only those users trusted with local administrator privileges on the host.

Disclosure Timeline

This vulnerability advisory was prepared in accordance with Rapid7’s disclosure policy.

• Mon, Aug 31, 2015: Discovered by Deral Heiland, Principal Consultant Rapid7
• Tue, Sep 01, 2015: Initial contact to vendor
• Tue, Sep 08, 2015: Vendor response with security contact for issue 00997412
• Tue, Sep 08, 2015: Details provided to vendor security contact
• Thu, Sep 17, 2015: Disclosed to CERT
• Wed, Dec 16, 2015: Vendor fix released (Planned)
• Wed, Dec 16, 2015: Public Disclosure

R7-2015-20, XSS and SQLi via SNMP in Castle Rock Computing SNMPc

Summary

The Castle Rock Computing product SNMPc Enterprise and its web based reporting/monitoring tool SNMPc OnLine is vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. The XSS issues do not require any prior authentication, while the SQLi issue does require authentication as a regularly privileged user.

Credit

These issues were discovered by Deral Heiland, Principal Consultant at Rapid7’s Global Services.

Products Affected

The following versions were tested and exploited successfully.

• SNMPc Enterprise Version 9
• SNMPc OnLine Version 12.1

R7-2015-20.1, Persistent XSS (CVE-2015-6027)

While examining the Castle Rock product SNMPc Enterprise and its web based reporting/monitoring tool SNMPc OnLine, it was discovered that SNMPc Online was vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This vulnerability allows a malicious actor to inject persistence XSS containing JavaScript into a number of fields within the product. When this data (JavaScript) is viewed within the web console the JavaScript code will execute within the context of the authenticated user. This will allow a malicious actor to conduct attacks which can be used to modify the system’s configuration, compromise data, take control of the product or launch attacks against the authenticated user’s host system.

These persistent XSS attacks were delivered to SNMPc product via a couple different means. The first method the XSS was delivered using the SNMPc’s discovery process. When discovering a network device, if that device is configured with SNMP and the following SNMP OID object contain HTML or JavaScript code. The code will be delivered to the product for persistent display and execution.

• sysDescr: 1.3.6.1.2.1.1.1
• sysName: 1.3.6.1.2.1.1.6.0

When discovering a network device where the SNMP sysDescr has been set to <SCRIPT>alert(“XSS-sysDescr”)<SCRIPT>. In this example, when device is viewed within SNMPc OnLine web console the JavaScript executes rendering an alert box, as shown below.

A second method of injection involves SNMP trap messages. The SNMPc product allows unsolicited traps, which are stored within the logs. By altering the data within a trap message a malicious actor could inject HTML and JavaScript code into the product. When the trap information is viewed the code will execute within the context of the authenticated user. The screenshot below shows an example attack where a trap message was used with the following HTML code `<embed src=//ld1.us/4.swf>` to embed flash into the SNMPc web console.

R7-2015-20.2, SQL Injection (CVE-2015-6028)

Examination of the SNMPc product also revealed a SQL Injection vulnerability within the “sc” parameter within the URL:

This injection point does require authentication to exploit. Leveraging the open source tool SQLMAP this vulnerability was simple to exploit and extract data from the application’s database.

The screenshot below demonstrates the extraction of database password hashes from the Microsoft SQL database.

Mitigations

In the absence of patches, customers should carefully control which devices and subnets are scanned for using SNMPc. In addition, login rights to the control console should be limited to only those users trusted with local administrator privileges on the host.

Disclosure Timeline

This vulnerability advisory was prepared in accordance with Rapid7’s disclosure policy.

• Mon, Sep 14, 2015: Discovered by Deral Heiland of Rapid7
• Tue, Sep 15, 2015: Vendor contact sought
• Wed, Sep 30, 2015: Disclosed to CERT
• Wed, Dec 16, 2015: Public Disclosure

R7-2015-21, Opsview Stored and Reflected XSS via SNMP (CVE-2015-6035)

Summary

Stored server and reflected client cross-site scripting (XSS) vulnerabilities in the web application component of Opsview via the Simple Network Management Protocol (SNMP).

Credit

This issue was discovered by independent researcher Matthew Kienow, and reported by Rapid7.

Products Affected

Opsview Version 4.6.3 was tested and exploited successfully.

Older versions may also be affected.

Description

A stored (AKA Persistent or Type I) server cross-site scripting (XSS) vulnerability exists in the Opsview web application due to insufficient filtering of Simple Network Management Protocol (SNMP) trap supplied data before the affected software stores and displays the data. Traps that will be processed by the affected software depend on the configuration of snmptrapd, the Net-SNMP trap notification receiver. This component may be configured to accept all incoming notifications or may be constrained by defined access control. In the latter case, the adversary must determine the SNMP authorization credentials before launching the attack. The affected software is capable of accepting traps from hosts registered or unknown to the system. The stored XSS attack code is delivered to the affected software via an object in the malicious SNMP trap. Once the trap is processed and determined to be an exception to any existing SNMP trap rules it will be stored as a trap exception. The code will execute when the user navigates to the SNMP Trap Exceptions page athttps://host:port/admin/snmptrapexception/list/unique.

In addition, a reflected (AKA Non-Persistent or Type II) client cross-site scripting (XSS) vulnerability exists due to insufficient filtering of SNMP agent supplied data before the affected software displays the data. The attack requires that the attack host has been registered with the system. The reflected XSS attack code is then delivered to the affected software during an SNMP Walk operation performed from the New Service Check page (https://host:port/admin/servicecheck/new). The attack host utilizes an SNMP agent to supply the desired attack code in response to SNMP Get messages for any object that can contain character data. For example, system objects such as sysDescr (1.3.6.1.2.1.1.1) and sysName (1.3.6.1.2.1.1.5), or objects under private enterprise management information bases (MIBs) unknown to the affected software may be used to deliver the attack code. The code will execute as soon as the SNMPwalk results are returned and displayed in the browser.

These attack methods allow an unauthenticated adversary to inject malicious content into the user’s browser session. This could cause arbitrary code execution in an authenticated user’s browser session and may be leveraged to conduct further attacks. The code has access to the authenticated user’s cookies and would be capable of performing privileged operations in the web application as the authenticated user, allowing for a variety of attacks.

Exploits

XSS strings can be injected into the Opsview web application via both SNMP traps and the SNMP agent.

SNMP Trap

The Opsview host used for the demonstration had snmptrapd configured to authorize processing of traps in the public community. A meaningless trap OID 1.3.6.1.4.1.123456789 was used to send an SNMPv2 trap in which the trap variables contain the single object sysName (1.3.6.1.2.1.1.5) set to the attack code<script>alert(‘Cookie: ‘ + document.cookie);</script>. After waiting a period of time for the trap to be processed, the user navigates to the SNMP Trap Exceptions page where the content is returned in a response to the user’s browser session and executed. An alert box is displayed that contains the cookies associated with the current document, as shown below.

SNMP Agent

An attack host is registered with the system and is operating an SNMP agent that returns <IMG SRC=/ onerror=alert(document.cookie) /> for the private enterprise OID 1.3.6.1.4.1.43555.1.1.1.999.0. When a user performs the SNMP Walk operation the content is returned in a response to the user’s browser session and the code is executed. An alert box is displayed that contains the cookies associated with the current document.

Mitigations

Affected users are advised to update to the latest version from the vendor.

Disclosure Timeline

This vulnerability advisory was prepared in accordance with Rapid7’s disclosure policy.

• Mon, Sep 28, 2015: Discovered by Matthew Kienow
• Tue, Sep 29, 2015: Vendor contact information sought
• Tue, Sep 29, 2015: Vendor acknowledged contact, requested details
• Tue, Sep 29, 2015: Details provided to vendor
• Mon, Oct 19, 2015: Details disclosed to CERT
• Fri, Nov 06, 2015: Vendor fixes released in versions 4.5.4 and 4.6.4
• Wed, Dec 16, 2015: Public Disclosure

Source:https://community.rapid7.com