There’s A New Struts 2 Vulnerability, Take Heed

The breach suffered last year by credit rating agency, Equifax, when details of more than 145 million U.S. customers was stolen, continues to remain a burning topic. In fact, Flexera is sounding an alert that there’s a new high-risk Struts vulnerability that can be exploited by malicious people to compromise a vulnerable system.

It’s imperative that organisations patch Struts now (without ignoring other vulnerabilities), as its visibility is likely to generate issues quickly. Organisations must undertake a re-prioritisation effort for the following reasons:

• The same day this vulnerability was disclosed, Flexera’s Secunia Research documented 25 other vulnerabilities in software from Avaya, IBM, Ubuntu, SUSE, Photoshop, Symantec and phpMyAdmin amongst many others.
• A Highly Critical vulnerability in the popular mozjs52 Spidermonkey JavaScript library for Ubuntu is also of consideration for operations teams.
• gtk2 for Suse also has a new update to fix about five vulnerabilities (some from last year!), with the most recent one being Highly Critical as deemed by Secunia Research with a CVSSv3 score of 8.8.
• Ghostscript is an Open Source Software (OSS) component with a highly critical, not patched (yet) vulnerability that seems to affect ImageMagick, Evince, GIMP and other PDF/PS tools.
• The popular mutt email client for various Linux flavours has a recently disclosed vulnerability with 9.8 score for most flavours of the Operating System (OS). Many advisories have been issued, and we’ve seen this system installed in production servers. With a remote, highly critical vulnerability out there, we expect security teams to be on high alert.

In the year since the Equifax hack, many organisations have been putting into place new policies and procedures designed to reduce the threat introduced by third-party software with known vulnerabilities. This new analysis process is called Software Composition Analysis (SCA). If you had asked these same organisations before the hack if they felt that they were already following the correct steps to mitigate these types of issues, they would have likely (and incorrectly) replied that they were.  While examining their codebases and projects as part of this response, a few top level discoveries were made:

They are using orders of magnitude more third-party software (mostly open source) than they knew about

Data shows that the typical software development team is aware of less than 5 percent of their true Bill of Materials (BOM). These BOMs also are much larger than they expected, often running to 500 or more OSS components. In many cases, even if they can produce a BOM it has never been checked for known vulnerabilities. Often there is finger pointing and shifting of blame in terms of who is responsible for discovering, triaging and remediating these types of issues.

Their software supply chain is exposed to these types of issues and is unprepared to mitigate them

While many of the third-party dependencies present in a codebase are introduced by the software development organisation itself, it’s common to discover significant amounts of the third-party software originates through the software supply chain. This means that there are undisclosed and un-tracked subcomponents brought in via both top level OSS components or through Commercial components. It’s rare to receive of BOM from either OSS or Commercial projects, which makes it difficult to compare the subcomponent against the list of known vulnerabilities such as the National Vulnerability Database (NVD). More and more companies are requiring a BOM to be provided by their commercial partners at code delivery time and are writing this into their commercial contracts. In the OSS world, it’s becoming more common to see projects trying to start tracking these types of issues, though it’s still rare to see a BOM delivered along with the projects code.

Responding to this issue requires coordination between Security, Development and Legal in ways they haven’t had to work together before

Even a couple years ago, most of the Open Source or Commercial vulnerabilities that were tracked internally were for large IT infrastructure pieces like operating systems, Web servers, databases and routers. The 2014 Heartbleed vulnerability in OpenSSL showed that lower level software components that could affect systems are Internet scale. While this vulnerability received global attention, it didn’t seem to cause the same response among purchasers or maintainers as the Struts2 related vulnerability has.  As part of this response Security, Development and Legal have had to work together to review lists of software components typically in the range of hundreds of components. Additionally, these reviews are discovering components that not only have known vulnerabilities, but open source or commercial licensing issues as well. Working with the software supply chain means working backward to discover who introduced a vulnerable component, sometimes crossing multiple commercial and open source lines.

By adding SCA to your security response, your organisation will be able to better protect your customers and business against external attacks. While this process will require creating new processes and response flows, the benefits of better knowledge of software dependencies and more rapid alerting to new vulnerabilities leads to faster response times and mitigation of security issues.