Rapid7 Blog

Vulnerability Disclosure  

R7-2017-07: Multiple Fuze TPN Handset Portal vulnerabilities (FIXED)

This post describes three security vulnerabilities related to access controls and authentication in the TPN Handset Portal, part of the Fuze platform. Fuze fixed all three issues by May 6, 2017, and user action is not required to remediate. Rapid7 thanks Fuze for their quick…

This post describes three security vulnerabilities related to access controls and authentication in the TPN Handset Portal, part of the Fuze platform. Fuze fixed all three issues by May 6, 2017, and user action is not required to remediate. Rapid7 thanks Fuze for their quick and thoughtful response to these vulnerabilities: R7-2017-07.1, CWE-284 (Improper Access Control): An unauthenticated remote attacker can enumerate through MAC addresses associated with registered handsets of Fuze users. This allows them to craft a URL that reveals details about the user, including their Fuze phone number, email address, parent account name/location, and a link to an administration interface. This information is returned over HTTP and does not require authentication. R7-2017-07.2, CWE-319 (Cleartext Transmission of Sensitive Information): The administration interface URL revealed from the URLs enumerated in R7-2017-07.1 will prompt for a password over an unencrypted HTTP connection. An attacker with a privileged position on the network can capture this traffic. R7-2017-07.3, CWE-307 (Improper Restriction of Excessive Authentication Attempts): Authentication requests to the administration portal do not appear to be rate-limited, thus allowing attackers to potentially find successful credentials through brute-force attempts. Product Description Fuze is an enterprise, multi-platform voice, messaging, and collaboration service created by Fuze, Inc. It is described fully at the vendor's website. While much of the Fuze suite of applications are delivered as web-based SaaS components, there are endpoint client applications for a variety of desktop and mobile platforms. Credit These issues were discovered by a Rapid7 user, and they are being disclosed in accordance with Rapid7's vulnerability disclosure policy. Exploitation R7-2017-07.1 Any unauthenticated user can browse to http://mb.thinkingphones.com/tpn-portlet/mb/MACADDRESS and, if a valid MAC address is provided in place of MACADDRESS, receive a response that includes the following data about a Fuze handset user: Owner email address Account (including location information) Primary phone number Administration portal link Here is a (redacted) example of retrieving the above information using Fuze's TPN Portlet: While the total possible MAC address space is large (48 bits), the practical space in this case is significantly less. An attacker would only need to enumerate options starting with related published OUIs to target the subset of MAC addresses for Polycom and Yealink phones, which are the officially supported phone brands that Fuze offers as outlined here. For example, Polycom's OUIs are 00:04:F2 and 64:16:7F. An attacker can use this information to enumerate all Fuze customers/users with hard phones and collect their their email addresses, their phone numbers, and also access the Fuze device admin login page (shown below) and potentially make configuration changes. While it is common for handsets to request configuration from a remote server during boot, and indeed for those requests to not be authenticated, the fact that the configuration server is located in the cloud versus on-prem, and the fact that the specific URLs are crafted using a known pattern of MAC addresses, adds an unexpected surface for undesired information disclosure. R7-2017-07.2 Network traffic between a handset and the TPN Portal (http://mb.thinkingphones.com/tpn-portlet/mb/MACADDRESS/admin.jsp) are made over HTTP. Thus if an attacker is able to capture/intercept network traffic while the handset boots up, they would be able to view the content of requests made to the Portal, including the admin code, as shown below: R7-2017-07.3 If an attacker was not listening to network traffic during handset boot, they could still determine the administration portal URL by MAC enumeration as mentioned in R7-2017-07.1. Given that URL, the attacker could try various admin codes until they are successfully logged in, as it does not appear that authentication attempts are limited. Remediation Fuze addressed R7-2017-07.1 on April 29, 2017 by requiring password authentication to access the TPN portal (http://mb.thinkingphones.com/tpn-portlet/mb/MACADDRESS), and R7-2017-07.2 on May 6, 2017 by encrypting traffic to the TPN portal. No user action is required to remediate these two issues. Hashed passwords were pushed out by Fuze to customer handsets during a daily required update check. Handsets were also configured to use TLS for future communication with the portal at that time. After this update was pushed, Fuze's servers were configured to deny unauthenticated requests, as well as requests made over HTTP. If any handsets did not receive these updates, users would not be able to perform some actions from the handset directly, such as re-assigning to a new user. This may impact a small number of users, who should work with Fuze support to resolve. Phone re-assignment and other configuration changes can still be made and pushed from the Fuze server side. More importantly, if a handset did happen to be offline during the initial update push, once back online it would still be able to download firmware updates and essential configuration updates, including those related to SIP and TLS requirements. Fuze addressed R7-2017-07.3 on May 6, 2017 by rate limiting authentication attempts to the administration portal. In addition, MAC enumeration to find URLs providing the administration portal URLs is no longer possible given the authentication requirement. No user action is required to remediate this issue, as the change was made to Fuze's servers. Vendor Statement Rapid7 is a Fuze customer and a highly valued voice in ensuring that Fuze is continuously improving the security of its voice, video, and messaging service. As users of the entire Fuze platform, Rapid7’s team identified security weaknesses and responsibly disclosed them to the Fuze security team. In this case, while the exposure was a limited set of customer data, Fuze took immediate action upon receiving notification by Rapid7, and remediated the vulnerabilities with its handset provisioning service, in full, within two weeks. Fuze has no evidence of any bad actors exploiting this vulnerability to compromise customer data. Fuze is grateful to Rapid7 for its continued partnership in responsibly sharing security information, and believes in its larger mission to normalize the vulnerability disclosure process across the entire software industry. -- Chris Conry, CIO of Fuze* Disclosure Timeline Wed, Apr 12, 2017: Issues discovered by Rapid7 Tue, Apr 25, 2017: Details disclosed to Fuze Sat, Apr 29, 2017: R7-2017-07.1 fixed by Fuze Sat, May 6, 2017: R7-2017-07.2 and R7-2017-07.2 fixed by Fuze Tue, May 23, 2017: Disclosed to CERT/CC Fri, May 26, 2017: CERT/CC and Rapid7 decided no CVEs are warranted since these issues exist on the vendor's side, and customers do not need to take action. Tue, Aug 22, 2017: Public disclosure

You've Got 0-Day!

Hey all, it feels like it's been forever since I wrote a blog post that wasn't about some specific disaster currently consuming the Internet, so I just wanted to drop a note here about how I'll be speaking at UNITED 2017, Rapid7's annual security summit…

Hey all, it feels like it's been forever since I wrote a blog post that wasn't about some specific disaster currently consuming the Internet, so I just wanted to drop a note here about how I'll be speaking at UNITED 2017, Rapid7's annual security summit in Boston September 11-14. Specifically, I'll be closing out the Research and Collaborate track at UNITED on a topic near and dear to my heart: the vagaries of vulnerability disclosure. Vuln disclosure is a funny business; when you're on the receiving side, it's at best some unwelcome news about some bug in your product that's putting your customers at risk. If you're on the giving side, it's pretty much an invitation for angry letters from CTOs and their attorneys. So why bother? Turns out, despite all the emotional pain associated with it, reasonable vulnerability disclosure is pretty much the most effective tool we have to make the internet-connected products and services we produce and use that much stronger in the face of an increasingly hostile public network. We need vuln disclosure conversations in order to get better at what we do, since it's literally impossible to write, assemble, package, and deliver software of any complexity completely vulnerability-free on the first try. So, the goal of this talk is to share some stories about my experiences in vuln handling from both sides. As director of research here at Rapid7, I'm often the first point of contact for software and technology vendors when one of our researchers uncovers a vulnerability. On the flip side, I also get notifications about Rapid7 product bugs from security@rapid7.com, so I spend a fraction of my work life helping to get those bits of nastiness resolved. If you're looking for tips and advice on how to handle vulnerability disclosures—either as a discoverer, or as someone responsible for patching shipping software—then I hope my experiences will give you some insight into how this surprisingly emotion-driven business of disclosure works. Haven't yet signed up to join us at UNITED this year? Register here.

R7-2017-18: Logentries Windows Agent uses vulnerable OpenSSL (FIXED)

Summary The Logentries Windows Agent before version 2.6.0.1 shipped with a version of OpenSSL that is susceptible to several public vulnerabilities described below. While we have no indication that any Logentries customers have been compromised due to these older versions of OpenSSL,…

Summary The Logentries Windows Agent before version 2.6.0.1 shipped with a version of OpenSSL that is susceptible to several public vulnerabilities described below. While we have no indication that any Logentries customers have been compromised due to these older versions of OpenSSL, we strongly encourage Logentries customers to update Agents deployed to Windows systems using the steps outlined under “Remediation” below. Since the previously shipped version of OpenSSL was susceptible to several categories of vulnerabilities, this issue is classified as CWE-937 (Using Components with Known Vulnerabilities). If you have any questions about this issue, please reach out to support@logentries.com. UPDATE - 2017/08/04 Scan coverage to detect vulnerable versions of the Logentries Windows Agent was added to InsightVM in the 6.4.48 update on July 26, 2017. InsightVM customers can use this to verify that all their Logentries Agents are patched. Credit Rapid7 warmly thanks Dustin Heart for reporting this vulnerability to us, as well as providing information throughout the investigation to help us resolve the issue quickly. Am I affected? All versions prior to 2.6.0.1 of Logentries Windows Agent are vulnerable. Logentries Agents on Linux and OS X are not vulnerable, as they use the version of OpenSSL present on the assets on which they are installed. Vulnerability Details The Logentries Windows Agent uses the OpenSSL library as part of its communication with the Logentries servers. Before v2.6.0.1, the Logentries Windows Agent used OpenSSL v1.0.1e, which is vulnerable to a number of issues. The vast majority are Denial of Service type vulnerabilities, but there are a small number that have the potential to allow remote code execution and information disclosure by an attacker in a privileged position on the network. One notable information disclosure issue that this version is vulnerable to is CVE-2014-0160 (AKA “Heartbleed”). While Heartbleed can be a big issue in some attack scenarios, in this case, the risk is relatively low as any information that could be accessed would be log data limited to the affected asset. By default, the Logentries Windows Agent will follow Application, Security, and System Windows logs, and a hardware statistics log. Users can additionally follow logs related to Internet Explorer, Key Management, Media Center, PowerShell, and Hardware Events. These should not include critically sensitive information such as credentials, personally identifiable information (PII), or intellectual property, but may include sensitive environment and user information. If your Logentries Windows Agent is configured to follow application logs, there is a possibility of more sensitive information being exposed. In addition, triggering an information leak from memory is reasonably complicated as it requires the Agent to connect to a malicious server. This could be accomplished by, for example, a man-in-the-middle (MITM) scenario, privileged access to the asset running the Agent (in order to set alternate host entries for the Logentries servers), or DNS cache poisoning attacks. The Logentries Windows Agent also failed to correctly validate TLS certificates and would fall back to plaintext HTTP if errors were encountered during HTTPS connections. This is especially problematic during the Agent update process and when setting username and password (only asked when setting up new installations). The latest version of the Logentries Windows Agent uses the most current version of the OpenSSL 1.0.2 series, v1.0.2l, which fixes all of the vulnerabilities described above. Rapid7 has also ensured that the Insight Agent is shipping with the latest OpenSSL libraries. Remediation Administrators should update all deployed Logentries Windows Agents to v2.6.0.1 through the following steps: Download the latest zip of Logentries Windows Agent here Verify you have the latest patched Windows-Agent.zip via the following checksums: MD5: 1c76f076d08c70ac43467e31c1125bda SHA256: b2ade2356a52e8dde136a2bb451c56df1cfbd6b5639e1b1b58686d861e6b4887 Unzip the zip file Run the extracted .exe file as an Administrator Follow the GUI prompts Once finished, you can verify the Agent version by clicking the Help tab in the GUI: Additional documentation for the Logentries Windows Agent is available here. Disclosure Timeline Thu, Jun 15, 2017: Vulnerability reported to Rapid7 Fri, Jun 16, 2017: Vulnerability confirmed by Rapid7 Wed, Jun 21, 2017: Rapid7 assigned CVE-2017-5245 for this issue Thurs, Jul 13, 2017: Patch for Logentries Windows Agents made available Thurs, Jul 13, 2017: Public disclosure Thurs, Jul 13, 2017: Disclosed to MITRE Tue, Jul 18, 2017: MITRE rejected CVE-2017-5245 assignment for this issue. A new CVE was not necessary, as we can instead reference the CVEs that impact the outdated dependency, i.e. those affecting OpenSSL v1.0.1e used by LogEntries Windows Agent before v2.6.0.1.

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-2017-16 | CVE-2017-5244: Lack of CSRF protection for stopping tasks in Metasploit Pro, Express, and Community editions (FIXED)

Summary A vulnerability in Metasploit Pro, Express, and Community was patched in Metasploit v4.14.0 (Update 2017061301). Routes used to stop running tasks (either particular ones or all tasks) allowed GET requests. Only POST requests should have been allowed, as the stop/stop_all…

Summary A vulnerability in Metasploit Pro, Express, and Community was patched in Metasploit v4.14.0 (Update 2017061301). Routes used to stop running tasks (either particular ones or all tasks) allowed GET requests. Only POST requests should have been allowed, as the stop/stop_all routes change the state of the service. This could have allowed an attacker to stop currently-running Metasploit tasks by getting an authenticated user to execute JavaScript (example below). As of Metasploit 4.14.0 (Update 2017061301), the routes for stopping tasks only allow POST requests, which validate the presence of a secret token to prevent CSRF attacks. CVE-2017-5244 is classified as CWE-352 (Cross-Site Request Forgery), and its CVSSv3 base score is 3.1. This is a lower severity issue due to the complexity of deployment and the lack of data exposure, but we nevertheless strongly encourage Metasploit users to update their instances using the steps outlined under “Remediation” below. In addition, Rapid7 will be doing further review of other important routes to verify they properly restrict access. Credit Rapid7 warmly thanks Mohamed A. Baset (Founder and Cyber Security Advisor at Seekurity.com SAS de C.V. Mexico; @SymbianSyMoh) for reporting this vulnerability to us, as well as providing information to help us resolve the issue and protect Metasploit users. You can read his report on the issue here. Am I affected? Versions of Metasploit Pro, Express, and Community editions before 4.14.0 (Update 2017061301) are vulnerable to CVE-2017-5244, regardless of operating system. Additional details and exploitation While POST requests go through normal Rails anti-CSRF verification, this doesn't apply to GET requests. Routes that aren't idempotent (i.e. they make changes) need to be limited to POST only. Since that was not the case before this patch, and the stop action could be triggered through GET requests, an attacker able to trick an authenticated user to request a URL which runs JavaScript could trigger the same action. It may also be possible to exploit this vulnerability by injecting network traffic impersonating the same request. This video shows the reporter exploiting this vulnerability to stop a running discovery scan. Example exploitation Javascript calling the affected route after 5 seconds: <script> setInterval(function(){ window.location.replace("https://127.0.0.1:3790/tasks/stop_all"); }, 5000); </script> Regardless of vector, the result of that route being called by an authenticated user would be to stop all running tasks (e.g. discovery scans, report generation). This should show up in UI notifications and task logs. In terms of impact, while some tasks can be replayed (i.e. restarted with the same configuration), there's no way to resume the stopped tasks; thus data limited to that task may be not be saved to the database, and therefore lost. Remediation We strongly encourage Metasploit users to update their instances to the latest version (Metasploit 4.14.0 (Update 2017061301) or above). You can find detailed update steps here. Release notes and offline installers are available here. Disclosure Timeline Sat, May 27, 2017: Vulnerability reported to Rapid7 by Mohamed A. Baset Tue, May 30, 2017: Vulnerability confirmed by Rapid7 Fri, June 9, 2017: Vulnerability fixed by Rapid7 Sun, June 11, 2017: Rapid7 assigned CVE-2017-5244 to this vulnerability Wed, June 14, 2017: Rapid7 released patch; public disclosure Wed, June 14, 2017: Rapid7 reported vulnerability to MITRE

R7-2017-05 | CVE-2017-3211: Centire Yopify Information Disclosure

This post describes a vulnerability in Yopify (a plugin for various popular e-commerce platforms), as well as remediation steps that have been taken. Yopify leaks the first name, last initial, city, and recent purchase data of customers, all without user authorization. This poses a significant…

This post describes a vulnerability in Yopify (a plugin for various popular e-commerce platforms), as well as remediation steps that have been taken. Yopify leaks the first name, last initial, city, and recent purchase data of customers, all without user authorization. This poses a significant privacy risk for customers. This vulnerability is characterized as: CWE-213 (Intentional Information Disclosure). Product Description Yopify is a notification plugin for a variety of e-commerce platforms, including BigCommerce, WooCommerce, Shopify, and LemonStand. The product is produced by Centire, an IT company based in India. Yopify provides a feature where website visitors are, every few seconds, presented with a popup containing information about one of the last 50 purchases from the site, such as the one shown here: The purported use case is that by demonstrating existing customer activity, it replicates the public bustle and hubbub of a real-world shop, and makes potential customers more engaged. As you can see, the example above contains personal information about the customer (first name, last initial, city). The various plugin sites for major e-commerce platforms show over 300 reviews of Yopify, which suggests that the number of exploitable sites is at least in the hundreds, and perhaps thousands. Credit This vulnerability was discovered by Oliver Keyes, a Rapid7, Inc. senior data scientist. This advisory was prepared in accordance with Rapid7's vulnerability disclosure policy. Exploitation Yopify works by having the e-commerce site load a JavaScript widget from the Yopify servers, which contains both the code to generate the UI element and the data used to populate it, stored as JSON. This widget does not require any authorization beyond a site-specific API key, which is embedded in the e-commerce site's source code, and is easily extractable with a regular expression. The result is that by scraping a customer site to grab the API key and then simply running something like: curl 'https://yopify.com/api/yo/js/yo/3edb675e08e9c7fe22d243e44d184cdf/events.js?t=1490157080' where 3edb675e08e9c7fe22d243e44d184cdf is the site ID and t is a cache buster, someone can remotely grab the data pertaining to the last 50 customers. This is updated as purchases are made. Thus an attacker can poll every few hours for a few days/weeks/months and build up a database of an e-commerce site's customer set and associated purchasers. The data exposed to this polling was, however, far more extensive than the data displayed. While the pop-up only provides first name and last initial, the JSON blob originally contained first and last names in their entirety, along with city-level geolocation. While the casual online customer wouldn't have seen that, a malicious technical user could have trivially gained enough information to potentially target specific users of specific niche e-commerce sites. Vendor Statement We were unaware of this security threat when we created the app, however have taken the necessary steps alongside Shopify and Rapid7 to come to a satisfactory resolution where users privacy exposure is reduced. Remediation Minimally, we believe users should be asked if they want their name, location, and purchase information shown to complete strangers. Sending and display of the information should be off by default to protect customer privacy and safety. On May 18, Yopify responded to the bug report by Base64-encoding the JSON blob. This obfuscation may stop some unsophisticated users from finding the information, but it is in no way encrypted. However, by May 20 Yopify did make an additional update and the client no longer receives the full last name even in the JSON, but only the first letter of the last name. This is an improvement as it does limit the exposure of user data, and makes identifying individuals more difficult. However, as personal information is still sent and displayed, we recommend that until Yopify adds opt-in functionality, users with privacy concerns avoid using e-commerce sites with Yopify installed. Users will know it is installed given the frequent pop-ups displaying other customers' information when they browse an affected site. In addition, we encourage e-commerce store owners to request Yopify add this functionality, or remove the widget in order to protect their customers' privacy. Disclosure Timeline This vulnerability advisory was prepared in accordance with Rapid7's vulnerability disclosure policy. Tue, Feb 28, 2017: Discovered by Rapid7's Oliver Keyes Wed, Mar 22, 2017: Initial vendor contact (Yopify) Thu, Mar 30, 2017: Additional vendor contact (Shopify), as no response received from Yopify yet Thu, Mar 30, 2017: Response from Shopify Fri, Mar 31, 2017: Details sent to security@shopify.com, who forwarded information to Yopify Wed, Apr 5, 2017: Additional vendor contact (Centire). Sent reminder to Yopify, and clarification/update to Shopify. Fri, Apr 7, 2017: Additional disclosure to yopify@gmail.com Fri, Apr 7, 2017: Disclosed to CERT/CC Fri, Apr 14, 2017: Reached back out to info@yopify.com, no response Wed, Apr 26, 2017: CVE-2017-3211 assigned by CERT/CC Wed, May 17, 2017: Reached back out to Yopify and Centire Thu, May 18, 2017: First response from Yopify; JSON Base64 encoding change deployed Sat, May 20, 2017: Additional patch deployed by Yopify: full last name no longer sent to client, only first letter Wed, May 31, 2017: Public disclosure

R7-2016-23, R7-2016-26, R7-2016-27: Multiple Home Security Vulnerabilities

Executive Summary In October of 2016, former Rapid7 researcher Phil Bosco discovered a number of relatively low-risk vulnerabilities and issues involving home security systems that are common throughout the United States, and which have significant WiFi or Ethernet capabilities. The three systems tested were offerings…

Executive Summary In October of 2016, former Rapid7 researcher Phil Bosco discovered a number of relatively low-risk vulnerabilities and issues involving home security systems that are common throughout the United States, and which have significant WiFi or Ethernet capabilities. The three systems tested were offerings from Comcast XFINITY, ADT, and AT&T Digital Life, and the issues discovered ranged from an apparent "fail open" condition on the external door and window sensors, to weak, pre-shared WiFi access passwords, to cleartext communications over the network. Rapid7 has been in touch with all three vendors over the last few months, per our standard disclosure policy, and was involved with both communicating the issues and helping to resolve them in a timely manner. Today, we're happy to report that all of the identified issues have been either resolved or sufficiently mitigated against! In all cases, customers who use these products for home security should not need to apply patches manually or otherwise alter their current system configurations for any software updates, as all vendors have the capability to remotely update any problematic networked components. Before getting into the technical details of the issues discovered, we'd like to state that risk of exploitation of these issues was relatively low before fixes were implemented. In all cases, attackers would have to be reasonably close to the target's residence, and in some cases, be in possession of low-power jamming equipment. Attackers could not exploit these issues from across the Internet. Finally, we also would like to acknowledge ADT, AT&T Digital Life, and Comcast XFINITY for their responsiveness and engagement in discussing, validating and resolving these issues in a timely fashion. Methodology The issues discovered and documented in this advisory were all discovered using standard assessment tools and techniques applied to a single residential installation in the researcher's home, and all equipment was originally installed by authorized technicians. All screenshots, video captures, and other evidence of compromise were collected from the researcher's own systems. It's important to note that the two "Insecure Sensor Fail Open" issues identified as R7-2016-26.1 and R7-2016-27.1 were discovered by using radio frequency (RF) shielding, rather than RF jamming. In a shielded test, the researcher is able to guarantee a failure event on the sensors by physically wrapping the sensors in RF-blocking material, and observing the resulting behavior on on the systems' base stations. In this way, the researcher may be able to simulate a radio interference condition, rather than actually creating one. While shielding has the advantage of creating a more controlled failure event, one shortcoming of this technique is that shielding will not activate any RF interference detection on the base stations, since no detectable RF noise is generated. In short, shielding creates an ideal situation for testing failure conditions, while an active RF jamming event more closely resembles an actual attack. Unfortunately, intentionally creating RF interference, even for the purpose of testing one's own equipment, continues to be a contentious subject in the offensive security testing community, and so shielding is meant as the closest approximation of what low power jamming would do. Vulnerability Overview Below is an overview of the vulnerabilities and exposures discovered during testing. Each vendor's home security platform is explored in turn, along with any recommended remediations or mitigations, as well as a statement provided by the vendor. Again, all vulnerabilities were disclosed and discussed privately with each vendor before publication. Description Vendor R7 ID CVE Status Insecure Sensor Fail Open ADT R7-2016-26.1 CVE-2016-6570 Mitigated by sensor placement Weak WPA2 Pre-Shared Key ADT R7-2016-26.2 CVE-2016-6571 Fixed Cleartext WLAN Communications ADT R7-2016-26.3 CVE-2016-6572 Mitigated by R7-2016-26.2 Insecure Sensor Fail Open AT&T Digital Life R7-2016-27.1 CVE-2016-6573 Mitigated by sensor placement Default physical access administrative credentials AT&T Digital Life R7-2016-27.2 CVE-2016-6574 Fixed Insecure Network Administrative Access AT&T Digital Life R7-2016-27.3 CVE-2016-6575 Mitigated by R7-2016-27.2 Cleartext WLAN Communications AT&T Digital Life R7-2016-27.4 CVE-2016-6576 Mitigated by R7-2016-27.2 Cleartext Credential Storage and Display AT&T Digital Life R7-2016-27.5 CVE-2016-6577 Mitigated by R7-2016-27.2 Weak WPA2 Pre-Shared Key Comcast XFINITY R7-2016-23.1 CVE-2016-6568 Fixed Cleartext WLAN Communications Comcast XFINITY R7-2016-23.2 CVE-2016-6569 Mitigated by R7-2016-23.1 In the cases involving the WiFi networked components, potential attackers would have to be reasonably close to the target's residence and within line-of-sight, and are limited by the signal strength of the attacking equipment. They could not exploit these issues from across the internet, and could not scale these attacks outside of a limited geographic range. In the cases of creating RF interference to cause external door and window sensors to go offline, the attacker would need to carefully modulate their interference signal strength in order to avoid triggering anti-jamming detection technologies already provided by the vendor. Triggering these detection mechanisms would cause an alert to be sent to the vendor's normal monitoring systems. In addition, onsite motion sensors installed as part of the complete security system would either be wired – and thus immune to radio frequency interference – or wireless, which would make it extremely difficult to jam both an external sensor and an internal sensor yet still avoid triggering anti-jamming detection. In cases of the cleartext transmission vulnerabilities and exposures documented in this advisory, these are dependent on other vulnerabilities being exploited first. For example, if an attacker finds it impossible to associate to the network, it is immaterial (practically speaking) that the communications over that WiFi network are themselves in the clear, as all of the home security WiFi networks employ industry-standard encryption provided by WiFi Protected Access II (WPA2). That said, a defense-in-depth posture is usually recommended for networks that carry sensitive information, so that a failure in one component does not expose the entire network and its assets to compromise. R7-2016-26: ADT Home Security Three issues were identified with ADT's home security solution: Exterior sensors appear to fail open when RF transmissions are blocked; systems were installed with a weak, pre-shared WPA2 key for authentication to the wireless network; and cleartext communications on that network. A failure condition in the 908.42 MHz radio frequency band will cause the system to fail open, and the base system will fail to report a communications failure with the associated devices. In addition, due to a weak, pre-shared key shipping with the WiFi access point component of the product, an attacker can rapidly compromise the network on which the security cameras communicate. Finally, all communications to and from the security cameras are conducted in the clear. Once an attacker is associated with the WiFi network, it is possible to capture the administrative credentials to the camera and the provided access point's administrative credentials. R7-2016-26.1: ADT Insecure Sensor Fail Open (CVE-2016-6570) A failure condition in the sensor's RF band can cause the system to fail open, and the base system may fail to report a communications failure with the associated devices. Exploiting the insecure fail open issue can be accomplished with commodity RF jammers. Failing Open In order to cause the system to fail open, an attacker would need to block communication in the sensor's RF band. While jamming devices are illegal to operate in the US, they are relatively easy to buy or build using commodity electronics equipment. This issue is essentially identical to R7-2015-23: Comcast XFINITY Home Security System Insecure Fail Open, and those details are immediately applicable in this case. For testing purposes, jamming was simulated by physically shielding the devices to effectively block all radio communications. Remediation The RF jamming attack can be mitigated by two shipping solutions. One, the system's base station is equipped with interference detection, so an attacker would need to ensure that any jamming signal has sufficient power to effectively block communication from the exterior sensor, but not so much power as to be detected by the base station. Two, many of ADT's home security systems are installed with interior, wired motion sensors. Because these sensors do not rely on RF communications, they are effectively immune to this attack, and therefore, any movement after jamming the exterior sensor will be alerted on by these motion sensors. In the case where interior motion sensors are wireless, again, the attacker would need to ensure that jamming is sufficient to block both the exterior sensor and the interior motion sensor, but not the base station. Such an attack would be extremely tricky to implement, require physical reconnaissance in order to plan the attack, and may be impossible depending on the placement of the base station and interior motion sensors. R7-2016-26.2: ADT Weak WPA2 Pre-Shared Key (CVE-2016-6571) Exploiting the weak WPA2 pre-shared key (PSK) can be accomplished with a WiFi deauthentication and offline cracking attack. Deauthentication First, an attacker would locate the ADT gear, using standard tools such as the Aircrack-NG WiFi security assessment toolkit. Figure 1 demonstrates the use of airodump-ng<span>.</span> Once identified, the attacker can then deauthenticate one of the cameras, as shown in Figure 2. Doing this allows the attacker to capture the WPA2 handshake, which is then subjected to cracking with Aircrack-ng, as shown in Figure 3. Because the vendor-supplied password is exactly thirteen characters, consisting only of numbers, it generally does not take very much time to crack with typical consumer-grade hardware. Remediation The vendor updated all components of customers' WiFi networks with a more complex generated password during the first quarter of 2017. R7-2016-26.3: ADT Cleartext WLAN Communications (CVE-2016-6572) Exploiting the cleartext communications can be achieved once the attacker is associated with the special-purpose WiFi network, and can provide an attacker with administrative credentials and direct camera feeds. Camera Credential Collection Once the attacker recovers the WPA2 pre-shared key, they can then connect to the device network and capture a camera's credentials via a brief ARP spoofing attack and posing as the base station. This is shown in Figure 4. The attacker can then reuse these credentials to log in the cameras directly and access live video feeds, as seen in Figure 5. Remediation The upgraded password complexity implemented as a solution R7-2016-26.2 makes associating to the WiFi network difficult to impossible, and thus, effectively mitigates the malicious use of cleartext communications on the WPA2 WiFi network. R7-2016-27: AT&T Digital Life Home Security Five issues were identified with AT&T Digital Life's home security solution: exterior sensors appear to fail open when RF transmissions are blocked; physical network access is governed by an easily-guessed default administrative credential; network administrative access does not challenge for a credential; the WiFi network uses cleartext communications; and saved credentials are stored and displayed in cleartext. AT&T Digital Life's home security systems ship with a base station, window and door sensors, motion sensors, wireless cameras, and a mobile app, as described by the vendor. A failure condition in the 433.92 MHz radio frequency band used by AT&T Digital Life's third party home security equipment can cause the system to fail open, and the base system may fail to report a communications failure with the associated devices. WiFi access control appears to be sufficient and reasonable, since the WPA2 network is secured with a 32-character password made up of uppercase, lowercase, and numeric characters. Due to an installation error, access to this network can be accomplished via a physically accessible LAN Ethernet port to the base station, and access to the shipped Cisco management interface is controlled by easily-guessed default credentials. Since the time of this discovery, AT&T Digital Life has updated their installation procedures to ensure that this LAN Ethernet port is disabled after initial setup on customer sites. R7-2016-27.1: AT&T Digital Life Insecure Sensor Fail Open (CVE-2016-6573) A failure condition in the sensor's RF band can cause the system to fail open, and the base system may fail to report a communications failure with the associated devices. Exploiting the insecure fail open issue can be accomplished with commodity RF jammers. Failing Open In order to cause the system to fail open, an attacker would need to block communication in the sensor's RF band. While jamming devices are illegal to operate in the US, they are relatively easy to buy or build using commodity electronics equipment. This issue is essentially identical to R7-2015-23: Comcast XFINITY Home Security System Insecure Fail Open, and those details are immediately applicable in this case. For testing purposes, jamming was simulated by physically shielding the devices to effectively block all radio communications. It should be noted that AT&T does not believe that jamming (unlike shielding) can be performed without triggering certain anti-jamming alerts. Remediation The RF jamming attack can be mitigated by two shipping solutions. One, the system's base station is equipped with interference detection, so an attacker would need to ensure that any jamming signal has sufficient power to effectively block communication from the exterior sensor, but not so much power as to be detected by the base station. Two, AT&T Digital Life's home security systems are typically installed with at least one interior, wireless motion sensor. In this case, the attacker would need to ensure that jamming is sufficient to block both the exterior sensor and the interior motion sensor, but not the base station. Depending on the placement of the interior motion sensor, such an attack could be extremely tricky to implement, since it would require physical reconnaissance in order to plan the attack, and may be impossible depending on the relative placement of the base station and interior motion sensors. R7-2016-27.2: AT&T Digital Life Default physical access administrative credentials (CVE-2016-6574) If an attacker is able to physically access the base station and connect to an enabled Ethernet port, access to an administrative interface is possible. Physical-Only Administrative Access Assuming an attacker can physically connect to the base station via an Ethernet port, they can connect to an administrative web service on the default gateway (http://192.168.29.1:80) and provide the easily-guessed login credentials of "admin:admin." From here, the attacker has complete administrative control over the device and can learn the WiFi SSID and pre-shared key. This key would be difficult to impossible to crack in an offline deauthentication attack, since it is a complex, 32-character string. However, once physical access is achieved and the administrative interface is loaded in a browser, the key is displayed to the logged-in attacker. Remediation During testing, disabling the Ethernet diagnostic port was a manual step that field technicians could accidentally skip, and that appears to have been the case during the installation at the researcher's residence. Since this report, AT&T Digital Life has thoroughly reviewed its automatic post-installation verification procedures, and now ensures that every installation of its home security system does, in fact, disable the physical Ethernet port. Disabling this port does not require an on-premises visit, and can be achieved remotely by AT&T Digital Life. It is impossible to enable this port locally; field technicians must activate this port with an authenticated service call. R7-2016-27.3: AT&T Digital Life Insecure Network Administrative Access (CVE-2016-6575) If it is possible to learn the WPA2 pre-shared key, other administrative interfaces become available to the attacker over the local WiFi network. Port 8090 Once the attacker is associated with the WiFi network, he can then connect to the administrative web interface for the system, which is listening on port 8090/TCP. This interface does not challenge for authentication credentials, and from this interface, the attacker can add or remove devices, cameras and keypads, and can also disarm any alarm-related functionality, as shown below. Remediation As there is no reasonable way for an attacker to perform an offline bruteforce attack on the WPA2 key due to the strength of this pre-generated key, physical access is required as well as access to an active, administrative Ethernet LAN port. Therefore, due to remediations provided in R7-2016-27.1 and R7-2016-27.2 described above, this attack vector is effectively mitigated. R7-2016-27.4: AT&T Digital Life Cleartext WLAN Communications (CVE-2016-6576) If an attacker can achieve wireless administrative access, credentials can be learned through ARP spoofing. Camera Credential Collection Once the attacker recovers the WPA2 pre-shared key, he can then connect to the device network, and capture a camera's credentials via a brief ARP spoofing attack and posing as the base station. This is shown in Figure 9. Remediation As with R7-2016-27.3 above, the remediations provided for R7-2016-27.2 effectively mitigate this attack, since the attacker can no longer learn the WPA2 pre-shared key. R7-2016-27.5: AT&T Digital Life Cleartext Credential Storage and Display (CVE-2016-6577) If an attacker can achieve wireless administrative access, credentials can be learned directly from associated devices. These credentials can be discovered without ARP spoofing by accessing the administration web page on port 8090, since it is displayed in cleartext, as shown in Figure 10. Remediation As with R7-2016-27.3 and R7-2016-27.4 above, the remediations provided for R7-2016-27.2 effectively mitigate this attack, since the attacker can no longer learn the WPA2 pre-shared key. R7-2016-23: Comcast XFINITY Home Security A certain generation of Comcast XFINITY's Home Security product was found to utilize a weak algorithm to generate its per-premise WPA2 security key. While a sufficiently random WPA2 key cannot be bruteforced, the weak keys generated by the algorithm in question could be bruteforced in one to two months on average with commodity hardware, giving a physically-proximate and persistent attacker access to the WiFi network over which the touchscreen and cameras communicate. Once the attacker achieved access to the network, they could have captured administrative credentials to the camera and the access point, which are sent in the clear between the touchscreen and these two devices. Finally, it was noticed that the URLs used to view camera feeds were not protected by session authentication. While session-controlled access to individual feeds is a more standard approach to securing video streams, the URLs were randomized with a sufficient (128-bit) keyspace to prevent live brute-forcing. Access is conducted over HTTPS, and the URLs are periodically regenerated. After discussing this approach with Comcast XFINITY and CERT/CC, we came to the conclusion that this implementation does not present any practical security concerns. Nonetheless, Comcast XFINITY agreed with our suggestion and has since implemented session authentication as an additional layer of security. R7-2016-23.1: Comcast XFINITY Weak WPA2 Pre-Shared Key (CVE-2016-6568) Exploiting the weak WPA2 PSK can be accomplished with a WiFi deauthentication and offline cracking attack. Deauthentication First, an attacker would locate the Comcast XFINITY gear, using standard tools such as the Aircrack-NG WiFi security assessment toolkit. Figure 11 demonstrates the use of airodump-ng: Once identified, the attacker can then deauthenticate one of the cameras, as shown in Figure 12: Doing this allows the attacker to capture the WPA2 handshake, which is then cracked using aircrack-ng, as shown in Figure 13: Because the vendor-supplied password is exactly eight characters, consisting of uppercase letters and numbers, it is quite feasible to crack this password with typical consumer-grade hardware. Remediation The vendor has updated all components of customers' WiFi networks with a much longer, mixed-character password, during a staged rollout across all installations throughout the first quarter of 2017. R7-2016-23.2: Comcast XFINITY Cleartext WLAN Communications (CVE-2016-6569) Exploiting the cleartext communications can be achieved once the attacker is associated with the special-purpose WiFi network, and can provide an attacker with administrative credentials. Camera Credential Collection Once the attacker recovers the WPA2 pre-shared key, they can then connect to the device network and capture a camera's credentials via a brief ARP spoofing attack and posing as the base station. This is shown in Figure 14. The attacker can then reuse these credentials to log in the camera base station, and access live video feeds. An example taken from the researcher's camera is shown in Figure 15. Router Credential Collection Both the administrative touch screen and the cameras log into the WiFi router periodically to check for firmware updates. By ARP spoofing the router interface, the router's administrative credentials can also be collected. This is shown in Figure 16. Once administrative router access is secured, the attacker can perform all normal administrative functions, such as providing a malicious firmware update or redirecting DNS traffic to a name server controlled by the attacker, as seen in Figure 17. Remediation The upgraded password complexity implemented as a solution to R7-2016-23.1 makes associating to the WiFi network difficult to impossible, and thus effectively mitigates the malicious use of cleartext communications on the WPA2 WiFi network. Vendor Statement on R7-2016-23 Our customers' safety and security is our top priority.  We have developed and deployed fixes for the issues reported by Rapid7, which they identified as low-risk. For the vast majority of affected customers, these issues are fully mitigated. A small number of XFINITY Home customers need to make manual updates, and we are contacting those customers by email and/or phone. At XFINITY Home, we regularly perform stringent information security testing of our products, both before and after we launch them.  However, no product can ever be completely free of security vulnerabilities, and experts intent on hacking into any system will discover vulnerabilities.  So another way we maintain our customers' trust is by responding quickly and effectively to reported vulnerabilities. We are grateful to Rapid7 security researcher Phil Bosco and research director Tod Beardsley for responsibly disclosing these vulnerabilities to us.  While Rapid7 identified these issues as low risk, XFINITY Home moved quickly to remediate them. Credit All of the issues described in this vulnerability disclosure were discovered by former Rapid7 researcher Phil Bosco and disclosed by Rapid7 according to our standard disclosure policy. Disclosure Timeline R7-2016-26 (ADT) Wed, Oct 26, 2016: Vendor contacted Fri, Oct 28, 2016: Disclosed details to the vendor Wed, Nov 09, 2016: Discussed details with the vendor Fri, Nov 18, 2016: Disclosed details to CERT/CC Mon, Nov 21, 2017: CERT/CC assigned CVE-2016-6570, CVE-2016-6571, and CVE-2016-6572 Fri, Jan 27, 2017: Discussed vendor's plans for remediation Thu, Mar 16, 2017: Vendor confirmed remediation is on track Fri, Apr 28, 2017: Further clarification from the vendor on mitigations (ongoing through May) Wed, May 17, 2017: Public disclosure of R7-2016-26. R7-2016-27 (AT&T Digital Life) Wed, Oct 26, 2016: Vendor contacted Mon, Nov 07, 2016: Details disclosed to the vendor Wed, Nov 09, 2016: Discussed details with the vendor Fri, Nov 18, 2016: Disclosed details to CERT/CC Mon, Nov 21, 2017: CERT/CC assigned CVE-2016-6573, CVE-2016-6574, CVE-2016-6575, CVE-2016-6576, and CVE-2016-6577 Thu, Jan 12, 2017: Clarified fixes and mitigations with the vendor Tue, Mar 28, 2017: Further clarifications on disclosure content with the vendor (ongoing through May) Wed, May 17, 2017: Public disclosure of R7-2016-27. R7-2016-23 (Comcast XFINITY) Wed, Oct 26, 2016: Vendor contacted Fri, Oct 28, 2016: Disclosed details to the vendor Tue, Nov 08, 2016: Discussed details with the vendor Fri, Nov 18, 2016: Disclosed details to CERT/CC Mon, Nov 21, 2017: CERT/CC assigned CVE-2016-6568 and CVE-2016-6569 Fri, Jan 27, 2017: Discussed vendor's plans for remediation Thu, Mar 16, 2017: Vendor confirmed remediation is on track (ongoing through May) Thu, Mar 16, 2017: Vendor also implemented session controls for video URLs Wed, May 17, 2017: Public disclosure of R7-2016-23.

On the lookout for Intel AMT CVE-2017-5689

We've had some inquiries about checks for CVE-2017-5689, a vulnerability affecting Intel AMT devices. On May 5th, 2017, we released a potential vulnerability check that can help identify assets that may be vulnerable. We initially ran into issues with trying to determine the exact version…

We've had some inquiries about checks for CVE-2017-5689, a vulnerability affecting Intel AMT devices. On May 5th, 2017, we released a potential vulnerability check that can help identify assets that may be vulnerable. We initially ran into issues with trying to determine the exact version of the firmware remotely, and so a potential check was released so that you would still be able to identify devices that may be impacted by this.We didn't stop there though. As part of yesterday's Nexpose release, we issued an updated vulnerability check that is a remote direct condition test that will definitively identify the issue if it is present. Detection of this vulnerability does not require authentication to the asset.Please note, you will have to modify your scan template to include a couple of extra TCP ports: 16992 and 16993. To learn more about how to configure your scan template see this help page for details. Happy Hunting!UPDATE - May 12th, 2017: On Wednesday, May 10th, we also added an unauthenticated scanner in Metasploit to check for vulnerable systems in a network, gathering metadata such as firmware version, serial number, vendor, and model number.

R7-2017-03: Improper Access Control of Fuze Meeting Recordings (FIXED)

This post describes a security vulnerability in the Fuze collaboration platform, and the mitigation steps that have been taken to correct the issue. The Fuze collaboration platform did not require authentication to access meeting recordings (CWE-284). Shortly after being informed of this issue, Fuze disabled…

This post describes a security vulnerability in the Fuze collaboration platform, and the mitigation steps that have been taken to correct the issue. The Fuze collaboration platform did not require authentication to access meeting recordings (CWE-284). Shortly after being informed of this issue, Fuze disabled public access to all recorded meetings, and implemented user-configurable controls in the client application to mediate public access to shared meeting recordings. Affected recordings that had already been shared were reviewed and addressed as well. Rapid7 thanks Fuze for their timely and thoughtful response to this issue. Product Description Fuze is an enterprise, multi-platform voice, messaging, and collaboration service created by Fuze, Inc. It is described fully at the vendor's website. While much of the Fuze suite of applications are delivered as web-based SaaS components, there are endpoint client applications for a variety of desktop and mobile platforms. Credit This issue was discovered by Samuel Huckins of Rapid7 (that's me 😉 ), and is being disclosed in accordance with Rapid7's vulnerability disclosure policy. Exploitation Recorded Fuze meetings are saved to Fuze's cloud hosting service. They could be accessed by URLs such as "https://browser.fuzemeeting.com/?replayId=7DIGITNUM", where "7DIGITNUM" is a seven digit number that increments over time. Since this identifier did not provide sufficient keyspace to resist bruteforcing, specific meetings could be accessed and downloaded by simply guessing a replay ID reasonably close to the target, and iterating through all likely seven digit numbers. This format and lack of authentication also allowed one to find recordings via search engines such as Google. Vendor Statement Security is a top priority for Fuze and we appreciate Rapid7 identifying this issue and bringing it to our attention. When we were informed by the Rapid7 team of the issue, we took immediate action and have resolved the problem. Remediation As of Mar 1, 2017, all meeting recordings now appear to require password authentication in order to be viewed from Fuze's cloud-hosted web application via direct browsing or from the Fuze desktop and mobile clients. This authentication control is configurable by the user via the client applications as of version 4.3.1 (released on Mar 10, 2017). Fuze users are encouraged to update their Fuze client applications in order to take advantage of new access controls. Additional options, such as downloading the recording locally, are available at https://account.fuzemeeting.com/#/recordings. Disclosure Timeline Thu, Feb 23, 2017: Discovered by Samuel Huckins of Rapid7. Mon, Feb 27, 2017: Vulnerability verified by Rapid7. Mon, Feb 27, 2017: Vulnerability details disclosed to Fuze. Wed, Mar 01, 2017: Fuze disabled public access to meeting recordings. Fri, Mar 10, 2017: Version 4.3.1 of Fuze endpoint client released, providing authentication controls for recorded meetings. Tue, Mar 15, 2017: Vulnerability details disclosed to CERT/CC. Tue, Mar 21, 2017: VU#590023 assigned by CERT/CC to track this issue. Tue, Apr 25, 2017: CERT/CC and Rapid7 decided not to issue a CVE for this vulnerability. The issue was primarily on Fuze's servers, thus the end user didn't have to take any actions, and the issue has already been corrected. Tue, May 02, 2017: Disclosed to the public

R7-2017-02: Hyundai Blue Link Potential Info Disclosure (FIXED)

Summary Due to a reliance on cleartext communications and the use of a hard-coded decryption password, two outdated versions of Hyundai Blue Link application software, 3.9.4 and 3.9.5 potentially expose sensitive information about registered users and their vehicles, including application usernames,…

Summary Due to a reliance on cleartext communications and the use of a hard-coded decryption password, two outdated versions of Hyundai Blue Link application software, 3.9.4 and 3.9.5 potentially expose sensitive information about registered users and their vehicles, including application usernames, passwords, and PINs via a log transmission feature. This feature was introduced in version 3.9.4 on December 8, 2016, and removed by Hyundai on March 6, 2017 with the release of version 3.9.6. Affected versions of Hyundai Blue Link mobile application upload application logs to a static IP address over HTTP on port 8080. The log is encrypted using a symmetrical key, "1986l12Ov09e", which is defined in the Blue Link application (specifically, C1951e.java), and cannot be modified by the user. Once decoded, the logs contain personal information, including the user's username, password, PIN, and historical GPS data about the vehicle's location. This information can be used to remotely locate, unlock and start the associated vehicle. This vulnerability was discovered by Will Hatzer and Arjun Kumar, and this advisory was prepared in accordance with Rapid7's disclosure policy. Product Description The Blue Link app is compatible with 2012 and newer Hyundai vehicles. The functionality includes remote start, location services, unlocking and locking associated automobiles, and other features, documented at the vendor's web site. Credit This vulnerability was discovered by independent researchers William Hatzer and Arjun Kumar. Exploitation for R7-2017-02 The potential data exposure can be exploited one user at a time via passive listening on insecure WiFi, or by standard man-in-the-middle (MitM) attack methods to trick a user into connecting to a WiFi network controlled by an attacker on the same network as the user. If this is achieved, an attacker would then watch for HTTP traffic directed at an HTTP site at 54.xx.yy.113:8080/LogManager/LogServlet, which includes the encrypted log file with a filename that includes the user's email address. It would be difficult to impossible to conduct this attack at scale, since an attacker would typically need to first subvert physically local networks, or gain a privileged position on the network path from the app user to the vendor's service instance. Vendor Statement Hyundai Motor America (HMA) was made aware of a vulnerability in the Hyundai Blue Link mobile application by researchers at Rapid7. Upon learning of this vulnerability, HMA launched an investigation to validate the research and took immediate steps to further secure the application. HMA is not aware of any customers being impacted by this potential vulnerability. The privacy and security of our customers is of the utmost importance to HMA. HMA continuously seeks to improve its mobile application and system security. As a member of the Automotive Information Sharing Analysis Center (Auto-ISAC), HMA values security information sharing and thanks Rapid7 for its report. Remediation On March 6, 2017, the vendor updated the Hyundai Blue Link app to version 3.9.6, which removes the LogManager log transmission feature. In addition, the TCP service at 54.xx.yy.113:8000 has been disabled. The mandatory update to version 3.9.6 is available in both the standard Android and Apple app stores. Disclosure Timeline Tue, Feb 02, 2017: Details disclosed to Rapid7 by the discoverer. Sun, Feb 19, 2017: Details clarified with the discoverer by Rapid7. Tue, Feb 21, 2017: Rapid7 attempted contact with the vendor. Sun, Feb 26, 2017: Vendor updated to v3.9.5, changing LogManager IP and port. Mon, Mar 02, 2017: Vendor provided a case number, Consumer Affairs Case #10023339 Mon, Mar 06, 2017: Vendor responded, details discussed. Mon, Mar 06, 2017: Version 3.9.6 released to the Google Play store. Wed, Mar 08, 2017: Version 3.9.6 released to the Apple App Store. Wed, Mar 08, 2017: Details disclosed to CERT/CC by Rapid7, VU#152264 assigned. Wed, Apr 12, 2017: Details disclosed to ICS-CERT by Rapid7, ICS-VU-805812 assigned. Fri, Apr 21, 2017: Details validated with ICS-CERT and HMA, CVE-2017-6052 and CVE-2017-6054 assigned. Tue, Apr 25, 2017: Public disclosure of R7-2017-02 by Rapid7. Tue, Apr 25, 2017: ICSA-17-115-03 published by ICS-CERT. Fri, Apr 28, 2017: Redacted the now-disabled IP address for the LogManager IP address.

Rapid7 urges NIST and NTIA to promote coordinated disclosure processes

Rapid7 has long been a champion of coordinated vulnerability disclosure and handling processes as they play a critical role in both strengthening risk management practices and protecting security researchers. We not only use coordinated disclosure processes in our own vulnerability disclosure and receiving activities, but…

Rapid7 has long been a champion of coordinated vulnerability disclosure and handling processes as they play a critical role in both strengthening risk management practices and protecting security researchers. We not only use coordinated disclosure processes in our own vulnerability disclosure and receiving activities, but also advocate for broader adoption in industry and in government policies.Building on this, we recently joined forces with other members of the security community to urge NIST and NTIA (both part of the U.S. Dept. of Commerce) to promote adoption of coordinated vulnerability disclosure processes. In each of these two most recent filings, Rapid7 was joined by a coalition of approximately two dozen (!!) like-minded cybersecurity firms, civil society organizations, and individual researchers.Joint comments to the National Institute of Standards and Technology (NIST) Cybersecurity Framework, available here.Joint comments to the National Telecommunications and Information Administration's (NTIA) "Green Paper" on the Internet of Things, available here.The goal of the comments is for these agencies to incorporate coordinated vulnerability disclosure and handling processes into official policy positions on IoT security (in the case of NTIA) and cybersecurity guidance to other organizations (in the case of NIST). We hope this ultimately translates to broader adoption of these processes by both companies and government agencies.What are "vuln disclosure processes" and why are they important?Okay, first off, I really hope infosec vernacular evolves to come up with a better term than "coordinated vulnerability disclosure and handling processes" because boy that's a mouthful. But it appears to be the generally agreed-upon term.A coordinated vulnerability disclosure and handling process is basically an organization's plan for dealing with security vulnerabilities disclosed from outside the organization. They are formal internal mechanisms for receiving, assessing, and mitigating security vulnerabilities submitted by external sources, such as independent researchers, and communicating the outcome to the vulnerability reporter and affected parties. These processes are easy to establish (relative to many other security measures) and may be tailored for an organizations' unique needs and resources. Coordinated vulnerability disclosure and handling processes are not necessarily "bug bounty programs" and may or may not offer incentives, or a guarantee of protection against liability, to vulnerability reporters.Why are these processes important? The quantity, diversity, and complexity of vulnerabilities will prevent many organizations from detecting all vulnerabilities without independent expertise or manpower. When companies are contacted about vulnerabilities in their products or IT from unsolicited third parties, having a plan in place to get the information to the right people will lead to a quicker resolution. Security researchers disclosing vulnerabilities are also better protected when companies clarify a process for receiving, analyzing, and responding to the disclosures – being prepared helps avoid misunderstandings or fear that can lead to legal threats or conflicts.To catch vulnerabilities they might otherwise overlook, businesses and government agencies are increasingly implementing vulnerability disclosure and handling processes, but widespread adoption is not yet the norm. NIST Framework commentsThe NIST Framework is a voluntary guidance document for organizations for managing cybersecurity risks. The Framework has seen growing adoption and recognition, and is an increasingly important resource that helps shape cybersecurity implementation in the public and private sectors. NIST proposed revisions to the Framework and solicited comments to the revisions. In our joint comments, the coalition urged NIST to expressly incorporate vulnerability disclosure processes into the Framework. The Framework already included "external participation" components and metrics (likely directed at formal cyber threat intel sharing arrangements), but they are unclear and don't explicitly refer to vulnerability disclosure processes. Specifically, our comments recommended that the Framework Core include a new subcategory dedicated to vulnerability disclosure processes, and to build the processes into existing subcategories on risk assessment and third party awareness. Our comments also recommended revising the "external participation" metric of the Framework Tiers to lay out a basic maturity model for vulnerability disclosure processes.NTIA Internet of Things "Green Paper" commentsNTIA issued a “Green Paper” in late 2016 to detail its overall policies with regard to the Internet of Things, and then they solicited feedback and comments on that draft. Although the Dept. of Commerce has demonstrated its support for vulnerability disclosure and handling processes, there was little discussion about this issue in the Green Paper. The Green Paper is important because it will set the general policy agenda and priorities for the Dept. of Commerce on the Internet of Things (IoT).In our joint comments, the coalition urged NTIA to include more comprehensive discussion vulnerability disclosure and handling processes for IoT. This will help clarify and emphasize the role of vulnerability disclosure in the Dept. of Commerce's policies on IoT security going forward.The comments also urged NTIA to commit to actively encouraging IoT vendors to adopt vulnerability disclosure and handling processes. The Green Paper mentioned NTIA's ongoing "multistakeholder process" on vulnerability disclosure guidelines, which Rapid7 participates in, but the Green Paper did not discuss any upcoming plans for promoting adoption of vulnerability disclosure and handling processes. Our comments recommended that NTIA promote adoption among companies and government agencies in IoT-related sectors, as well as work to incorporate the processes into security guidance documents.More comingRapid7 is dedicated to strengthening cybersecurity for organizations, protecting consumers, and empowering the independent security research community to safely disclose vulnerabilities they've discovered. All these goals come together on the issue of coordinated vulnerability disclosure processes. As we increasingly depend on complex and flawed software and systems, we must pave the way for greater community participation in security. Facilitating communication between technology providers and operators and independent researchers is an important step toward greater collaboration aimed at keeping users safe.Rapid7 is thrilled to be working with so many companies, groups, and individuals to advance vulnerability disclosure and handling processes. As government agencies consider how cybersecurity fits into their missions, and how to advise the public and private sectors on what to do to best protect themselves, we expect more opportunities to come.You can learn more about our policy engagement efforts on Rapid7's public policy page.

R7-2016-28: Multiple Eview EV-07S GPS Tracker Vulnerabilities

Seven issues were identified with the Eview EV-07S GPS tracker, which can allow an unauthenticated attacker to identify deployed devices, remotely reset devices, learn GPS location data, and modify GPS data. Those issues are briefly summarized on the table below. These issues were discovered by…

Seven issues were identified with the Eview EV-07S GPS tracker, which can allow an unauthenticated attacker to identify deployed devices, remotely reset devices, learn GPS location data, and modify GPS data. Those issues are briefly summarized on the table below. These issues were discovered by Deral Heiland of Rapid7, Inc., and this advisory was prepared in accordance with Rapid7's disclosure policy. Vulnerability Description R7 ID CVE Exploit Vector Unauthenticated remote factory reset R7-2016-28.1 CVE-2017-5237 Phone number Remote device identification R7-2016-28.2 None (identification) Phone number range Lack of configuration bounds checks R7-2016-28.3 CVE-2017-5238 Phone number Unauthenticated access to user data R7-2016-28.4 None (server-side issue) Web application Authenticated user access to other users' data R7-2016-28.5 None (server-side issue) Web application user account Sensitive information transmitted in cleartext R7-2016-28.6 CVE-2017-5239 Man-in-the-Middle (MitM) Network Web application data poisoning R7-2016-28.7 None (server-side issue) Web application Product Description The EV-07S is a personal GPS tracker device used for personal safety and security, described at the vendor's website as being primarily intended for tracking elderly family members; disabled and patient care; child protection; employee management; and pet and animal tracking. Test devices were acquired from Eview directly, and an example is shown below in Figure 1. R7-2016-28.1: Unauthenticated remote factory reset## Given knowledge of the EV-07S's registered phone number, the EV-07S device can be reset to factory level setting by sending "RESET!" as a command in an SMS message to the device. Only the phone number is required; no password or physical access is required to accomplish this task. After a factory reset, the device can then be reconfigured remotely via SMS messages without need of password. The product manual states this functionality, so it appears to be a fundamental design flaw with regard to secure configuration. Mitigation for R7-2016-28.1 A vendor-supplied patch should prevent the device from allowing unauthenticated factory reset without having physical access to the device. Absent a patch, users should regularly check their device to ensure the configuration has not be deleted or altered. R7-2016-28.2: Remote device identification The EV-07S device, once set up with a password, should not respond to any SMS queries sent to the device's phone number. According to the user manual, no password is needed to send "reboot" and "RESET!" commands to the device. Testing showed, in spite of user manual statement, that the "reboot" command required a password if device is set up for authentication. Further manual fuzzing test via SMS reveled that the command "REBOOT!" will cause the device to respond with the message "Format error!". Due to providing this negative response, a malicious actor could use this command to enumerate all devices by trying all likely phone numbers, commonly known as a war dialing operation, using SMS messages containing the "REBOOT!" command. Mitigation for R7-2016-28.2 A vendor-supplied patch should disable the response from the "REBOOT!" command when password protection is enabled. R7-2016-28.3: Lack of configuration bounds checks Several input configuration fields were discovered to not be performing proper bounds checks on incoming SMS messages. If a device's phone number is known to an attacker, this lack of bounds checking allows the overly long input of one configuration setting to overwrite data of another setting. An example of this is shown in Figure 3, where the "Authorized Number" setting A1 is used to overwrite setting B1: Mitigation for R7-2016-28.3 A vendor-supplied patch should implement bounds checks and input sanitization on all entered configuration data. Absent a vendor-supplied patch, users should be mindful of entering any values of excessive length. In the case with Authorized Number setting anything over 20 characters will overwrite the next setting in line. R7-2016-28.4: Unauthenticated access to user data A malicious actor can gain access to user data including account name, TrackerID and device IMEI id. This is done by posting userId=**5XXXX**&trackerName=&type=allTrackerswith a the target's userID number to the API.  An example of this shown below in Figure 4: Given the small keyspace involved with guessing valid user IDs of 5 digits, it appears trivial to determine all valid user IDs. Mitigation for R7-2016-28.4 A vendor-supplied patch on the vendor web application should prevent unauthenticated access to individual user data. Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device. R7-2016-28.5: Authenticated access to other users' data An authenticated user can gain access to others users configuration and device GPS data if they know or guess a valid userId, device IMEI or TrackerID. The following three examples (Figures 5 through 7) show this level of access from one authenticated account being able to access another account's data. Mitigation for R7-2016-28.5 A vendor-supplied patch should prevent access to other users data. Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device. R7-2016-28.6:  Sensitive information transmitted in cleartext The web application used for realtime tracking web application, hosted at http://www.smart-tracking.com , does not utilize SSL/TLS encryption for HTTP services. Also the EV-07S device passes IMEI and GPS data to this website over the Internet on TCP port 5050 without any encryption. An example of this captured unencrypted data is show below in Figure 8: Mitigation for R7-2016-28.6 A vendor-supplied patch on both the server and the client should enable encrypted transfer of data to website, as well as an update of the website to enable HTTPS service and serve these pages only over HTTPS. Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device. R7-2016-28.7:  Data poisoning An unauthenticated attacker can poison the realtime tracking data by injecting device data similar to the data structure shown above in Figure 8 to the server at www.smart-tracking.com over TCP port 5050. The attacker can do this only if they know a device's IMEI number, but that data is learnable through mechanisms described above. An example of this is shown in Figure 9, where the device's realtime tracking data was poisoned to make the device appear to be Moscow, Russia (it was not). Mitigation for R7-2016-28.7 A vendor-supplied patch should enable authentication before allowing device data to be posted to the site on TCP port 5050. Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device. Disclosure Timeline Mon, Dec 12, 2016: Initial contact made to the vendor. Tue, Dec 20, 2016: Vendor responded and details provided to info@eviewltd.com. Tue, Dec 27, 2016: Disclosure to CERT/CC, VU#375851 assigned. Wed, Mar 08, 2017: CVEs assigned in conjunction with CERT/CC. Mon, Mar 27, 2017: Vulnerability disclosure published.

Apache Struts Vulnerability (CVE-2017-5638) Protection: Scanning with Nexpose

On March 9th, 2017 we highlighted the availability of a vulnerability check in Nexpose for CVE-2017-5638 – see the full blog post describing the Apache Struts vulnerability here. This check would be performed against the root URI of any HTTP/S endpoints discovered during a…

On March 9th, 2017 we highlighted the availability of a vulnerability check in Nexpose for CVE-2017-5638 – see the full blog post describing the Apache Struts vulnerability here. This check would be performed against the root URI of any HTTP/S endpoints discovered during a scan.On March 10th, 2017 we added an additional check that would work in conjunction with Nexpose's web spider functionality. This check will be performed against any URIs discovered with the suffix “.action” (the default configuration for Apache Struts apps).It may be necessary to configure your scan template to direct Nexpose to specific paths on web servers if they cannot be discovered during the default spidering process. If your app's URI is not linked to from any of these discovered pages, you will need to configure these paths. Follow the steps below to configure your scan template:Let's say you have 2 Apache Struts apps in the following locations:Example App URL 1: http://example.com/org/apps/myapp.actionExample App URL 2: http://example.com/other/org/different.actionIn Nexpose's web UI, select the scan template that you wish to use (Administration → Templates → manage)Go to the Web Spidering section of the template (WEB SPIDERING → PATHS) and then add all the paths you wish Nexpose to try accessing to the “Bootstrap paths” section. PLEASE NOTE: Each path must be followed by a trailing slash and are comma separated (e.g. /org/apps/,/other/org/):Once you configured the paths, save the changes to the template.Not a Nexpose customer and want to scan your network for the Apache Struts vulnerability? Download a free trial of Nexpose here.

R7-2017-01: Multiple Vulnerabilities in Double Robotics Telepresence Robot

This post describes three vulnerabilities in the Double Robotics Telepresence Robot ecosystem related to improper authentication, session fixation, and weak Bluetooth pairing. We would like to thank Double Robotics for their prompt acknowledgement of the vulnerabilities, and in addressing the ones that they considered serious.…

This post describes three vulnerabilities in the Double Robotics Telepresence Robot ecosystem related to improper authentication, session fixation, and weak Bluetooth pairing. We would like to thank Double Robotics for their prompt acknowledgement of the vulnerabilities, and in addressing the ones that they considered serious. Two of the three vulnerabilities were patched via updates to Double Robotics servers on Mon, Jan 16, 2017.CreditThese issues were discovered by Rapid7 researcher Deral Heiland. They were reported to Double Robotics and CERT/CC in accordance with Rapid7's disclosure policy.Product AffectedThe Double Telepresence Robot is a mobile conferencing device. Its mobility allows the remote user to roam around an office for meetings and face-to-face conversations.Vendor StatementFrom Double Robotics' co-founder and CEO, David Cann:At Double Robotics, we seek to provide the best experience possible for our customers, which means not only providing an agile, innovative technology, but also, the highest level of safety and security. Rapid7's thorough penetration tests ensure all of our products run as securely as possible, so we can continue delivering the best experience in telepresence. Before the patches were implemented, no calls were compromised and no sensitive customer data was exposed. In addition, Double uses end-to-end encryption with WebRTC for low latency, secure video calls.Summary of VulnerabilitiesR7-2017-01.1: Unauthenticated access to dataAn unauthenticated user could gain access to Double 2 device information including: device serial numbers, current and historical driver and robot session information, device installation\_keys, and GPS coordinates.R7-2017-01.2: Static user session managementThe access token (also referred to as the driver \_token) which is created during account assignment to a Robot was never changed or expired. If this token was compromised, it could be used to take control of a robot without a user account or password.R7-2017-01.3: Weak Bluetooth pairingThe pairing process between the mobile application (iPad) and robot drive unit does not require the user to know the challenge PIN. Once paired with the robot drive unit, a malicious actor can download the Double Robot mobile application from the Internet and use it (along with the web services) to take control of the drive unit.Vulnerability Details and MitigationsR7-2017-01.1: Unauthenticated access to dataIn the following example, critical information related to a session was accessed using the URL “https://api.doublerobotics.com/api/v1/session/?limit=1&offset=xxxxxxx&format=jso n” By incrementing the "offset=" number, information for all historical and current sessions could be enumerated:In the next example, robot and user installation keys were enumerated by incrementing the "offset=" number in the URL https://api.doublerobotics.com/api/v1/installation/?limit=1&offset=xxxxxxx&forma t=json as shown below:On Mon, Jan 16, 2017, Double deployed a server patch to mitigate this issue.R7-2017-01.2: Static user session managementAlthough the driver\_token is a complex, unique, 40-character token (and so unlikely to be guessed), it can still be enumerated by anyone who has access to the Double Robot iPad or is successful in creating an SSL man-in-the-middle attack against the device. For example, via a successful man-in-the middle attack or access to the robot iPad's cache.db file, a malicious actor could identify the robot\_key as shown below:Using this robot\_key, an unauthenticated user could enumerate all of the user access tokens (driver_tokens) which allow remote control access of the robot. An example of this enumeration method is shown below:On Mon, Jan 16, 2017, Double Robotics deployed a server patch to mitigate this issue. The API queries described above no longer expose related session tokens to the Double device.R7-2017-01.3: Weak Bluetooth pairingThe exposure of this vulnerability is limited since the unit can only be paired with one control application at a time. In addition, the malicious actor must be close enough to establish a Bluetooth connection. This distance can be significant (up to 1 mile) with the addition of a high-gain antenna.On Mon, Jan 16, 2017, Double Robotics indicated it did not see this as a significant security vulnerability, and that it does not currently plan to patch. Users should ensure that the driver assembly remains paired to the control iPad to avoid exposure. Disclosure TimelineThis vulnerability advisory was prepared in accordance with Rapid7's disclosure policy.Dec 2016: Discovered by Rapid7's Deral HeilandMon, Jan 09, 2017: Disclosed to Double RoboticsMon, Jan 09, 2017: Double Robotics acknowledged the vulnerabilitiesMon, Jan 16, 2017: R7-2017-01.1 and R7-2017-01.2 were fixed by Double Robotics via server patchesTue, Jan 24, 2017: Disclosed to CERT/CCWed, Jan 25, 2017: Rapid7 and CERT/CC decided to not issue CVEs for these vulnerabilities. R7-2017-01.01 and 01.02 were present in Double's web application server. As there was only one instance of the affected software, and no user action was required to apply the fixes, no CVE is warranted. R7-2017-01.03 is a exposure for users to be aware of, but it only allows control of the drive unit if pairing is successful. User data cannot be modified without additional compromise.Sun, Mar 12, 2017: Disclosed to the public

Protecting Your Web Apps with AppSpider Defend Until They Can Be Patched

AppSpider scans can detect exploitable vulnerabilities in your applications, but once these vulnerabilities are detected how long does it take your development teams to create code fixes for them?  In some cases it could take several days to weeks before a fix/patch to…

AppSpider scans can detect exploitable vulnerabilities in your applications, but once these vulnerabilities are detected how long does it take your development teams to create code fixes for them?  In some cases it could take several days to weeks before a fix/patch to resolve the vulnerability can be deployed, and during this time someone could be actively exploiting this issue in your application.  AppSpider Defend, which is now integrated into AppSpider Pro, helps to protect your applications until a fix for the identified vulnerabilities are deployed.Defend allows you to easily create custom defenses for Web Application Firewalls(WAFs), Intrusion Protection Systems(IPS), or Intrusion Detection Systems(IDS), based on the results of vulnerability scans conducted with AppSpider .Using innovative automated rule generation, Defend, part of AppSpider Pro, helps security professionals to patch web application vulnerabilities with custom rules in a matter of minutes, instead of the days or weeks it can take by hand. Without the need to build a custom rule for a WAF or IPS or the need to deliver a source code patch, Defend allows developers the time to identify the root cause of the problem and fix it in the code. When you are ready to generate Defend rules, simply:Click on the Load Findings icon.Select the vulnerability summary XML file from a completed AppSpider scan.Determine which of the discovered vulnerabilities you would like to generate Defend rules for.Select the WAF/IDS/IPS that you want to configure with Defend. The current supported WAF/IDS/IPS's are the following:  ModSecurity, SourceFire/Snort, Nitro/Snort, Imperva, Secui/Snort, Akamai, Barracuda, F5, and DenyAll.Then click on the Export Rules icon to generate a Defend rules file which can be uploaded into your WAF/IDS/IPS solution.With these 5 easy steps you can generate a set of Defend rules that, along with your existing WAF/IDS/IPS solution, can help protect against exploits discovered by AppSpider.Once you have loaded the Defend rule set into your WAF/IDS/IPS solution you can verify that the Defend protection has been enabled by clicking the Defend Scan icon which will launch a Defend Quick scan to replay the attacks which AppSpider used to discover the vulnerabilities and confirm that the attacks are no longer successful due to the Defend rules being deployed.For more information on how the Defend functionality works you can review the AppSpider Pro User Guide.

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

Upcoming Event

UNITED 2017

Rapid7's annual security summit is taking place September 12-14, 2017 in Boston, MA. Join industry peers for candid talks, focused trainings, and roundtable discussions that accelerate innovation, reduce risk, and advance your business.

Register 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