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

Nexpose

264 posts

Introduction

 

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.

drown1.png

---

drown2.png

 

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.

drown3.png

 

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 dasc.name = '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:

 

WITH
   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 dasc.name = '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:

autocomplete.png

 

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!

anowak

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.

aws_scanengine.PNG

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": [

        "ec2:DescribeInstances",

        "ec2:DescribeImages",

        "ec2:DescribeAddresses"

      ],

      "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.
    shared-secret.png

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_PORT=40815
    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 10.3.6.0, 12.1.2.0, 12.1.3.0, 12.2.1.0)

 

...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 CustomEnvironment.properties file that resides in:

 

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

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?

anowak

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.

 

2FA1.png

 

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.

 

 

2FA2.png

 

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

 

 

2FA3.png

 

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.

 

 

2FA4.png

 

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 10.3.6.0, 12.1.2.0, 12.1.3.0, 12.2.1.0 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.

After releasing TLS Coverage Improvements in Nexpose 6.0.2 we figured that the Nexpose Security Console should be able to abide by our own suggestions. Last year we had already disabled SSLv3 support by default and allowed configuring what other protocols are enabled on the console as well. With this week's release we're limiting the TLS cipher suites available to the console's web server by default. Similar to the protocols, the cipher suites can also be configured to be more or less strict as required by your organization.

 

Configuring SSL/TLS Protocol and Cipher Settings

Currently, these settings are configured through the CustomEnvironment.properties file, which can be created/edited in the [installation path]/nsc/ directory. A restart of the Nexpose service is required for changes to take effect. The following examples reflect the default settings, which means setting them exactly as shown will not change anything.

 

For SSL/TLS protocols, the following parameters are allowed:

  • SSLv3
  • SSLv2Hello
  • TLSv1
  • TLSv1.1
  • TLSv1.2

 

To configure the enabled protocols, add the following line to the file where each protocol is separated by a comma without any spaces:

 

com.rapid7.nexpose.nsc.sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2

 

For cipher suites, you can use either Apache-style syntax or JSSE syntax. To configure the enabled cipher suites using Apache-style syntax, add the following line to the file:

 

com.rapid7.nexpose.nsc.sslEnabledCiphers=ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AE S256:ECDH+AES128:DH+AES:!aNULL:!MD5:!DSS

 

If the default cipher suites are not suitable for your use, we suggest reviewing the recommendations from Mozilla as they are quite comprehensive: Security/Server Side TLS - MozillaWiki.

 

SHA-1 Certificates

If your Nexpose Security Console is still using a SHA-1 certificate (generated more than a year ago), you have a few options to upgrade the certificate strength. If you're using the generated self-signed certificate, you can simply generate a new one from the Administration > Administer Console page. Under the Web Server settings click the Manage Certificates button, then generate a new certificate. A restart of the Nexpose service is required for the new certificate to be used.

 

If you're using a certificate signed by an internal or external Certificate Authority (CA) you can generate a new CSR, which requires generating a new self-signed certificate as well. Note that if the parameters of the CSR are not satisfactory for your requirements, your CA may allow overriding some of the settings related to algorithms when signing the certificate.

 

In the future we hope to expand the functionality around certificates and TLS connections from the user interface. We would love to hear your feedback on what options you need the most and how you would like to use them.

Nexpose has long provided the ability to filter vulnerabilities by a wide variety of categories and operators. Starting in Nexpose 6.1, filtering in new-vulnerability actions in Adaptive Security closely mirrors that of Nexpose. New vulnerability actions were covered in a recent blog .How Adaptive Security fits into your Vulnerability Management Program).nexposeVulnFilters.png

adaptiveVulnFilters.png

 

Similarity to Nexpose Filtering

The enhanced filters now mirror those of Nexpose in their entirety. Users can now automate any workflows they have which only operate on certain types of vulnerabilities.

 

More Selective Scanning

This enhanced filtering allows users to be much more specific in which types of new vulnerabilities are scanned for. Nexpose released an average of 283 new vulnerabilities per week in 2015, but depending on the customer's assets, only some vulnerabilities are worth scanning for right away. The new filters allow much more pin-pointed scans that target exactly the types of vulnerabilities the user is concerned about.

 

Example Use Case

Suppose a user has a site which does not contain any Windows assets. They want to scan right away for high-risk vulnerabilities, but not Microsoft-related vulnerabilities, because those should not be applicable to their assets. With this knowledge, they can filter only the vulnerabilities they are interested in.

 

noWindows.png

 

Over the last year, Nexpose added 13,854 new vulnerabilities, but only 6001 met these criteria. Applying these filters will prevent scans for new vulnerabilities that are uninteresting.

The SNMP protocol is very common, has many implementations and is deployed in diverse networks. In some cases it responds very promptly, in others it is relatively slow to respond. We found that in some environments a 1 second request timeout was insufficient, so in Nexpose 6.1.1 we have changed the default to 3 seconds in order to improve the service and related vulnerability detection.

 

This, however, can have a major impact on scan times on port 161 and may not be desirable on networks with low latency as all relevant vulnerability checks wait 3 times longer to timeout (currently 77 checks). This is why we made the SNMP request timeout configurable via JVM property.


The value of SNMP request timeout can be changed for the console by running a console command. From Administration tab select 'Run' link under 'Maintenance, Storage and Troubleshooting section'. Type:

set custom property com.rapid7.net.snmp.requestTimeout=10000

(this will set the timeout to 10 seconds, as the value is represented in milliseconds) and hit the 'Execute' button. The new value is applied immediately and will be used in running scans.


Alternatively the timeout can be changed by creating a file called CustomEnvironment.properties (if it doesn't exist already) in:

  • [INSTALLATION_PATH]/nsc for Nexpose console or
  • [INSTALLATION_PATH]/nse for Nexpose engine,

and adding the following line to this file:

com.rapid7.net.snmp.requestTimeout=10000

(again, this will set the timeout value to 10 seconds). The console or engine must be restarted after making the changes to take effect.

Filter Blog

By date: By tag: