Last updated at Tue, 03 Sep 2024 18:49:47 GMT

Today (April 10, 2018) we are sharing six vulnerabilities that have been fixed in Rapid7 products and supporting services. You won’t need to take any actions: all of the issues have been addressed. We are disclosing these vulnerabilities in order to be transparent, to thank those that take the time to report security issues responsibly, and to provide a few reminders of security concerns that you should audit for in your own organization.

Dynamically-generated web server access policies

Generating configuration settings for web servers is a great area for automation, as desired policies and changes to them can be rolled out to large numbers of servers without manual overhead. However, this also means that if a misconfiguration is missed, a large number of assets can be put at risk.

A misconfiguration in the web server access policy for insight.rapid7.com was found that potentially allowed leakage of HTTPS data. The Access-Control-Allow-Origin policy setting made it possible for an attacker in a man-in-the-middle (MITM) position to access resources within the site that required the target user to be authenticated. In specific, HTTP requests for insight.rapid7.com were allowed (via CORS, Cross-Origin Resource Sharing) to access HTTPS resources within the domain. This issue is an instance of Improper Access Control (CWE-284), with an overall CVSS v3 score of 6.3.

This vulnerability does have some non-trivial requirements to exploit, including user interaction and having a MITM position. In an example scenario, the attacker would first embed an iframe in a site they thought target users might visit. Once opened, JavaScript in this iframe would make requests as the target user to https://insight.rapid7.com, including for resources and actions that require the user to be authenticated.

Rapid7 has no evidence that this vulnerability was exploited. Session cookie requirements already in place would likely have prevented the above scenario from being successful. The misconfiguration was addressed by changing the generation process for CORS policies to only allow requests coming from HTTPS origins for existing whitelisted domains.

Rapid7 warmly thanks Jens Mueller for reporting this vulnerability responsibly, and for working with us during mitigation. You can find more information on this type of common vulnerability in this post by Jens.

Password resets

When a password reset was requested for AppSpider Enterprise users, the email sent included the newly generated password in plaintext. As email is not a secure communication channel, only secure, and expiring, URLs should be emailed to allow users to reset their password. This issue is an instance of Insufficiently Protected Credentials (CWE-522), with an overall CVSSv3 score of 4.7.

In terms of exploitation, the complexity and risk are high: a malicious actor would have to be able to intercept the email, but would have then been able to log in as that user and perform actions as them.

This issue was addressed in version 3.8.189, deployed in Nov 2017. Reset passwords are no longer emailed in plain text, but instead include a URL with a 24 hour expiry. Note that this patch was deployed to cloud instances of AppSpider Enterprise, so users do not need to take any action to address this issue.

CSRF protection

In Nexpose versions before 6.4.66, endpoints related to Automated Actions administration lacked CSRF protection. If a Nexpose administrator created or modified an Automated Action, a malicious actor in a privileged network position could intercept the request and send a modified version on to the Nexpose server. This was due to inadequate validation of the source of HTTP requests, which made the affected endpoints susceptible to a cross-site request forgery (CSRF) attack.

Rapid7 issued CVE-2017-5264 for this vulnerability. It is an instance of CSRF (CWE-352), with an overall CVSSv3 score of 3.1. The vulnerability was fixed in Nexpose version 6.4.66. Please note: if you are running a version of Nexpose older than 6.4.66, you should upgrade to 6.4.66 or newer if possible.

Rapid7 warmly thanks Shwetabh Vishnoi for reporting this vulnerability responsibly, and for working with us during mitigation.

Testing server exposure

Several internal vulnerable test machines were exposed to the internet. They were intentionally vulnerable in order to test scanning systems during PCI Certification, but unnecessarily exposing them to the internet risked potential compromise and malicious re-use of these servers against third parties.

These systems shouldn’t have been running at this time, but the bigger issue was they shouldn’t have been exposed to the internet regardless. This misconfiguration is an instance of Violation of Secure Design Principles (CWE-657). It has been addressed by tightening access controls, disabling access unless required and going through a VPN when external access is needed.

This issue was reported to Rapid7 via alerts from shadowserver.org about Rapid7-attributed IP addresses running network services exposed to the internet. Rapid7 warmly thanks the ShadowServer Foundation for their proactive and responsible reporting of this vulnerability.

DNS and CloudFront

When using Amazon CloudFront, it is common to configure an alternate domain name within CloudFront in order to serve resources under a more familiar domain. Then a DNS entry (a CNAME record) for the desired domain must be added pointing to CloudFront for requests to be routed properly.

In order to safely decommission a CloudFront distribution, both of these steps must be rolled back: the alternate domain name must be removed in CloudFront and the DNS CNAME entry must be removed, or changed to not point to CloudFront. If only the alternate domain name is removed in CloudFront but the DNS CNAME still points to CloudFront, then any CloudFront user can associate a new CloudFront distribution with the DNS CNAME entry. While the hijacked DNS CNAME will point to a different CloudFront distribution hostname, that hostname will still resolve to a CloudFront IP address (similar to the notion of different virtual hosts entries that are all served from the same IP). Once the request hits CloudFront, it will be routed to the distribution associated with the alternate domain name.

In a recent case, the DNS CNAMEs help.ges.r7ops.com and help-metasploit.ges.r7ops.com pointed to CloudFront, but no CloudFront distribution was associated with those domains at the time. While there were no external references to these domains by Rapid7, the DNS CNAMEs still pointing to CloudFront introduced a phishing risk by leveraging the real or perceived positive reputation of the domains.

To expand on this scenario: a malicious actor can create a new CloudFront distribution and associate it with any domain that is already pointing to CloudFront, unless a CloudFront distribution is associated with the domain at the time. This allows linking to realistic-looking URLs under the attacker’s control. They could also associate an Amazon S3 bucket with their new CloudFront distribution to serve files from these URLs. And that enables adding a SSL/TLS domain validation certificate through, for example, Let’s Encrypt, as the ACME (Automated Certificate Management Environment) protocol used to verify domain ownership only requires being able to serve a file over HTTP under the domain being checked. This would make the malicious URLs potentially appear even more credible.

This vulnerability was addressed by re-associating the alternate domains with a distribution in CloudFront. However, if the reporter had not released the association in CloudFront, and the association had instead been made by an attacker, the only option would have been to remove the DNS CNAMEs.

Rapid7 warmly thanks Fredrik Nordberg Almroth for reporting this vulnerability responsibly, and for working with us during mitigation.

DNS and AWS Elastic Load Balancers

In another variation on this theme, DNS entries pointing to defunct AWS ELB instances introduce a similar risk. However, it doesn’t appear that the vulnerability could be exploited, at least currently.

In the particular case reported, the CNAME record data.userinsight.rapid7.com pointed to an AWS ELB instance that was no longer active and lacked an A record. If a malicious actor could establish an active ELB instance with a URL matching the CNAME target, various attacks would be possible, e.g. credible phishing attempts.

This isn’t possible currently, however, as one cannot customize or otherwise specify a desired URL for AWS ELBs. That may change in the future, and there may also be a small risk of the orphaned ELB being allocated to someone else. Thus, as in the CloudFront case, it is safest to regularly scan DNS entries for disconnects such as this, and remove them to avoid any risk.

This issue was addressed by removing the affected DNS record. Rapid7 warmly thanks Vineet Kumar for reporting this vulnerability responsibly, and for working with us during mitigation.

Summary: Takeaways

  • Use caution in automating the generation and deployment of access policy settings for web servers: careful auditing is needed to prevent initial misconfigurations from silently expanding to other servers and putting additional infrastructure at risk.
    • CORS policies in specific should be set to only allow requests coming from HTTPS origins for existing whitelisted domains.
  • Email is not a secure communication channel. Password reset emails should only use secure, and expiring, URLs to allow users to reset their password.
  • Audit your code for proper validation of the source of HTTP requests: this is an important step to avoid CSRF. The OWASP CSRF cheat sheet has a wealth of information on CSRF audit and defense approaches.
  • Audit existing and new test servers: do they need to be accessible to the internet? If so, put them behind a VPN if at all possible.
    • Discovery can be the bigger hurdle here, i.e. avoiding silos of infrastructure set up with good intentions but without guidance from IT and Security teams. Vulnerability Management systems such as Nexpose can help you find these unknown unknowns.
  • All DNS records, including CNAMEs, that point to CloudFront must either be registered with an active CloudFront distribution or removed. Ensure a process is in place to review and remove such records when services are decommissioned.
    • As of April 4, 2018, Amazon notifies users in the AWS CloudFront console when they remove an alternate domain name from a CloudFront distribution, alerting them to update their DNS entries accordingly (and thus avoid exposure to the hijacking outlined above). This was added not long after a recent research effort wherein over 2,000 domains, including those of major organizations, were hijacked (before being transferred back to Amazon).
    • You can find more information on subdomain takeovers possible through a wide range of service providers in this article.
  • Regularly audit all your existing DNS entries for orphaned records, i.e. those that point to names that do not resolve or that simply point to non-responsive addresses. Those found should be reviewed, in case the disconnect stemmed from an infrastructure issue and the record is still needed, and otherwise removed.