Rapid7 Blog

Vulnerability Disclosure  

BPC SmartVista SQL injection vulnerability (FIXED)

No-Priority, Post-Auth Vulnerabilities

In the course of collecting and disclosing vulnerabilities, I occasionally come across an issue that walks like a vuln, quacks like a vuln, but… it’s not exactly a vuln. As per our usual vulnerability disclosure process, we still report these issues to vendors. The…

In the course of collecting and disclosing vulnerabilities, I occasionally come across an issue that walks like a vuln, quacks like a vuln, but… it’s not exactly a vuln. As per our usual vulnerability disclosure process, we still report these issues to vendors. The behavior observed is nearly always a bug of some sort, but it’s not immediately exploitable, or the “exploit” is merely exercising the expected level of privilege, but in an unexpected context. Post-authentication -- the case where a behavior can only be exercised by an authenticated user -- is a killer for prioritizing bugfixes, and tends to kick otherwise serious vulnerabilities way down the priority ladder. If you work in software development, you’ve probably run into the curious phenonemon that a “low priority” assignment to a bug really means no priority, and the security issues described here are no different. Now, “post-auth” isn’t the only vulnerability quality that devalues a bug, but it is a pretty solid killer. This macOS vulnerability and this Android bug were (correctly) rated as fairly high severity issues despite being post-authentication, but it’s difficult for most post-auth bugs to claw their way out of the no-priority pile at the bottom of the queue. In my (purely) anecdotal experience, these kinds of bugs tend to linger until (a) more than one or two users complain about them, (b) they attract the attention of influential, in-house expertise, or (c) they get refactored away during a top-to-bottom component rewrite. The problem with not addressing bugs that have vague and tenuous security implications is that many of the best penetration testing stories involve chaining together two, five, or ten of these “unexpected behavior” corner cases into a full-blown domain compromise. So, in the spirit of National Cyber Security Awareness Month, I want to offer up some examples of these low-risk, no-priority issues. The goal here is to define some terms and discuss no-priority post-auth vulnerabilities like these, and hopefully start a conversation around how we in the industry prioritize them. After all, you might have one or two like this lurking in your WontFix backlog, so you might find real examples out in the world illuminating. Authenticated User Enumeration: Tableau Server (R7-2017-09) While on a penetration testing engagement, Rapid7 consultant and researcher Robert Stewart managed to gain access to an on-site instance of Tableau Server, and found that any authenticated user can collect the usernames of all the users on the system. The twist here is that there is no such functionality in Tableau Server; normally, only administrators can list all local users, regular users shouldn’t have this power. Robby was able to sidestep this restriction by creating a specially crafted POST request with a with a null or blank value for the username field of a different API call, as seen in the Burp Suite screenshot below: So, while we appear to have a privilege escalation on our hands here, it turns out, usernames aren’t actually secret. Yes, the direct access to a list of users on a given site is restricted to administrators, but in reality, normal users can of course see other people’s usernames -- it’s required functionality in order to do things like autocomplete, or view other people’s workbooks, and all sorts of other normal functions of the application. Given this, it’s certainly possible to use web scraping techniques to just cycle through all the content on a given Tableau Server site and nab all the usernames. However, penetration testers, like real criminals, are pretty lazy. Being able to abuse an API call to simplify an otherwise tedious task of collecting usernames certainly makes easier the job of credential bruteforcing. In this case, Tableau Server does support account lockouts by integrating with Active Directory or SAML authentication, but the installation found on site was using a local authentication scheme that lacks account lockout controls. So, once armed with a list of valid users, it was only a matter of time before one of them fell over to bruteforcing. Here, we have a case of not-technically-a-vulnerability -- a categorization that we and Tableau ultimately concluded. Authenticated users can always figure out who the other users are through various creative means. Usernames aren’t secret from other authenticated users on this or nearly any other platform. That said, this API abuse certainly makes things easier for the attacker. Insider Spoofing: Duo login_duo (R7-2017-17) Jon Hart, a researcher here at Rapid7, was monkeying around with our own Duo two-factor authentication installation, and found a bit of weirdness lurking in the Linux agent, login_duo. While Duo recommends using the more robust pam_duo PAM module, sometimes you need to go with login_duo to provide 2FA for SSH connections. As it turns out, login_duo reads data directly from the environment variable, SSH_CONNECTION, which normally is written to by OpenSSH through a socket inspection. However, if a local, already authenticated user can invoke login_duo directly, they can write whatever they want to SSH_CONNECTION. This can lead to either convincing-looking alerts that happen to come from other planets: ...or complete nonsense: The Duo administrator console is similarly fooled with bogus SSH_CONNECTION data, but sadly, does not render emojis: All of this is well and good, but again, what does this get an attacker? First off, the attacker would already need to have pretty great local access to a machine that’s running the Duo 2FA authenticator -- and in that case, unless they’re root, their local username is going to be part of the authenticated message, so it’ll be pretty easy to figure out who’s up to shenanigans. It could be useful to an attacker who has this access to start spamming the Duo admin with fake alert messages in hopes of later getting some unsupervised chances at brueforcing the 2FA scheme, but this kind of an attack is hard to imagine actually happening -- there are better ways to DoS a person with annoying messages. In the end, this is a case of trusting data from a source that’s…well, usually pretty trustworthy, but could be subverted for…reasons not entirely clear yet. As you might expect, we all agreed in the end that it was a pretty funny finding, but ultimately, not a very valuable attack vector. Administrative XSS: Cisco ASA (R7-2017-04) While on site, penetration tester Kirk Hayes managed to snag Administrative credentials on the customer’s Cisco ASA VPN terminator. How exactly that happened is neither here nor there, but he did notice a couple issues once on the box. First, Kirk figured out that usernames could be enumerated by anyone (not just admins) thanks to differences between the authentication failure messages: for users that exist, “Login Failed” messages were generated, while nonexistent users triggered an “Authentication Failed” message. This is an honest and true vulnerability, and Cisco addressed it with an advisory. Huzzah for vendor disclosure. The other issue we reported didn’t get much traction, though. Due to a lack of input sanitization, the configurable WebVPN login form could be host to a persistent XSS boobytrap in the “Username Prompt” field. This would trigger upon any other user’s login attempt, and from there, the user’s browser could be hooked, sessions stolen, all the usual XSS hijinks. However, you need to be an Administrator in order to configure the WebVPN login page, and we agreed with Cisco that an ASA admin has plenty of opportunity to mess around with remote users in various subtle or obvious ways. Once again, we’re left with an input sanitization issue that could only really be exploited by someone who already has a ton of insider privilege. But, it’s also a case where this absolutely came in handy on a live penetration test. Using one high-privilege account on one high value, internet-facing device to collect other people’s credentials is pretty much pentesting bread-and-butter. Third-Party Unsafe Export: Rapid7 Nexpose (NEX-50645) To be sure, Rapid7 has its own share of bugs, since everyone who produces complex software is going to occasionally ship a bug here and there. At any rate, a little while back, independent researcher Raghav Bisht reported an issue against Nexpose, which we started tracking as NEX-50645. By constructing an asset tag in Nexpose as a Microsoft Excel formula, that tag can ultimately get evaluated by Microsoft Excel and executed. This sounds like a sneaky way to use your vulnerability management system against you to deliver some Office malware… except there are some barriers to actually getting malicious code to run. For starters, the permission to create tags is usually only granted to the Global Administrator, or by an administrator to a trusted user. So, not only is this an authenticated attack, but it’s another case of needing enhanced privileges. Next, in order to execute this attack, you’d need to convince your target to export a report from Nexpose as a CSV file. There’s no automated way we could find to get a user to do this, and the process takes a fair bit of typing -- it’s not something that you can easily clickjack them into. Finally, Microsoft Excel will tend to not execute unsafe formulas from documents converted from CSV -- it throws up all kinds of warnings about this when you try, so you need to be pretty determined in order to get owned. That all said, should Nexpose asset tags be interpreted as executable Excel formulas? They’re certainly not designed to act that way, and there’s no expectation here that people use them this way. This is clearly a case of weird behavior that could, under some pretty limited circumstances, conceivably advance an attacker’s goals. (As an aside, Google has already addressed this exact sort of issue as not a bug). While we’re inclined to agree, we do think we can make this kind of injection-and-export issue harder to exploit (rather, harder than it already is) by employing some more strict input sanitization on tag names. Stay tuned for that fix (but in the meantime, don’t worry about it terribly -- if your Global Administrator wants to mess up your Nexpose-using day, they have many easier opportunities to do so). Conclusions Although I’ve been around the vulnerability disclosure circus for a while, I honestly don’t know what the “right” response is to bugs like these. It would be great to commit to fix every security-smelling bug reported, but the realities of time constraints, effort, and money are inevitably going to freeze some of these issues out. So far, we here at Rapid7 have agreed with the vendors on all of these -- they’re not directly exploitable issues, but merely weird things that sometimes help penetration testers (and possibly real threat actors) get down to the business of popping shells. While there’s no easy answer to the question of how to deal with all post-auth vulnerabilities, it is valuable to consider them from a different angle than simply their individual impact. How useful might the data revealed be to an attacker that does happen to have authenticated access? If the vulnerability would allow them to greatly speed up their attack on your products and infrastructure, you may want to reconsider that assigned low-but-really-no priority.

Vulnerabilities Affecting Four Rapid7 Products (FIXED)

Today we are announcing four fixed vulnerabilities in four Rapid7 products, summarized in the table below. These issues are low to medium severity (mostly due to the high exploitation requirements), but we want to make sure that our customers have all the information they need…

Today we are announcing four fixed vulnerabilities in four Rapid7 products, summarized in the table below. These issues are low to medium severity (mostly due to the high exploitation requirements), but we want to make sure that our customers have all the information they need to make informed security decisions. This article includes detailed descriptions of the vulnerabilities, as well as how to ensure they are mitigated in your environment. Some of the updates are automatic, but some may require manual action, so we recommend you review sections about products you have deployed. If you are a Rapid7 customer who has any questions about these issues, please don't hesitate to contact your customer success manager (CSM), our support team, or leave a comment below. Rapid7 ID CVE Product Vulnerability Status R7-2017-24 CVE-2017-5252 Insight Agent for Windows DLL Injection Patched in v1.4.68 R7-2017-22 n/a Metasploit Pro, Express, Community, Ultimate Forced logout via CSRF Patched in v4.14.1-20170828 R7-2017-26 n/a Logentries Server Side Template Injection Patched on Aug 10, 2017 R7-2017-15 CVE-2017-5248 AppSpider Pro Unauthenticated Reports Retrieval Patched in v6.14.077 CVE-2017-5252 || Insight Agent: DLL Injection All versions of the Insight Agent on Windows prior to version 1.4.68, which was released today, were vulnerable to loading malicious libraries placed in the dependency search path. Rapid7 assigned CVE-2017-5252 to this vulnerability, which is classified as CWE-426 (Untrusted Search Path). Exploitation and Impact The Insight Agent searches for local dependencies in several locations. Before v1.4.68, these locations included directories in the system PATH variable. As this variable can include directories unknown to the Agent, an attacker with local admin access could place a (potentially malicious) DLL in a directory in that path, causing the Agent to load that library. This vulnerability has high potential impact, including causing the Agent to run arbitrary code, accessing local Agent data, and changing Agent configuration. However, exploitation requires local administrative access to a Windows machine running Insight Agent, and a successful exploitation impacts the Agent on that individual machine only. Additionally, it should be noted that a malicious administrative user is already able to cause a wide variety of damage, such as exfiltrating data and running arbitrary code. Due to the local access and administrative privilege requirements, this is rated as a medium severity vulnerability (CVSS score 6.3). Credit This vulnerability was discovered by an external party and reported to Rapid7. Am I affected? All versions of Insight Agent on Windows systems up to version 1.4.67 are vulnerable. InsightVM customers can verify that all Insight Agents deployed on Windows systems are patched through the scan coverage for CVE-2017-5252 added to InsightVM today. Remediation Insight Agent on Windows systems will automatically update to the latest available version, so the majority of deployments will not require any user action. If your Agents on Windows are pinned to a particular past version, please reach out to Rapid7 support to discuss moving that pinned version to the current one. Additional action required depending on Windows version If you have Insight Agents deployed on Windows 7, Windows 2008, Windows 2008 R2, Windows Vista, you need to ensure that KB2533623 has been applied. This is automatic for Windows systems more recent than those listed here. KB2533623 allows setting default DLL directories, and is required for Insight Agent v1.4.68 to be able to change the default search path, and thus to patch CVE-2017-5252 on the above systems. If you do not have KB2533623 installed when the v1.4.68 update is received, a warning will be shown and logged, but the Agent will be able to continue running on that system. If you apply KB2533623 thereafter, the v.1.4.68 patch will become effective. If you have Insight Agents deployed to Windows XP and Windows 2003 systems, please consider upgrading to a newer operating system. KB2533623 cannot be applied to these legacy systems, and thus the fix for CVE-2017-5252 in Insight Agent v1.4.68 will not be effective. If an OS upgrade is not feasible, we recommend you audit the access controls on such systems with an aim to minimize the number of users with administrative access. The following newer Windows versions have KB2533623 built in already and users do not need to take further action: Windows 8, Windows 10, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016. Disclosure timeline Aug 2017: Vulnerability discovered Wed, Aug 30, 2017: Vulnerability reported to Rapid7 Wed, Aug 30, 2017: Vulnerability confirmed by Rapid7; CVE-2017-5252 assigned Fri, Oct 06, 2017: Fix deployed in v.1.4.68 update R7-2017-22 || Metasploit: Forced Logout via CSRF Exploitation and Impact Before the 4.14.1-20170828 update, the Metasploit web UI did not protect the web UI logout form with CSRF token validation. This allowed an attacker to log out valid users by getting them to hit https://Metasploit-Server-IP:3790/logout. This attack may have been useful as a denial of service against Metasploit instances, allowing an attacker to prevent normal Metasploit usage. However, the attacker wouldn't be able to tell if their attempt worked, as they would not have direct access to the Metasploit instance. In addition, logging a user out doesn't impact background running tasks, so the impact is limited to availability of the Metasploit instance for the user tricked into clicking the logout link. Due to the required user interaction, exploitation difficulty, and limited impact, this is a low severity vulnerability (CVSS score 3.1). Credit Rapid7 thanks Mishra Dhiraj for reporting this vulnerability to us, and for collaborating in the investigation process. Am I affected? Metasploit Pro, Express, Ultimate, and Community deployments running versions before 4.14.1-20170828 are vulnerable. Metasploit Framework is not affected. Remediation This issue was fixed in the 4.14.1-20170828 update for Metasploit commercial editions. Users should ensure their Metasploit Pro, Express, Ultimate, and Community instances are updated. Disclosure timeline Sun, Aug 13, 2017: Vulnerability reported to Rapid7 Mon, Aug 21, 2017: Vulnerability confirmed by Rapid7 Wed, Aug 30, 2017: Fix made available in 4.14.1-20170828 R7-2017-26 || Logentries: Server Side Template Injection Exploitation and Impact By injecting an Angular.js template expression in a logline, it was possible to coerce that expression to be evaluated by the rendered log view in Logentries. This is akin to a stored or persistent cross-site scripting (XSS) issue, but using Angular template expressions rather than Javascript expressions. Prior to the update on July 26, malicious actors could create and insert specially crafted log entries that, when viewed, could subvert the Logentries administrator’s browser session. This is a medium severity vulnerability (CVSS score 4.3), owing largely to the fact that user interaction is required (the act of viewing a log), and that the attacker is then limited to compromising the confidentiality of the affected user’s current browser session. Credit Rapid7 thanks Vini Macedo for reporting this vulnerability to us, and for collaborating in the investigation process. Am I affected? Users of Logentries prior to July 26, 2017 were potentially exposed to this issue. Remediation Since the fix is localized entirely in the Rapid7-hosted Logentries log view, all customers were effectively patched simultaneously on July 26, 2017. Disclosure timeline Mon, Jul 24, 2017: Reported to Rapid7 by Vini Macedo Mon, Jul 24, 2017: Vulnerability confirmed by Rapid7 Tue, Jul 26, 2017: Fix deployed CVE-2017-5248 || AppSpider Pro: Unauthenticated Reports Retrieval Exploitation and Impact Before v6.14.077, the results from an AppSpider Pro scan was accessible for a brief period at a guessable location. This was due to a combination of a race condition and a lack of sufficient controls on temporary files. For approximately 30 seconds, the generated report from a completed scan was available at a URL generated with the UTC timestamp (with one minute fidelity) of the start of the report. An attacker could rapidly bruteforce all likely locations of this report in a short period of time, and then can download the report. As a result, the attacker could learn confidential information about a site’s vulnerability profile. This is a medium severity vulnerability (CVSS score 4.8), since the user interaction requirement (to kick off a scan) requires that the attacker use bruteforce guessing with every exploit attempt, while the ultimate impact of successful exploitation is a loss of confidentiality of a single affected report. Credit Rapid7 thanks Tad Whiteknight for reporting this vulnerability to us, and for collaborating in the investigation process. Am I affected? AppSpider Pro installations running versions older than v6.14.077 are potentially vulnerable. However, AppSpider Pro is typically hosted on private, local networks, and should not be exposed directly to the internet; therefore, attackers must also be able to associate to the same network in order to execute this attack. Furthermore, an unauthenticated attacker has no mechanism to launch an AppSpider Pro scan, and must wait until an authorized user does so. Remediation Users of AppSpider Pro must update to v6.14.077 or later to resolve this issue. Disclosure timeline Wed, May 24, 2017: Vulnerability reported by Tad Whiteknight Thu, Aug 03, 2017: CVE-2017-5248 reserved Mon, Aug 14, 2017: Fix released in v6.14.077

Multiple vulnerabilities in Wink and Insteon smart home systems

Today we are announcing four issues affecting two popular home automation solutions: Wink's Hub 2 and Insteon's Hub. Neither vendor stored sensitive credentials securely on their associated Android apps. In addition, the Wink cloud-based management API does not properly expire and revoke authentication tokens, and…

Today we are announcing four issues affecting two popular home automation solutions: Wink's Hub 2 and Insteon's Hub. Neither vendor stored sensitive credentials securely on their associated Android apps. In addition, the Wink cloud-based management API does not properly expire and revoke authentication tokens, and the Insteon Hub uses an unencrypted radio transmission protocol for potentially sensitive security controls such as garage door locks. As most of these issues have not yet been addressed by the vendors, users should ensure mobile devices enable full disk encryption if possible, and avoid the use of these products for sensitive applications until the vulnerabilities are patched. While the potential impact is high, these vulnerabilities are not exploitable over the internet: access to the user's phone, or close proximity to connected devices in the replay case, is required for exploitation. This post provides additional details on the vulnerabilities and steps users can take to protect themselves. Rapid7 ID CVE Product Vulnerability Status R7-2017-19.1 CVE-2017-5249 Wink Android App Insecure Storage of Sensitive Information Patched in v6.3.0.28 R7-2017-19.2 n/a Wink API Insufficient Session Expiration Unpatched; fix planned R7-2017-20.1 CVE-2017-5250 Insteon Hub Insecure Storage of Sensitive Information Unpatched R7-2017-20.2 CVE-2017-5251 Insteon Hub Authentication Bypass by Capture-replay Unpatched Wink: Android app authentication token storage and API authentication token revocation vulnerabilities Two issues related to authentication were discovered in the Wink Android mobile application and related API: CVE-2017-5249, R7-2017-19.1, CWE 922 (Insecure Storage of Sensitive Information): the OAuth token used by the Wink Android application to authorize user access was not stored in an encrypted and secure way. R7-2017-19.2, CWE 613 (Insufficient Session Expiration): when users log out of the Wink Android application, the authentication token used for that session is not revoked, nor does the generation of new tokens revoke older ones. There is no way currently for users to see all valid authentication tokens connected to their account, but there is a method available to revoke all authentications aside from their current one (detailed below). No CVE was assigned to this issue, as remediation would likely be done on Wink's servers. Product Description Wink Hub 2 is a smart home system designed to help consumers manage multiple home IoT products and protocols from various vendors. It is composed of a hub device as well as a mobile application for user interaction. More information can be found on the vendor's product page. Credit These issues were discovered by Deral Heiland, Research Lead at Rapid7, Inc. This advisory was prepared in accordance with Rapid7's disclosure policy. R7-2017-19.1 Details and Exploitation During analysis of the Android mobile application for Wink (Wink application version 6.1.0.19 on Android 5.1 running kernel 3.10.72), it was discovered that the OAuth token is stored unencrypted within the following file: /data/data/com.quirky.android.wink.wink/shared_prefs/user.xml To determine the longevity of this preference file, the Android device was rebooted, after which the unencrypted OAuth token shown in Figure 1 below was still present. It was determined that the token remained until the user logged off manually. Based on the nature of IoT technology, users typically stay logged in, however. Thus the authentication tokens are likely to stay valid indefinitely, unless the user doesn't interact with the application for more than 30 days. Remediation A vendor-supplied patch for the mobile app should be provided to prevent storing potentially sensitive information, such as authentication tokens, in cleartext. While local storage is likely necessary for normal functionality, sensitive information should be stored in an encrypted format that requires authentication to decrypt. In the case of Android, there is a built-in secure storage method that should be used. [Updated Sept 22, 2017] The latest version of the Wink Android application, v6.3.0.28, fixed the authentication storage issue. This was released on Sep 13, 2017. Users should update to this version immediately. Users should also consider enabling full-disk encryption (FDE), and be sure to log out of the Wink application when not in use. Enabling FDE will protect the authentication tokens on the device from being accessed. iPhones enable FDE by default, and most modern Android devices are capable of enabling it. FDE also adds an additional layer of protection by adding a boot password. If FDE is not possible for a particular device, the user should be especially careful not to lose the device, as sensitive data may be recoverable. R7-2017-19.2 Details and Exploitation Further examination of the Wink app's use of OAuth revealed that the normal user logout process does not include OAuth token revocation. When the user logs out from the mobile application, it only sends a delete request for the mobile device tracker in specific (as shown in Figure 2 below). This tracker plays no direct roll in the authentication process. When the user logs back in, they are assigned a new OAuth token. However, testing showed that the previous OAuth token still remained valid. To further validate the security of this, the user's password was changed, at which point revocation of that user's tokens was expected. The system rebooted, but the original OAuth token still remained valid, as shown in Figure 3: This means that if a user loses their mobile device, or if it is stolen, a malicious actor could extract the unencrypted OAuth token from the user.xml file, giving the malicious actor full access to the Wink Hub 2 remotely. Remediation A vendor-supplied patch should be provided to revoke the user's OAuth token after logout from the mobile application. In addition, a mechanism should be added to allow for the revocation of all tokens across all mobile devices with access to the user's Wink Hub 2. This would help prevent unauthorized access to the device and services even if a device is lost or compromised. [Updated Sept 22, 2017] Wink reports that they plan to address this issue in the near future through a server-side change. [Updated Sept 26, 2017] Users are currently able to force a log out of other user sessions. This can only be done by going to change your password, and then selecting the "Log Out Others" option presented in figure 4: This step will invalidate all associated OAuth tokens, except for the one currently in use by the user. This lowers exposure greatly, as it is much less likely for an attacker to have that current token, rather than an older one. We recommend users change their password and log out other sessions associated with their account to avoid exposure. If users are able to view sessions associated with their account in the future, they should review that regularly. R7-2017-19 Disclosure Timeline Wed, Jul 19, 2017: Initial contact with Wink Wed, Jul 20, 2017: Wink acknowledged receipt Fri, Jul 28, 2017: Details disclosed to Wink Mon, Jul 31, 2017: Wink acknowledged Android token issue, plans to fix Mon, Aug 14, 2017: Rapid7 reserved CVE-2017-5249 for R7-2017-19.1 Mon, Aug 14, 2017: Disclosed to CERT/CC Fri, Sep 22, 2017: Public blog disclosure; presented at DerbyCon 7.0 Fri, Sep 22, 2017: Wink confirmed that R7-2017-19.1 was fixed on Sep 13, 2017, and that they intend to fix R7-2017-19.2 in the near future. Insteon Hub: Unencrypted credential storage and radio replay vulnerabilities Two issues related to authentication and radio transmission security were discovered in the Insteon Hub: CVE-2017-5250, R7-2017-20.1, CWE 922 (Insecure Storage of Sensitive Information): the OAuth token used by the Insteon Android application to authorize user access is not stored in an encrypted and secure way. CVE-2017-5251, R7-2017-20.2, CWE 294 (Authentication Bypass by Capture-replay): the radio transmissions used for communication between the Hub and connected devices are not encrypted, and do not provide sufficient protections to guard against capture-replay attacks. These issues can be used to compromise and control an Insteon Hub environment. Product Description The Insteon Hub is a smart home system designed to help consumers connect various home IoT products and manage home automation. It is composed of a hub device as well as a mobile application for user interaction. More information can be found on the vendor's product page. Credit These issues were discovered by Deral Heiland, Research Lead at Rapid7, Inc. This advisory was prepared in accordance with Rapid7's disclosure policy. R7-2017-20.1 Details and Exploitation Analysis of the Android mobile application for Insteon Hub (Insteon application version 1.9.7) revealed that the account and password for both Insteon services and the Hub hardware was stored unencrypted within the following file: /data/data/com.insteon.insteon3/shared_prefs/com.insteon.insteon3_preferences.xml To determine the longevity of this file, the Android device was rebooted, after which the plaintext username and password shown in Figures 1 and 2 below was still present. It was determined that the account credentials remained in the file until the user logged off manually. Based on the nature of IoT technology, users typically stay logged in. Remediation A vendor-supplied patch should be made to the mobile app to prevent storing sensitive information, such as user credentials, unencrypted. While local storage is likely necessary for normal functionality, sensitive information should be stored in an encrypted format that requires authentication to decrypt. In the case of Android, there is a built-in secure storage method that should be used. Absent a vendor-supplied patch, users should consider full-disk encryption (FDE), and be sure to log out of the Insteon Hub application when not in use. Enabling FDE will protect the authentication tokens on the device from being accessed. iPhones enable FDE by default, and most modern Android devices are capable of enabling it. FDE also adds an additional layer of protection by adding a boot password. If FDE is not possible for a particular device, the user should be especially careful not to lose the device, as sensitive data may be recoverable. R7-2017-20.2 Details and Exploitation The Insteon Hub uses radio signals to communicate with connected devices, specifically a 915MHz Frequency Shift Keying (FSK) communication protocol. Analysis of this protocol revealed that the transmissions do not appear to be encrypted, nor to contain any security mechanisms to prevent replay attacks. A malicious actor can easily capture and replay the radio signals at any time to manipulate any device being managed via this communication protocol. To test the Insteon Hub's security against replay attacks, an Insteon Garage Door Control Kit (Device 43) was configured via an Insteon Hub (2245-222). Using software-defined radio (SDR), the 915MHz radio signal used to open and close the door via the Garage Door Control device was captured. Once captured, the signal was filtered to remove background noise and then replayed to successfully actuate the Insteon Garage Door Control device. This confirmed that the Insteon RF protocol is vulnerable to replay attacks, and is shown in Figure 3 below: Remediation A vendor-supplied patch should be provided to configure the 915MHz signal to encrypt the data being communicated, or to apply a rotating certificate to prevent replay of captured RF signals. Absent a vendor-supplied patch, users should avoid using the Insteon's radio-control features with security-related and access control devices if they are concerned about potential radio eavesdroppers. R7-2017-20 Disclosure Timeline Wed, Jul 19, 2017: Initial contact with Insteon Wed, Jul 20, 2017: Insteon acknowledged receipt Fri, Jul 28, 2017: Details disclosed to Insteon Mon, Jul 31, 2017: Insteon acknowledged receipt, intent to review Mon, Aug 14, 2017: Rapid7 reserved CVE-2017-5250 for .1 and CVE-2017-5251 for .2 Mon, Aug 14, 2017: Disclosed to CERT/CC Fri, Sep 22, 2017: Public blog disclosure; presented at DerbyCon 7.0

Cisco Smart Install Exposure

Cisco Smart Install (SMI) provides configuration and image management capabilities for Cisco switches. Cisco’s SMI documentation goes into more detail than we’ll be touching on in this post, but the short version is that SMI leverages a combination of DHCP, TFTP and a…

Cisco Smart Install (SMI) provides configuration and image management capabilities for Cisco switches. Cisco’s SMI documentation goes into more detail than we’ll be touching on in this post, but the short version is that SMI leverages a combination of DHCP, TFTP and a proprietary TCP protocol to allow organizations to deploy and manage Cisco switches. Using SMI yields a number of benefits, chief among which is the fact that you can place an unconfigured Cisco switch into an SMI-enabled (and previously configured) network and it will get the correct image and configuration without needing to do much more than wiring up the device and turning it on. Simple “plug and play” for adding new Cisco switches. But, with the great power and heightened privileges comes great responsibility, and that remains true with SMI. Since its first debut in 2010, SMI has had a handful of vulnerabilities published, including one that led to remote code execution (CVE-2011-3271) and several denial of service issues (CVE-2012-0385, CVE-2013-1146, CVE-2016-1349, CVE-2016-6385). Things got more interesting for SMI within the last year when Tenable Network Security, Daniel Turner of Trustwave SpiderLabs, and Alexander Evstigneev and Dmitry Kuznetsov of Digital Security disclosed a number of security issues in SMI during their presentation at the 2016 Zeronights security conference. Five issues were reported, the most severe of which easily rated as CVSS 10.0, if risk scoring is your thing. Or, put more bluntly, if you leave SMI exposed and unpatched and have not followed Cisco’s recommendations for securing SMI, effectively everything about that switch is at risk for compromise. Things get even more gnarly quickly when you consider what a successful attack against a Cisco switch exposing SMI would get an attacker. Even an otherwise well-protected network could be compromised if a malicious actor could arbitrarily reroute a target’s traffic at will. In direct response to last year’s research, Cisco issued a security response hoping to put the issue of SMI security to bed once and for all. They effectively claim that these issues are not vulnerabilities, but rather “misuse of the protocol”, even while encouraging customers to disable SMI if it was not in use. True, this largely boils down to a lack of authentication both in some of the underlying protocols (DHCP and TFTP) as well as SMI itself, which is a key part of achieving the aforementioned installation/deployment simplicities. However, every SMI-related security advisory published by Cisco has included recommendations to disable SMI unless needed. Most recently, they’ve provided various coverage for SMI abuse across their product lines, updated the relevant documentation that details how to properly secure SMI, and released a scanning tool for customers to use to determine if their networks are affected by these SMI issues. To further help Cisco customers secure their switching infrastructure, they’ve also made available several SMI related hardening fixes: CSCvd36820 automatically disables SMI if not used during bootup CSCvd36799 if SMI is enabled it must show in the running config CSCvd36810 periodically alerts to the console if SMI is enabled Ultimately, whether we call this protocol a vulnerability or a feature, exposed SMI endpoints present a very ripe target to attackers. And this is where things get even more interesting. Given that up until recently there was no Cisco provided documentation on how to secure SMI and no known tools for auditing SMI, it was entirely possible that scores of Cisco switches were exposing SMI in networks they shouldn’t be without the knowledge of the network administrators tasked with managing them. Sure enough, a preliminary scan of the public IPv4 Internet by these same original SMI researchers showed 251,801 systems exposing SMI and seemingly vulnerable to some or all of the issues they disclosed. The Smart Install Exploit Tool (SIET) was released to help identify and interact with exposed SMI endpoints, which includes exploit code for a variety of the issues they disclosed. As part of Cisco’s response to this research, they indicated that the SIET tool was suspected in active attacks against organizations’ networks. A quick look through Rapid7 Labs’ Project Heisenberg for 2017 shows only minimal background network noise on the SMI port and no obvious large-scale scanning efforts, though this does not rule out the possibility of targeted attacks. As with many situations like this in security, it's like a case of “if you build it, they will come” gone wrong, almost a “if you design it, they’ll misuse it.” There are any number of ways a human or a machine could mistakenly deploy or forget to secure SMI. Until recently, SMI had little mention in documentation, and, as evidenced by the three SMI related hardening fixes, it was difficult for customers to identify that they were even using SMI in the first place. Plus, even in the presence of a timely patching program, any organization exposing SMI to hostile networks but failing to do their security due diligence are easy targets for deep compromise. To top it all off, by following the recommended means of securing SMI when it is actually being used for deployment, you must add specific ACLs to control who can speak to SMI enabled devices, thereby severely crippling the ease of use that SMI was supposed to provide in the first place. With all of this in mind, we decided to reassess the public Internet for exposure of SMI with several questions in mind: Have things changed since the publication of the SMI research in 2016 and the resulting official vendor response in 2017? Are there additional clues that could explain why SMI is being exposed insecurely? Can Rapid7 assist? The methodology we used to assess public Internet for SMI exposure is almost identical to what the Zeronights researchers used in 2016, except that after the first-pass zmap scan to locate supposedly open SMI 4786/TCP endpoints, we utilized the logic demonstrated in Cisco’s smi_check to determine if the endpoint actually spoke the SMI protocol. Our study found ~3.2 million open 4786/TCP endpoints, the vast majority of which are oddly deployed SSH, HTTP and other services, as well as security devices. It is worth noting that while the testing methodologies between these two scans appear nearly identical, both are relying on possibly limited public knowledge about the proprietary SMI protocol. Future research may yield additional methods of identifying SMI. Using the same logic as in smi_check, we identified 219,123 endpoints speaking SMI in July and 215,317 endpoints in a subsequent scan in August 2017. Answering our first question, we see there was a ~13% drop in the number of exposed SMI endpoints between the Zeronights researcher’s original study and Rapid7 Labs’ Sonar scan in July of 2017, but it is hard to say what the cause was. For one, the composition of the Internet has changed in the last year. Two, Sonar maintains a blacklist of addresses whose owners have requested that we cease scanning their IPs and it is unknown if the Zeronights researchers had a similar list, which means that there were likely a few fundamental differences in the target space between these two disparate scans. So, despite a history of security problems and Cisco advising administrators to properly secure SMI, a year later things haven’t really changed. Why? Examining SMI exposing IPs by country, as usual it is no surprise that countries with a large number IPv4 IPs and significant network infrastructure are at the top of those exposed: Repeating this visualization but examining the organizations that own the IPs exposing SMI, a possible pattern appears -- ISPs: Unfortunately this is where things get a little complicated. The data above seems to imply that the bulk of the organizations exposing SMI are ISPs or similar, however that is also an artifact of how the attribution process happens here. In cases where a given organization is its own ASN and they expose SMI, our reporting would attribute any of the IPs that that ASN is responsible for to the organization in question. However, in cases where a given organization is not its own ASN, or if it uses IP space that it doesn’t control, for example it just gets a cable/DSL/etc router from their ISP, then the name of that organization will not be reflected in our data. Proprietary protocols are interesting from a security perspective and SMI is no exception. Being specific to Cisco switches, you’ll only find this in Cisco shops that didn’t properly secure the switch prior to deployment, so there are limited opportunities for researchers or attackers to explore this. While proprietary protocols are not necessarily closed, SMI does appear that way in that there is almost no public documentation on the protocol particulars beyond what the Zeronights researchers published in 2016. Despite the lack of documentation at the time, these researchers employed a simple method for understanding how the protocol works and it turned out to to be highly effective -- exercising SMI functionality while observing the live protocol communication with a network sniffer. There are several areas for future research which may provide value: When properly secured, including applying all the relevant IOS updates and following Cisco’s recommendations with regards to securing SMI, what risks remain in networks that utilize SMI, if any? When improperly secured, are there are additional risks to be explored? For example, what about the related SMI director service that exposes 4787/TCP? Are there safer or quieter ways to carry out the attacks described by the Zeronights researchers such that more accurate vulnerability coverage could exist? Is there a need for vulnerability coverage similar to SIET’s in Metasploit? What is current state of the art with regards to post-compromise behavior on network switches like this? What methods are (or could) attackers employ to establish advantageous footholds in the networks and devices serviced by a compromised switch? In order to ensure that Rapid7 customers are able to identify assets exposing SMI in their environments, we have added SMI fingerprinting and vulnerability coverage to both Metasploit as of September 1 in auxiliary/scanner/misc/cisco_smart_install, and InsightVM as of the August 17, 2017 release via cisco-sr-20170214-smi. Interested in this research? Looking to collaborate? Questions? Comments? Leave them below or reach out via research@rapid7.com!

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-13 | CVE-2017-5243: Nexpose Hardware Appliance SSH Enabled Obsolete Algorithms

Summary Nexpose physical appliances shipped with an SSH configuration that allowed obsolete algorithms to be used for key exchange and other functions. Because these algorithms are enabled, attacks involving authentication to the hardware appliances are more likely to succeed. We strongly encourage current hardware appliance…

Summary Nexpose physical appliances shipped with an SSH configuration that allowed obsolete algorithms to be used for key exchange and other functions. Because these algorithms are enabled, attacks involving authentication to the hardware appliances are more likely to succeed. We strongly encourage current hardware appliance owners to update their systems to harden their SSH configuration using the steps outlined under “Remediation” below. In addition, Rapid7 is working with the appliance vendor to ensure that future appliances will only allow desired algorithms. This vulnerability is classified as CWE-327 (Use of a Broken or Risky Cryptographic Algorithm). Given that the SSH connection to the physical appliances uses the 'administrator' account, which does have sudo access on the appliance, the CVSS base score for this issue is 8.5. Credit Rapid7 warmly thanks Liam Somerville 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 physical, hardware appliances are affected. Virtual appliances (downloadable virtual machines) are NOT affected. Vulnerability Details Nexpose Physical Appliances The default SSH configuration of the hardware appliance enables potentially problematic algorithms which are considered obsolete. KEX algorithms: diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1, ssh-dss, ecdsa-sha2-nistp256, ssh-ed25519 Encryption algorithms: arcfour256, arcfour128, aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, aes192-cbc, aes256-cbc, arcfour, rijndael-cbc@lysator.liu.se MAC algorithms: hmac-md5-etm@openssh.com, hmac-sha1-etm@openssh.com, umac-64-etm@openssh.com, hmac-ripemd160-etm@openssh.com, hmac-sha1-96-etm@openssh.com, hmac-md5-96-etm@openssh.com, hmac-md5, hmac-sha1, umac-64@openssh.com, hmac-ripemd160, hmac-ripemd160@openssh.com, hmac-sha1-96, hmac-md5-96 These are supported by the version of OpenSSH used on the appliance, and should be disabled via explicit configuration that enables only desired algorithms. Nexpose Virtual Appliances The software appliances (downloadable virtual machines) are NOT affected by this issue. They specify desired algorithms, only allowing those generally recommended. Remediation - Updated 2017/06/02 Before making any updates, first verify that your appliance is running Ubuntu 14.04 or above. You can determine the version by running "lsb_release -r”. If on 14.04, you should see output like “Release: 14.04”. If appliance is running Ubuntu 12.04 or below: OS upgrade required Please reach out to Rapid7 support for more information on upgrading. Ubuntu 12.04 reached End of Life in April 2017, and we strongly encourage you to update to a supported version. DO NOT continue with the changes below if you are not on 14.04 or above, as some of the configuration options will not be supported by older versions of OpenSSH. If appliance is running Ubuntu 14.04 or above The version of OpenSSH on base Ubuntu 14.04 (“OpenSSH_6.6.1p1 Ubuntu-2ubuntu2, OpenSSL 1.0.1f 6 Jan 2014”) will support the configuration changes below. If you updated from 12.04, you may want to update OpenSSH to the latest available version to ensure you have available security patches, but it is not required for this change. You can check you OpenSSH version by running “ssh -V”. The current latest for 14.04 is “OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8” Note on verification and existing connections Do not close the SSH session you use to make the configuration change until you first attempt a new connection and verify you are able to connect. This will enable you to stay connected in the event there is a problem with the edit and you need to revert and review, as active SSH sessions should not be closed even across service restarts. If you skip this step, you may lose the ability to connect over SSH, potentially meaning you need physical access or other means to fix the issue. Configuration change Administrators need to edit the /etc/ssh/sshd_config file on their Nexpose appliance. Before changing the configuration file, copy it (e.g. "sudo cp /etc/ssh/sshd_config /home/administrator") in case there is a problem during editing. Add the following lines (based on the guidelines available here) to the end of the file: # Enable only modern ciphers, key exchange, and MAC algorithms # https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Modern_.28OpenSSH_6.7.2B.29 KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com Please be careful to copy the entirety of the lines above, which may scroll horizontally in your browser. You can also copy from this gist. Depending on the version of SSH you have installed, there may be other configuration lines in that file for "KexAlgorithms", "Ciphers", and "MACs". If that is the case, remove or comment (add a"#" to the beginning of the line) those lines so that the desired configuration you add is sure to be respected. Editing this file will require root access, so the appliance default "administrator" user, or another user with permission to sudo, will need to perform this step. After updating the configuration file, verify that the changes made match the configuration above. This is important, as missing part of the configuration may result in a syntax error on service restart, and a loss of connectivity. You can run this command and compare the three output lines with the configuration block above: egrep "KexAlgorithms|Ciphers|MACs" /etc/ssh/sshd_config After verifying the configuration change, restart the SSH service by running "service ssh restart". Once that completes, verify you can still connect via ssh client to the appliance in a separate terminal. Do not close the original terminal until you've successfully connected with a second terminal. This change should not impact connections from Nexpose instances to the physical appliance (SSH is not used for this communication). The main impact is shoring up access by SSH clients such that they cannot connect to the appliance using obsolete algorithms. We apologize for any inconvenience, and would like to warmly thank the customers that worked with us to test and troubleshoot these remediations. Disclosure Timeline Wed, May 10, 2017: Vulnerability reported to Rapid7 Wed, May 17, 2017: Vulnerability confirmed by Rapid7 Tue, May 23, 2017: Rapid7 assigned CVE-2017-5243 for this issue Wed, May 31, 2017: Disclosed to MITRE Wed, May 31, 2017: Public disclosure

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

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