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

Nexpose

259 posts

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.

anowak

Update Tuesday, December 2015

Posted by anowak Employee Dec 8, 2015

December continues this quarter’s trend, 10 bulletins addressing remote code execution (RCE) vulnerabilities, while the remaining two address elevation of privilege. The vulnerabilities affect Internet Explorer (7 and onwards), Edge, Office, Silverlight, VBScript scripting engine and Windows (Vista and onwards). It is advisable for users and administrators to patch the affected platforms.

 

Microsoft released 12 security bulletins this month, two thirds of them rates as critical, resolving a total of 58 vulnerabilities. All of the critical bulletins (MS15-124, MS15-125, MS15-126, MS15-127, MS15-128, MS15-129, MS15-130, MS15-131) are remote code execution issues affecting a variety of products and platforms including Edge, Internet Explorer, Live Meeting, Lync, Office, Office for Mac, Office Web Apps, Silverlight, Skype, VBScript and all supported releases of Microsoft Windows.

 

Specifically, MS15-124, MS15-125 and MS15-128 are the bulletins to watch out for this month, addressing 33 vulnerabilities. Since a wide range of products are affected this month almost all Microsoft users should be on alert. Microsoft’s update addresses the vulnerabilities by resolving underlaying issues with how certain functions in VBScript handle objects in memory, preventing cross site scripting (XSS) from incorrectly disabled HTML attributes, proper enforcement of content types and cross–domain policies.

 

From the bulletins released in December, the following vulnerabilities are know to have been exploited:

 

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

 

Resolved Vulnerability Reference:

Building an Application Vulnerability Management Program, found in the SANS Institute Reading Room (https://www.sans.org/reading-room/whitepapers/application/building-application-v ulnerability-management-program-35297), identifies vulnerability program management as a cyclical process involving the following steps:

  • Policy
  • Discovery and Baseline
  • Prioritization
  • Shielding and Mitigation
  • Eliminating the Root Cause
  • Monitoring

 

While the use of Nexpose applies to several of these steps, the scope of this article is how Adaptive Security fits into your vulnerability management program. To that end we will cover monitoring.

 

Monitoring

Monitoring is the part of the vulnerability management cycle where changes and refinements are considered and adjustments are made before proceeding to the next iteration. Two critical areas of change to consider are as follows:

  • Covering gaps in your vulnerability assessments
  • Discovery of new vulnerabilities

 

Covering Your Blindspots

Your run regular scans to discover and assess the assets connected to your network. You carefully schedule the vulnerability scans on nights and weekends to reduce the impact on your network during business hours. How will you ensure that of those laptops that people take home and on the road are also scanned for vulnerabilities? Adaptive Security allows you to automatically detect and scan assets that were previously connected to your network and have missed recent vulnerability scans.

 

There is a prerequisite for an automated action to employ the discovery trigger:

 

To create or manage automated actions, click the automated actions icon on the top navigation bar.

AdaptiveSecurityInVMP-01.png

Click the NEW ACTION button to create a new action.

AdaptiveSecurityInVMP-02.png

Select the type of trigger for your action. For this use case, we'll choose "Known asset available" to detect when assets are reconnected to the network.

AdaptiveSecurityInVMP-21.png

Next, select the discovery connection you wish to use as the source for this trigger. We're using a DHCP dynamic discovery connection that accepts Infoblox Triznic log entries via syslog.

AdaptiveSecurityInVMP-22.png

Optionally specify one or more filter criteria to refine the assets to be processed. Since we want to scan returning assets that have missed recent scans, we'll select Hours Since Last Scan and enter 84 to include only assets that have not been scanned in a week. Click on the Next button to continue.

AdaptiveSecurityInVMP-23.png

Select the action to take when the trigger is invoked. We'll use "Scan." Since this action uses the site from each asset's most recent scan, there is no need to provide any further information.

AdaptiveSecurityInVMP-24.png

Enter a descriptive and unique name for this action and then click the Save button.

AdaptiveSecurityInVMP-25.png

You should see you new automated action in the list. Here you may view the current state of the action and turn it on and off.

AdaptiveSecurityInVMP-26.png

From this point forward, the automated action will scan all returning assets that have not been scanned in the last week.

 

Reacting to New Vulnerability Discoveries

Researchers continuously discover and publish new vulnerabilities. Quickly assessing your network’s exposure to the more critical new vulnerabilities is essential. Also, with the seemingly increasing number of high-profile breaches in the media, you need to be able to report your assessed risk to executives as soon as possible. In any case, you can reduce your risk by scanning for new, critical vulnerabilities as soon as they're published rather than waiting for the next scan window. With Adaptive Security, you can create an automated action that triggers scans for only the new vulnerabilities that meet your criteria as they are published.

 

Click the automated actions icon from the top navigation bar and press the NEW ACTION button. Next, select the "New vulnerability coverage available" trigger. Finally, specify a filter for refining the vulnerabilities that will be automatically scanned.

 

AdaptiveSecurityInVMP-10.png

Select the "Scan for new vulnerabilities" action and then select the site to be scanned when new vulnerabilities are published.

AdaptiveSecurityInVMP-12.png

Enter a unique, descriptive name for the action and press the SAVE button.

AdaptiveSecurityInVMP-13.png

Your new action will be displayed in the list of automated actions. Again, you may view the action state or turn it on and off from here.

    AdaptiveSecurityInVMP-14.png

Your new action will now automatically scan the specified site for the new vulnerabilities that are published and meet your filter criteria.

 

Conclusion

Nexpose was already a major player in your vulnerability management program. Adaptive security makes monitoring possible to complete the loop.

The number one critical security control from the Center for Internet Security recommends actively managing all hardware devices on the network:

 

CSC 1: Inventory of Authorized and Unauthorized Devices

Actively manage (inventory, track, and correct) all hardware devices on the network so that only authorized devices are given access, and unauthorized and unmanaged devices are found and prevented from gaining access.

 

http://www.cisecurity.org/critical-controls.cfm

 

Here a some of the reasons you should actively inventory your hardware:

  • Discover new assets that have not yet patched
  • Detect returning hardware such as laptops that have missed previous updates
  • Identify unauthorized hardware

 

Whatever the scenario, you’ll want to establish your surface area in order to accurately assess your risk and remediate vulnerabilities.

 

Before you can track and correct assets on your network, you must first establish a method to inventory all of the assets connected to your network. Employing a DHCP dynamic discovery connection in Nexpose is a great way to determine what hardware is present on your network.

 

Nexpose dynamic asset discovery via DHCP parses DHCP server logs and supports two collection methods for gathering DHCP log entries:

  • Directory watcher – watches a specified directory for new and updated DHCP log files.
  • Syslog – listens on a TCP/UDP port to receive syslog messages much like a syslog server

 

Nexpose dynamic asset discovery currently supports Microsoft Server 2008 and 1012 using either directory watcher or syslog, as well as, Infoblox Trinzic using syslog.

 

How to Create a DHCP Discovery Connection

From the Administration page, find the Discovery Options section and click the Create link next to CONNECTIONS.

How-to-DHCP-02.png

Next, fill in all three tabs of the form…

 

From the General tab, select DHCP Service and provide the name of your discovery connection.

How-to-DHCP-03.png

From the Service tab, select the event source, collection method, and engine. The source and collection method will determine what additional fields are required. In the example, using the directory watcher collection method for Windows Server mandates providing the fully qualified path to the directory where DHCP logs reside.

How-to-DHCP-04.png

From the Credentials tab, provide the username and password for you to access the directory.

How-to-DHCP-05.png

As the DHCP server logs events, they will be parsed and imported as assets discovered by connection. Previously assessed assets that appear in DHCP logs will continue to show only as assessed. Discovered assets have not been assessed and present unknown risk to your network.

 

How-to-DHCP-06.png

The Assessment Status chart on the Assets page gives you a clear indication of your un-assessed surface area. Additionally, the Discovered by Connection table enumerates the discovered assets that have not yet been assessed.

Rapid7 has made it a priority to support security industry standards, including the Open Vulnerability and Assessment Language (OVAL).  Those of you who use Nexpose to measure policy compliance, either by using the built-in CIS, DISA, and USGCB policies, or by writing your own custom policies, are using OVAL for these policies.

 

A decision by the National Institute of Standards and Technology (NIST) has made it necessary for us to make changes in our OVAL implementation.  These changes affect policies written for Microsoft Windows systems.  Previously, Nexpose would convert case-sensitive comparators for certain objects and states to case-insensitive comparators, in order to support the case-insensitive behaviour of Windows.  This was a convenient function when uploading third-party policies, which would sometimes be written with default case-sensitive comparators, leading to false positives.

 

In order to comply with NIST's requirements for OVAL, it will now be necessary to honour the comparators exactly as written, meaning that comparators will now default to being case-sensitive on Windows systems.  This will not have any effect on policies that have already been imported into Nexpose, nor will it have any effect on the current set of built-in policies.

 

However, this change will affect:

 

1) Newly uploaded custom policies

2) Custom policies created by copying built-in content

3) Custom policies created by copying previously uploaded custom policies

 

As an example, consider the following registry object:

 

<registry_object xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#windows" 
id="oval:nist.validation.winRegistry:obj:19" version="1">
    <hive>HKEY_LOCAL_MACHINE</hive>
    <key>SOFTWARE\Microsoft\MSMQ\SCAP_Validation_Tests\win_reg\exists</key>
    <name operation="equals">vQwordLE</name>
</registry_object>

 

The name element in that object has an 'operation = "equals"' attribute.  Previously, this attribute would have been automatically converted to be 'operation = "case insensitive equals"'.  With the new change, this will no longer be the case: there will be no conversion, and the attribute will remain as 'operation = "equals"'.  This is also the default behaviour: when no operation is specified, the operation will be "equals".

 

As a result, a policy rule that would have passed regardless of whether the name field in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\SCAP_Validation_Test\win_reg\exists were "vqwordle", or "VQWORDLE", or "vQwordLE", will now only pass when the value in the name field is exactly "vQwordLE".

 

To change the behaviour of the object to match its previous behaviour, you would need to change:

 

<name operation="equals">vQwordLE</name>

 

to be:

 

<name operation="case insensitive equals">vQwordLE</name>

 

The following objects and states will be affected by this change:

accesstoken_object, accesstoken_state

environmentvariable_object, environmentvariable_state

environmentvariable58_object, environmentvariable58_state

fileauditedpermissions_object, fileauditedpermissions_state

fileauditedpermissions53_object, fileauditedpermissions53_state

fileeffectiverights_object, fileeffectiverights_state

fileeffectiverights53_object, fileeffectiverights53_state

file_object, file_state

group_object, group_state

registry_object, registry_state

sid_sid_object, sid_sid_state

sid_object, sid_state

user_object, user_state

 

Depending on your requirements, you may need to rewrite your custom policies to reflect these changes.  It will also be necessary to evaluate the functionality of any new policies that you create by copying previously imported policies.  We regret that this change might be disruptive, but it is necessary to ensure full compatibility with industry security standards.

anowak

Update Tuesday, November 2015

Posted by anowak Employee Nov 10, 2015

November sees a mix of remote code execution and elevation of privilege vulnerabilities enabling an attacker to gain the same rights as the user when the victim opens specially crafted content, such as a webpage, journal file or document containing embedded fonts. These vulnerabilities affect Internet Explorer (7 and onwards), Edge, and Windows (Vista and onwards).  It is advisable for users and administrators to patch the affected platforms.

 

Microsoft includes 12 security bulletins, a third of them rated as critical, resolving a total of 49 vulnerabilities. All of the critical bulletins (MS15-112, MS15-113, MS15-114, MS15-115) are remote code execution issues affecting affecting a variety of products and platforms including Edge, Internet Explorer, Lync, Office, Office for Mac, Office Web Apps, Skype for Business, SharePoint Server and all supported releases of Microsoft Windows.

 

MS15-112 is the bulletin to watch out for this month, it addresses 25 vulnerabilities. It is rated Critical for Internet Explorer 7 - 11 on Windows clients and moderate on Windows servers. Microsoft's update addresses the vulnerabilities by resolving underlaying issues with how objects are handled in memory for JScript and VBScript, properly re-implemeting the ASLR security feature and adding additional permissions to Internet Explorer.

 

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

 

Resolved Vulnerability Reference:

Filter Blog

By date: By tag: