Last updated at Fri, 10 May 2019 16:56:33 GMT

Today (October 29, 2018) we are sharing several vulnerabilities that have been fixed in Rapid7 products and supporting services. You won’t need to take any actions (unless you have AppSpider Enterprise and are not yet on Version 3.8.207, released in August 2018), since all of the issues have been addressed. Rapid7 has no evidence that any of these vulnerabilities have been exploited. We are disclosing these vulnerabilities in order to be transparent, to thank those who 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.

CSRF protection

In AppSpider Enterprise before Version 3.8.197, a CSRF token was not set when a user logged out. A malicious actor knowing the IP address of the AppSpider Enterprise instance would be able to establish a denial of service against users by continually logging them out. The lack of a CSRF token set at user logout meant that requests like these were not properly validated.

This vulnerability could have allowed an attacker to prevent normal AppSpider Enterprise usage—e.g., to prevent scanning from occuring while another attack was performed.

Rapid7 assigned CVE-2017-5265 to this vulnerability (tracked internally as R7-2018-38). It is an instance of CSRF (CWE-352), with a base CVSSv3 score of 3.1. CVE-2017-5265 was fixed in AppSpider Enterprise Version 3.8.197, released in January 2018.

Potential action required: If you are running a version of AppSpider Enterprise older than 3.8.197, you should upgrade to 3.8.197 or newer at your earliest convenience.

Rapid7 thanks Hari Namburi for reporting this vulnerability and working with us during mitigation.

XSS protection

Several stored XSS vulnerabilities were present in AppSpider Enterprise before Version 3.8.207:

  • CVE-2018-5555 (tracked internally as R7-2018-33)
  • CVE-2018-5556 (tracked internally as R7-2018-34)
  • CVE-2018-5558 (tracked internally as R7-2018-36)

These were present in different endpoints affecting different functionality, but overall they allowed potentially malicious actors to inject JavaScript to one section of the app and then execute it in another section. They are all instances of improper neutralization of input (CWE-79), with a base CVSSv3 score of 3.8. All of these vulnerabilities were fixed in AppSpider Enterprise Version 3.8.207, released in August 2018.

Potential action required: If you are running a version of AppSpider Enterprise older than 3.8.207, you should upgrade to 3.8.207 or newer at your earliest convenience.

Additionally, a reflected XSS vulnerability was found on https://www.rapid7.com/resources which allowed JavaScript to be included in a URL parameter. This could have enabled malicious users to steal session data and other sensitive information. Such a vector is also useful in phishing attacks, as the familiar domain and reasonable path would make a phishing URL harder to spot.

Rapid7 assigned R7-2018-11 to this vulnerability. It is an instance of improper neutralization of input (CWE-79), with a base CVSSv3 score of 6.1. R7-2018-11 was fixed in March 2018 via additional sanitization of URL parameters. Because this vulnerability is found in a hosted application, it is not eligible for a CVE assignment (see inclusion rule 3 of CVE counting policy).

Rapid7 thanks Athar Syed for reporting this vulnerability and working with us during mitigation.

Sensitive information handling

Passwords and URLs

When password complexity was checked in AppSpider Enterprise before Version 3.8.207, the password value was passed as a URL parameter. Capturing this value could have allowed a malicious actor to log in as a valid user, and then change that user’s password to delay future access.

This vulnerability would be difficult to exploit through either of two main vectors: An attacker would need to be able to read HTTPS-encrypted GET requests to the AppSpider Enterprise instance during a time when a user triggered a password complexity check (i.e., during password changes/resets), or gain access to AppSpider Enterprise web server logs or locally cached browser histories, where the request parameters are likely stored unencrypted.

Rapid7 assigned CVE-2018-5557 to this vulnerability (tracked internally as R7-2018-35). It is an instance of Information Exposure Through Query Strings in GET Requests (CWE 598), with a base CVSSv3 score of 4.2. CVE-2018-5557 was fixed by changing the password complexity check to use a POST request. This was released in AppSpider Enterprise Version 3.8.207 in August 2018.

Potential action required: If you are running a version of AppSpider Enterprise older than 3.8.207, you should upgrade to 3.8.207 or newer at your earliest convenience.

Passwords and updates

During the process of updating, AppSpider Enterprise before Version 3.8.205 exposed the credentials for the AppSpider Enterprise database in plain text. The credentials were displayed in a user dialog within the installer/update interface. No evidence of the credentials was found in AppSpider Enterprise log files, so exposure is limited to display on the AppSpider Enterprise host running the update (and any custom modifications, such as user-added logs).

Obtaining these credentials would allow a malicious actor to access the AppSpider Enterprise DB. Additionally, the account used for DB access may be a domain service account, which could allow access to additional networked systems in the same domain. Note that credentials used for testing applications with AppSpider Enterprise would not be exposed in this scenario.

Since the update script is run from the host system itself, exploiting this vulnerability would require that an attacker have local access to the host running AppSpider Enterprise, and that they observe the update dialog. Having access to the AppSpider Enterprise instance web UI would not be sufficient. There are additional and unlikely requirements for this vulnerability to be exploitable remotely (viz. that the attacker have access to the host via RDP, and that they log in as the same user running the update dialog), and so we do not characterize it as such.

Rapid7 assigned R7-2018-48 to this vulnerability. It is an instance of Insecure Storage of Sensitive Information (CWE 922), with a base CVSSv3 score of 7.5. R7-2018-48 was fixed in AppSpider Enterprise Version 3.8.205, released in June 2018.

Potential action required: If you are running a version of AppSpider Enterprise older than 3.8.205, you should upgrade to 3.8.205 or newer at your earliest convenience.

Rapid7 thanks Matt Pardo for reporting this vulnerability and working with us during mitigation.

Service paths

Before Version 3.8.206, the AppSpider Enterprise Scheduler Service used an unquoted service path during registration. This meant that an executable placed in the proper path could have been preferred over the executable intended. This in turn could have allowed a malicious actor to escalate their local privileges, or even escalate to a domain account depending on configuration.

Exercising this vulnerability is difficult since it requires the malicious actor already have access to the AppSpider Enterprise host, as well as write permissions to place executables in the needed filesystem location within the service path. If those conditions are met and a malicious executable successfully placed, the attacker must then wait for the service (or parent host OS) to restart. This restart would run the malicious executable and allow the attacker to run actions of their choosing.

Rapid7 assigned R7-2018-24 to this vulnerability. It is an instance of Unquoted Search Path or Element (CWE-428), with a base CVSSv3 score of 7.8. R7-2018-24 was fixed in AppSpider Enterprise Version 3.8.206, released in July 2018.

Potential action required: If you are running a version of AppSpider Enterprise older than 3.8.206, you should upgrade to 3.8.206 or newer if possible.

DNS and CloudFront

As we discussed in the 2018 Q1 wrap-up section on DNS and CloudFront, discrepancies between CloudFront alternate domain names and DNS CNAMEs are problematic. They can expose you to the risk of previously valid URLs being taken over and used for malicious intent.

We must share that lesson again today, as we found another instance of this issue in R7-2017-16 thanks to a disclosure from someone in the community. As before, a DNS CNAME that was no longer in use after a new name was put into production pointed to CloudFront, but a CloudFront distribution was no longer associated with it. This could have allowed a malicious actor to create a new CloudFront distribution and associate it with this CNAME, enabling them to use realistic-looking URLs that they control. Thankfully we were alerted to R7-2017-16 by a kind vulnerability reporter instead of a malicious actor, and the CNAME entry was removed. For further potential concerns on this type of vulnerability, check out the 2018 Q1 wrap-up section on DNS and CloudFront.

This new instance of the same issue was likely missed due to the CNAME being used within a product offering that is still in development. When a project involves new development teams, new approaches to offering products, and new deployment workflows, it can be easy to miss issues like this. Automation in deployment and verification can help, but it’s also key to communicate and review security checks and other hygiene steps during projects that aren’t business as usual.

Summary: Takeaways

  • CSRF: It can be easy to classify some endpoints that are vulnerable to CSRF as low-priority, but remember that these can still be useful to an attacker in the right scenario. Don’t push them down the priority pile precipitously!
  • XSS: The first rule of secure application design is, “Don’t trust user-controlled input.” While experienced software developers should know this well, it can be seductive to assume that a machine-generated string isn’t “user-generated,” and thus, not “user-controlled” in any way. This temptation may be why injection is the No. 1 risk in OWASP’s Application Security Top 10 list.
    • Determine the complete provenance of text strings that are processed in your web application to ensure any component from user input is properly sanitized first.
  • GET request parameters: HTTPS is a wonderful way to encrypt web content and protect it from prying eyes in general, but GET requests require special handling. Parameters for GET requests can be exposed through unencrypted storage in artifacts of normal web browsing such as web server logs, local browser history, and referrer headers (e.g., if the secure page requests an external asset). Thus, any sensitive information, such as passwords, should be passed only as POST parameters, which aren’t normally recorded in the artifacts above.
    • POST parameters in an HTTPS request are likely to stay secret between client and web server, while everything else—GET parameters, path names, and domain names—can be leaky. Check out this article for an example of GET parameter exposure in various contexts.
  • Audit password usage: It may seem obvious, but it is worth repeating—anywhere that password values are called is a terrific place to audit. Ensure that you know where the value will be shown and where it might be stored. And for any such case, ask whether it really needs to be shown or stored there.
  • Quote service paths: Always ensure that paths to executables are properly quoted. A lack of quoting along with a space in one or more name components opens up the possibility of placing executables that will win the resolution race and be called without your desired executable any the wiser.
    • Check out this article for examples and ways you can check for vulnerable service paths. Also see this article for common difficulties exploiting this vulnerability and more examples of checking for it.
  • Audit DNS records that point to CloudFront: These must either be registered with an active CloudFront distribution or removed.
    • Gotcha: It can be easy to miss records used for new projects still in incubation! Take the time to communicate and review security checks with teams working on projects that aren’t business as usual.

Thanks again to all the community contributors that help Rapid7 better secure our products and services—both those named above, and those who opted to stay anonymous. Please keep the reports coming! ☄️