A number of important security issues were resolved in Metasploit (Pro, Express, and Community editions) this week. Please update as soon as possible.

Issue 1: Localhost restriction bypass
   (affects versions 4.12.0-2016061501 through 4.12.0-2016083001)

On initial install, the Metasploit web interface displays a page for setting up an initial administrative user. After this initial user is configured, you can login and use the Metasploit web UI for the first time. Since this initial screen is unauthenticated, it can only be accessed via a local user (e.g. hitting the localhost hostname or loopback IP address 127.0.0.1).

Until the most current release, the initial setup page access restriction does not work properly in Metasploit 4.12.0 releases. Instead, on initial install, the page for setting up the initial administrative user is accessible from all addresses on the host running Metasploit.  An attacker might be able to 'race' a fresh Metasploit installation and become the first to create an administrative user.

Mitigation:

For users who are planning on using Metasploit with the web interface, it is important to isolate the machine from hostile networks until initial configuration is complete, or be sure to use the latest Metasploit installer in which this issue is resolved.

Thanks to Brandon Perry for discovering and reporting this issue.

Issue 2: Predictable session cookies
   (affects versions 4.12.0-2016061501 through 4.12.0-2016083001)

Metasploit uses a randomized secret key to protect session cookies from forgeries. On installation, it randomizes the secret key and stores it in a local configuration file.

As of Metasploit 4.12.0, the update packages inadvertently include a static version of this secret key file, which overwrites the randomly-generated one. The effect of this is that some Metasploit installations will all have the same hard-coded base session token, leading to forgeable session cookies, allowing an unauthenticated user to perform remote code execution via another object deserialization bug.

Mitigation:

On startup, Metasploit will identify 'bad' static secret keys that may be installed, and if found, the base secret key is regenerated. If this fix is needed, and if a user is applying the latest update via the web UI, the UI may appear to hang during the update, though it will complete successfully in the background. In this case, simply refresh the web UI after 10-20 minutes. If it loads a login screen, the update applied successfully.

Users who updated from 4.11.0 or earlier builds are not affected, but are still encouraged to update.

Thanks to Justin Steven for discovering and reporting this issue.

Issue 3: config.action_dispatch.cookies_serializer is set to :hybrid
   (affects versions 4.12.0-2016061501 through 4.12.0-2016083001

Metasploit versions 4.11.x and earlier use the default 'marshal' cookie type, which is vulnerable to remote object instantiation / remote code injection for a user who has the ability to generate a signed session cookie.

Mitigation:

The Metasploit 4.12.0 point release switched to the 'hybrid' type, which gives an update path for users to the safer 'json' type. The latest release switches entirely to 'json' cookie serialization method.

Thanks to Justin Steven for discovering and reporting this issue.