Nessus, Qualys, Metasploit for Struts Vulnerabilities?

The Equifax breach has brought Remote Code Execution (RCE) vulnerabilities in Struts into the spotlight. Nobody wants to be the “next Equifax,” much less the company leadership “retiring” or answering questions from Congress.

Right now, a lot of security people are running around with their hair on fire, trying to figure out if they, too, are vulnerable. How are they doing this? Mostly by loading up vulnerability assessment (VA) tools with special rules for the vulnerabilities, then pointing those at everything in their environments. In some organizations, this will keep their teams busy for weeks.

Kudos to these vendors for having rules (or plug-ins) available for these vulnerabilities almost immediately. This allowed teams that rely on this method to start their fire drills faster.

We’re hearing a lot of questions from prospects about using Nessus, Qualys, and Metasploit for identifying the Struts vulnerabilities. Is it effective? Yes, for those vulnerabilities for which rules or plug-ins are provided. Is it efficient? Absolutely not.

Are Vulnerability Assessment Tools Effective?

Let’s look at effectiveness first. The simplest way to understand vulnerability assessment tools is to think of them as checking for patch levels and configurations for (primarily) commercial products and some open source products and components. For vulnerabilities like the one used in the Equifax attack, some of the tools can run non-destructive exploits of the vulnerability in question. If a rule is provided for a vulnerability, they can effectively identify exploitable versions of the component.

Sometimes many rules are created to cover a vulnerability in different environments or commercial products. For example, Nessus has 85 plug-ins to detect the Heartbleed vulnerability in OpenSSL. For the Equifax vulnerability (CVE-2017–5638), there are 5 plug-ins. Tenable also provides Nessus plug-ins for three other RCE vulnerabilities reported in Struts since March (CVE-2017–9791, CVE-2017–9805, and CVE-2017–12611).

Only Sometimes…

However, not every vulnerability has plug-ins. In 2016, the National Vulnerability Database (NVD) reported over 2,400 vulnerabilities in open source software, the majority of which have no rules or plug-ins in the VA tools.

Maybe they just cover important or high-scoring vulnerabilities? It doesn’t appear so. In 2016, at least six RCE in Struts were disclosed in NVD, none of which have Nessus plug-ins available. These vulnerabilities are exploitable and in the same component exploited in the Equifax breach. Organizations relying on VA tools will be blind to their exposure.

Are VA Tools Efficient?

Vulnerability Assessment tools have no recall — every scan is a new experience of discovering specific use cases. If Microsoft issues a patch for Windows, the tools need to search everywhere for indicators of out-of-date instances. A patch for Adobe — same routine. Oracle — yep! A Struts vulnerability — search everywhere again.

For issues like the Struts vulnerability, and Heartbleed, Poodle, Shellshock, and hundreds of other exploitable vulnerabilities disclosed in open source components each year, VA tools are slow and reactive. Wouldn’t it be easier if you knew where to look for those components?

What If Automotive Recalls Were Handled Like This?

Organizations use VA tools to either continuously scan their environments for misconfigured or unpatched systems, or ad hoc (in the case of the Struts vulnerability, Heartbleed, and other “big” vulnerabilities). So each time a new rule or plug-in is released, the entire environment must be rescanned.

If the car industry ran like this, when a defective part was identified for recall, every car in the world would have to be “scanned” by querying the on-board computer to see if the defective (vulnerable) component was present. The next day — another defective part — another scan required. Consumers and regulators alike would be outraged!

The car industry solved this problem over 100 years ago, and the answer was simple. By maintaining a detailed bill of materials — a listing of every part used in each vehicle — defective parts could be tracked to the precise vehicles using those parts.

What Is the Answer?

Like the answer to most security issues, a multilayered approach works best. In this case, having visibility to the open source you’re using, and maintaining an accurate bill of materials that includes both declared and non-declared components is the first step. Incorporating an automated solution like Black Duck Hub into the build process allows you to avoid adding components with known vulnerabilities to your code. Next, track sources for new vulnerabilities in those components. NVD is a good start, but hundreds of other sources (like those in our enhanced security offering) are even better, providing hundreds of additional vulnerabilities and alerting on them weeks before they appear in NVD.

Maintaining a bill of material changes the dynamics when a new vulnerability is disclosed. Instead of starting from scratch and running VA tools for days across your entire environment, you simply log into your Black Duck console to see every version of the affected component in your application inventory, and which applications use each version.

Next step? Black Duck can’t tell you if the vulnerability is exploitable. So use your VA tools. Run them against the applications identified in your bills of material to determine exploitability and wrap up the triage process.

Open source components like Struts provide development teams with a lot of critical functionality. They save time, reduce costs, and accelerate time to market. It’s software, however, and therefore subject to vulnerabilities (just like your custom code). The problem isn’t that vulnerabilities are disclosed from time to time. It’s that organizations either don’t know they are using the vulnerable components, don’t know that vulnerabilities are present, or don’t bother to remediate the issues when vulnerabilities are disclosed.

Mike Pittenger | VP of Security Strategy
Originally published at