Rapid7 Blog

Sam Huckins  

AUTHOR STATS:

9

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

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-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-2017-03: Improper Access Control of Fuze Meeting Recordings (FIXED)

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

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

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

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

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

12 Days of HaXmas: Metasploit Framework 2016 Overview

Merry HaXmas to you! Each year we mark the 12 Days of HaXmas with 12 blog posts on hacking-related topics and roundups from the year. This year, we're highlighting some of the “gifts” we want to give back to the community. And while these gifts…

Merry HaXmas to you! Each year we mark the 12 Days of HaXmas with 12 blog posts on hacking-related topics and roundups from the year. This year, we're highlighting some of the “gifts” we want to give back to the community. And while these gifts may not come wrapped with a bow, we hope you enjoy them. Breaking Records and Breaking Business 2016 brought plenty of turmoil, and InfoSec was no exception: Largest data breach: Largest breach ever, affecting more than 1 billion Yahoo users. And they were not alone: Oracle, LinkedIn, the Department of Justice, SnapChat, Verizon, DropBox, the IRS — many organizations experienced, or discovered (or finally revealed the true extent of...), massive breaches this year. Record-breaking denial of service attacks: law enforcement efforts targeting DDoS-as-a-Service providers are encouraging, but Mirai achieved record-breaking DDoS attacks this year. It turns out those easy-to-take-for-granted devices joining the Internet of Things in droves can pack quite a punch. Ransomware: the end of 2015 saw a meteoritic rise in the prevalence of ransomware, and this continued in 2016. Healthcare and other targeted industries have faced 2-4x as many related attacks this year, some via increased coverage of ransomware in exploits kits, but mostly through plain old phishing. Businesses and individuals continue to face new and increasing threats in keeping their essential systems and data secure. A static defense will not suffice: they must increase in both awareness and capability regularly in order to form a robust security program. Metasploit Framework has grown in many ways during 2016, both through the broader community and through Rapid7 support. Let's look back through some of the highlights: More exploits A surprisingly wide range of exploits were added to Metasploit Framework in 2016: Network management: NetGear, OpenNMS, webNMS, Dell, and more Monitoring and backup: Nagios XI, Exagrid Security: ClamAV, TrendMicro, Panda, Hak5 Pineapple, Dell SonicWall, Symantec -- and Metasploit itself! Mainframes, SCADA dashboards Exploit Kits: Dark Comet, Phoenix ExtraBACON; StageFright Content management/web applications: Joomla, TikiWiki, Ruby on Rails, Drupal, Wordpress forms Docker, Linux kernel, SugarCRM, Oracle test suite, Apache Struts, exim, Postgres, and many more! More flexibility Metasploit Framework provides many supporting tools, aside from those designed to get a session on a target. These help in collecting information from a wide variety of systems, staying resilient to unknown and changing network environments, and looking like you belong. Some expansions to the toolbox in 2016 included: Additional persistence options: cron jobs, SSH keys, and boot services Improvements to payload handlers, including a universal handler Android: inject Meterpreter into an existing APK and re-sign Mettle: a new native POSIX Meterpreter PowerShell: run scripts even if PowerShell isn't installed on the target, upload to PowerShell Empire, and more Data collection: Amazon EC2 metadata, OS X Messages, subdomain enumeration, trusted Office locations — even generate an org chart from Active Directory. By the Numbers Nearly 400 people have contributed code to Metasploit Framework during its history. And speaking of history: Metasploit Framework turned 13 this year! Long long ago, in a console (probably not too) far away: Metasploit Framework 2.2 - 30 exploits Has much changed in the last 12 years? Indeed! Metasploit Framework 4.13.8 - 1607 exploits In 2016, Metasploit contributors added over 150 new modules. Metasploit Framework's growth is powered by Rapid7, and especially by the community of users that give back by helping the project in a variety of ways, from landing pull requests to finding flags. Topping the list of code contributors in 2016: Wei Chen (sinn3r), Brent Cook, William Vu (wvu), Dave Maloney (thelightcosine), h00die, OJ Reeves, nixawk, James Lee (egypt), Jon Hart, Tim Wright, Brendan Watters, Adam Cammack, Pedro Ribeiro, Josh Hale (sn0wfa11), and Nate Caroe (TheNaterz). The Metasploit Framework GitHub project is approaching 4700 forks, and ranks in the top 10 for Ruby projects once again. It's also the second most starred security project on GitHub. None of this would have been possible if not for the dedication and drive of the Metasploit community. Together, we can continue to highlight flaws in existing systems, and better test the essential software of tomorrow. John Locke voiced in 1693 what open source security supporters continue to know well today: "The only fence against the world is a thorough knowledge of it." So what about you? New to Metasploit? Check out the wiki for usage info and lots more! Need a refresher? Check out the new module documentation approach, including usage examples Get the latest Metasploit Framework and try it out against Metasploitable3! Hop on the #metasploit channel on IRC to ask questions, or hit us up on Twitter Want to Contribute? Thank you! There are many forms that can take, and whether adding module documentation, fixing a bug, filing a bug, sharing an idea, or putting up a pull request for your first exploit module: these are all valuable!

Working with reports and exports via the RPC API

The Metasploit RPC API provides a straightforward, programmatic way to accomplish basic tasks with your Metasploit Pro instance. Two of the key capabilities are export generation to backup your data and report generation to summarize and share your findings. The RPC API docs are currently…

The Metasploit RPC API provides a straightforward, programmatic way to accomplish basic tasks with your Metasploit Pro instance. Two of the key capabilities are export generation to backup your data and report generation to summarize and share your findings. The RPC API docs are currently undergoing a major overhaul and are a bit out of date for reports and export generation. This post will provide all the examples and configuration options you need to get running. Setting up a client to make the API calls is simple: # This class is defined under pro/api-example require_relative 'metasploit_rpc_client' client = MetasploitRPCClient.new(host:host, token:api_token, ssl:false, port:50505) Note that there are example scripts shipped with Metasploit Pro that show these examples and more. They can be found inside the install directory (on *nix systems /opt/metasploit) under apps/pro/api-example. They are simple wrappers that allow you to pass in required arguments, so good for getting a feel for things. In addition to the API calling code, however you implement that, you need to have the Metasploit Pro instance running and you need to generate an API key. This can be done from Administration -> Global Settings. Reports Listing existing reports report_list displays all reports that have been generated in the workspace you specify: report_list = client.call('pro.report_list', workspace_name) puts "Existing Reports: #{report_list}" Sample output: Existing Reports: {7=>[{"id"=>6, "report_id"=>7, "file_path"=>"/Users/shuckins/rapid7/pro/reports/artifacts/CredentialMetaModule-20140912105153.pdf", "created_at"=>1410537159, "updated_at"=>1410537159, "accessed_at"=>nil, "workspace_id"=>2, "created_by"=>"shuckins", "report_type"=>"mm_auth", "file_size"=>34409}], The keys of the Hash are the report IDs, needed for download as will be seen below. The value Array contains all the artifacts that were generated. An artifact is simply a particular file in a particular format. For example, when you generate an Audit report and select file formats PDF, HTML, and Doc, this results in a single report with three child artifacts. Getting information on available reports to generate type_list = client.call('pro.list_report_types') puts "Allowed Report types: #{type_list}" Sample output (snipped, full output includes every report type): Allowed Report types: {"activity"=>{"required_data"=>"tasks", "file_formats"=>"pdf, html, rtf", "options"=>"include_task_logs", "sections"=>"cover, project_summary, task_details", "report_directory"=>"/Users/shuckins/rapid7/pro/reports/activity/", "parent_template_file"=>"/Users/shuckins/rapid7/pro/reports/activity/main.jrxml"}, Downloading a report (all child artifacts) report_id = 1 # Get this from report_list call report = client.call('pro.report_download', report_id) report['report_artifacts'].each_with_index do |a, i| tmp_path = "/tmp/report_test_#{i}_#{Time.now.to_i}#{File.extname(a['file_path'])}" File.open(tmp_path, 'w') {|c| c.write a['data']} puts "Wrote report artifact #{report_id} to #{tmp_path}" end This will download every artifact related to this report generation (1-4 files depending on format selection). Downloading particular report artifacts If you only want a particular artifact file under a report, you can download that using the artifact ID provided from the report_list call. report_artifact_id = 1 artifact = client.call('pro.report_artifact_download', report_artifact_id) tmp_path = "/tmp/report_#{report_artifact_id}#{File.extname(artifact['file_path'])}" File.open(tmp_path, 'w') {|c| c.write artifact['data']} puts "Wrote report artifact #{report_artifact_id} to #{tmp_path}" Generating a report There are a number of options available for this call, detailed below. This basic version generates a single PDF artifact of the Audit report: report_hash = {workspace: workspace_name, name: "SuperTest_#{Time.now.to_i}", report_type: :audit, created_by: 'whoareyou', file_formats: [:pdf] } report_creation = client.call('pro.start_report', report_hash) puts "Created report: #{report_creation}" There's currently no API call to provide report (or export) generation status. The time required depends entirely on your data size and complexity. One place to check for status is the reports.log file. Configuration options These are placed in the hash passed to the start_report call. Required: name: String, the name for the report shown in the web UI and in the file path; used in forming the filenames of the artifacts generated report_type: String, must be one of those listed by list_report_types, e.g.: activity, audit, credentials, collected_evidence, compromised_hosts, custom, fisma, mm_auth, mm_pnd, mm_segment, pci, services, social_engineering, webapp_assessment report_template: if type custom this can be set, String, full file path to custom Jasper jrxml template. If not a custom report, do not use this. workspace_name: String, name of the workspace to which the report will be scoped created_by: String, username to which the report should be attributed file_formats: Array, the file format(s) of the artifacts to be generated. Must specify at least one. Available types vary slightly per report, 'pdf' is present for all. See list_report_types for formats per type. Optional: email_recipients: String, addresses to which the report artifact(s) should be emailed. Addresses can be separated with comma, semicolon, newlines, or spaces. mask_credentials: Boolean, whether credentials shown in report artifacts should be scrubbed (replaced with MASKED) included_addresses: String, space-separated addresses to include in the report. Can include wildcards, ranges, CIDR. excluded_addresses: String, space-separated addresses to exclude from the report. Can include wildcards, ranges, CIDR. If included and excluded are both specified, they are both expanded and the address set used is included - excluded. logo_path: String, full path to image file to use on cover page of report artifacts. If not specified, the Rapid7 logo is used. Must be of type: gif, png, jpg, or jpeg options: sub hash of additional configuration options: include_sessions: Boolean, whether information on sessions should be included in the report if applicable include_charts: Boolean, whether graphs should be included in the report if applicable include_page_code: Boolean, whether HTML code of pages in SE campaigns should be included in the report versus just an image preview of the rendered page se_campaign_id: Integer, the ID of the SE campaign the report should cover. Only applied to SE report. sections: Array, specific sections of the report to include. If this is specified only the specified sections will be included. If not specified all sections will be included. For section names, see list_report_types. usernames_reported: String, comma-separated list of users to be included as active in the report. This is usually shown in the Executive summary section. Exports Export coverage is nearly identical to reports. Listing existing exports export_list = client.call('pro.export_list', workspace_name) puts "Existing Exports: #{export_list}" Generating an export export_types = ['zip_workspace','xml','replay_scripts','pwdump’] # NOTE: If you are not on the latest update of 4.10 (4.10.0-2014092401) this requires workspace_id with integer value of ID. # If you've updated to this point you can use workspace with a string value of name as below. export_config = {created_by: 'whoareyou', export_type: export_types[1], workspace: 'ThePlace'} export_creation = client.call('pro.start_export', export_config) puts "Created export: #{export_creation}" Downloading a generated export export_id = 1 export = client.call('pro.export_download', export_id) tmp_path = "/tmp/export_test_#{export_id}#{File.extname(export['file_path'])}" File.open(tmp_path, 'w') {|c| c.write export['data']} puts "Wrote export #{export_id} to #{tmp_path}" Configuration options Required: created_by: String, username to which the export should be attributed export_type: String, must be one of: zip_workspace, xml, replay_scripts, pwdump workspace: String, name of the workspace to which export will be scoped Optional: name: String, the name for the export shown in the web UI and in the file path; unacceptable characters are changed to underscores or removed mask_credentials: Boolean, whether credentials shown in XML and other files should be scrubbed (replaced with MASKED) included_addresses: String, space-separated addresses to include in the export. Can include wildcards, ranges, CIDR. excluded_addresses: String, space-separated addresses to exclude from the export. Can include wildcards, ranges, CIDR. If included and excluded are both specified, they are both expanded and the address set used is included – excluded.

Featured Research

National Exposure Index 2017

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

Learn More

Upcoming Event

UNITED 2017

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

Register Now

Podcast

Security Nation

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

Listen Now