Today, we’d like to announce eight vulnerabilities that affect four Rapid7 products, as described in the table below. While all of these issues are relatively low severity, we want to make sure that our customers have all the information they need to make informed security decisions regarding their networks. 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.

For all of these vulnerabilities, the likelihood of exploitation is low, due to an array of mitigating circumstances, as explained below.

Rapid7 would like to thank Noah Beddome, Justin Lemay, Ben Lincoln (all of NCC Group); Justin Steven; and Callum Carney - the independent researchers who discovered and reported these vulnerabilities, and worked with us on pursuing fixes and mitigations.

Rapid7 ID

|

CVE

|

Product

|

Vulnerability

|

Status

—|—|—|—|—

NEX-49834

|

CVE-2017-5230

|

Nexpose

|

Hard-Coded Keystore Password

|

Fixed (6.4.50-2017-0809)

MS-2417

|

CVE-2017-5228

|

Metasploit

|

stdapi Dir.download() Directory Traversal

|

Fixed (4.13.0-2017020701)

MS-2417

|

CVE-2017-5229

|

Metasploit

|

extapi Clipboard.parse_dump() Directory Traversal

|

Fixed (4.13.0-2017020701)

MS-2417

|

CVE-2017-5231

|

Metasploit

|

stdapi CommandDispatcher.cmd_download() Globbing Directory Traversal

|

Fixed (4.13.0-2017020701)

PD-9462

|

CVE-2017-5232

|

Nexpose

|

DLL Preloading

|

Fixed (6.4.24)

PD-9462

|

CVE-2017-5233

|

AppSpider Pro

|

DLL Preloading

|

Fix in progress (6.14.053)

PD-9462

|

CVE-2017-5234

|

Insight Collector

|

DLL Preloading

|

Fixed (1.0.16)

PD-9462

|

CVE-2017-5235

|

Metasploit Pro

|

DLL Preloading

|

Fixed (4.13.0-2017022101)

CVE-2017-5230: Rapid7 Nexpose Static Java Keystore Passphrase

Cybersecurity firm NCC Group discovered a design issue in Rapid7’s Nexpose vulnerability management solution, and has released an advisory with the relevant details here. This section briefly summarizes NCC Group’s findings, explains the conditions that would need to be met in order to successfully exploit this issue, and offers mitigation advice for Nexpose users. **Update:**As of August 9, 2017, keystore management has been overhauled, thus resolving this issue.

Conditions Required to Exploit

One feature of Nexpose, as with all other vulnerability management products, is the ability to configure a central repository of service account credentials so that a VM solution can login to networked assets and perform a comprehensive, authenticated scan for exposed, and patched, vulnerabilities. Of course, these credentials tend to be sensitive, since they tend to have broad reach across an organization’s network, and care must be taken to store them safely.

The issue identified by NCC Group revolves around our Java keystore for storing these credentials, which is encrypted with a static, vendor-provided password, “r@p1d7k3y5t0r3.” If a malicious actor were to get a hold of this keystore, that person could use this password to decrypt and expose all stored scan credentials. While this is not obviously documented, this password is often known to Nexpose customers and Rapid7 support engineers, since it’s used in some backup recovery scenarios.

This vulnerability is not likely to offer an attacker much of an advantage however, since they would need to already have extraordinary control over your Nexpose installation in order to exercise it. This is because you need high level privileges to be able to actually get hold of the keystore that contains the stored credentials. So, in order to obtain and decrypt this file, an attacker would need to already have at least root/administrator privileges on the server running the Nexpose console, OR have a Nexpose console “Global Administrator” account, OR have access to a backup of a Nexpose console configuration.

If the attacker already has root on the Nexpose console, the jig is up; customers are already advised to restrict access to Nexpose servers through normal operating system and network controls. This level of access would already represent a serious security incident, since the attacker would have complete control over the Nexpose services and could leverage one of any number of techniques to extend privileges to other network assets, such as conducting local man-in-the-middle network monitoring, local memory profiling, or other, more creative techniques to increase access.

Similarly, Global Administrator access to the Nexpose console would, at minimum, allow an attacker to obtain a list of every vulnerable system in scope, alter or skip scheduled scans, and create new and malicious custom scan templates.

That leaves Nexpose console backups, which we believe represents the most likely attack vector. Sometimes, backups of critical configurations are stored in networked locations that aren’t as secure as the backed-up system itself. We advise against this, for obvious reasons; if backups are not secured at least as well as the Nexpose server itself, it is straightforward to restore the backup to a machine under the attacker’s control (where he would have root/administrator), and proceed to leverage that local privilege as above.

Designing a Fix

While encrypting these credentials at rest is clearly important for safety’s sake, eventually these credentials do have to be decrypted, and the key to that decryption has to be stored somewhere. After all, the whole point of a scheduled, authenticated scan is to automate logins. Storing that key offline, in an operator’s head, means having to deal with a password prompt anytime a scan kicks off. This would be a significant change in how the product works, and would be a change for the worse.

Designing a workable fix to this exposure is challenging. The simple solution is to enable users to pick their own passwords for this keystore, or generate one per installation. This would at least force attackers who have gained access to critical network infrastructure to do the work of either cracking the saved keystore, or do the slightly more complicated work of stepping through the decryption process as it executes.

Unfortunately, this approach would immediately render existing backups of the Nexpose console unusable – a fact that tends to only be important at the least opportune time, after a disaster has taken out the hosting server. Given the privilege requirements of the attack, this trade-off, in our opinion, isn’t worth the future disaster of unrestorable backups.

While we do expect to implement a new strategy for encrypting stored credentials in a future release, care will need to be taken to both ensure that the customer experience with disaster recovery remains the same and support costs aren’t unreasonably impacted by this change.

Mitigations for CVE-2017-5320

As of August of 2017, a fixed version has been released.

CVE-2017-5228, CVE-2017-5229, CVE-2017-5231: Metasploit Meterpreter Multiple Directory Traversal Issues

Metasploit Framework contributor and independent security researcher Justin Steven reported three issues in the way Metasploit Meterpreter handles certain directory structures on victim machines, which can ultimately lead to a directory traversal issue on the Meterpreter client. Justin reported his findings in an advisory, here.

Conditions Required to Exploit

In order to exploit this issue, we need to first be careful when discussing the “attacker” and “victim.” In most cases, a user who is loading and launching Meterpreter on a remote computer is the “attacker,” and that remote computer is the “victim.” After all, few people actually want Meterpreter running on their machine, since it’s normally delivered as a payload to an exploit.

However, this vulnerability flips these roles around. If a computer acts as a honeypot, and lures an attacker into loading and running Meterpreter on it, that honeypot machine has a unique opportunity to “hack back” at the original Metasploit user by exploiting these vulnerabilities.

So, in order for an attack to be successful, the attacker, in this case, must entice a victim into establishing a Meterpreter session to a computer under the attacker’s control. Usually, this will be the direct result of an exploit attempt from a Metasploit user.

Designing a Fix

Justin worked closely with the Metasploit Framework team to develop fixes for all three issues. The fixes themselves can be inspected in the open source Metasploit framework repository, at Pull Requests 7930, 7931, and 7932, and ensure that data from Meterpreter sessions is properly inspected, since that data can possibly be evil. Huge thanks to Justin for his continued contributions to Metasploit!

Mitigations for CVE-2017-5228, CVE-2017-5229, CVE-2017-5230

In addition to updating Metasploit to at least version 4.3.20, Metasploit users can help protect themselves from the consequences of interacting with a purposefully malicious host with the use of Meterpreter’s “Paranoid Mode,” which can significantly reduce the threat of this and other undiscovered issues involving malicious Meterpreter sessions.

CVE-2017-5232, CVE-2017-5233, CVE-2017-5234, CVE-2017-5235: DLL Preloading

Independent security researcher Callum Carney reported to Rapid7 that the Nexpose and AppSpider installers ship with a DLL Preloading vulnerability, wherein an attacker could trick a user into running malicious code when installing Nexpose for the first time. Further investigation from Rapid7 Platform Delivery teams revealed that the installation applications for Metasploit Pro and the Insight Collector exhibit the same vulnerability.

Conditions Required to Exploit

DLL Preloading vulnerabilities are well described by Microsoft, here, but in short, DLL preloading vulnerabilities occur when a program fails to specify an exact path to a system DLL; instead, the program can seek that DLL in a number of default system locations, as well as the current directory.

In the case of an installation program, that current directory may be a general “Downloads” folder, which can contain binaries downloaded from all sorts of places.

If an attacker can convince a victim to download a malicious DLL, store it in the same location as one of the Rapid7 installers identified above, and then install one of those applications, the victim can trigger the vulnerability. In practice, DLL preloading vulnerabilities occur more often on shared workstations, where the attacker specifically poisons the Downloads directory with a malicious DLL and waits for the victim to download and install an application susceptible to this preloading attack. It is also sometimes possible to exercise a browser vulnerability to download (but not execute) an arbitrary file, and again, wait for the user to run an installer later. In all cases, the attacker must already have write permissions to a directory that contains the Rapid7 product installer.

Usually, people only install Rapid7 products once each per machine, so the window of exploitation is also severely limited.

Designing a Fix

In the case of Metasploit Pro, Nexpose, and the Insight Collector, the product installers were updated to define exactly where system DLLs are located, and no longer rely on dynamic searching for missing DLLs. An updated installer for Appspider Pro will be made available once testing is completed.

Mitigations for CVE-2017-5232, CVE-2017-5233, CVE-2017-5234, CVE-2017-5235

In all cases, users are advised to routinely clean out their “Downloads” folder, as this issue tends to crop up in installer packages in general. Of course, users should be aware of where they are downloading and running executable software, and Microsoft Windows executables support a robust, certificate-based signing procedure that can ensure that Windows binaries are, in fact, what they purport to be.

Users who keep historical versions of installers for backup and downgradability purposes should be careful to only launch those installation applications from empty directories, or at least, directories that do not contain unknown, unsigned, and possibly malicious DLLs.

Coordinated Disclosure Done Right

NCC Group, Justin Steven, and Callum Carney all approached Rapid7 with these issues privately, and have proven to be excellent and accommodating partners in reporting these vulnerabilities to us. As a publisher of vulnerability information ourselves, Rapid7 knows that this kind of work can at times be combative, unpleasant, and frustrating. Thankfully, that was not the case with these researchers, and we greatly appreciate their willingness to work with us and lend us their expertise.

If you’re a Rapid7 customer who has any questions about this advisory, please don’t hesitate to contact your regular support channel, or leave a comment below.