Posted by Mike Pittenger on September 7, 2017
“This is as serious as it gets; if remote attackers are allowed to exploit the newly identified vulnerability it can critically damage thousands of enterprises.” Oege de Moor, CEO and founder of Semmle.
Dozens of Fortune 100 companies are at risk after security researchers at lgtm.com discovered a critical Apache Struts security flaw (CVE-2017-9805) that is “easy” to hack (Rapid7 and Tenable have released plug-ins to detect and exploit the vulnerability just one day after the disclosure). This security flaw, which affects open source server software, serves as yet another reminder to have full visibility over all components used in your software.
Lockheed Martin, the IRS, and Virgin Atlantic have all previously developed applications using the affected Struts framework. This showcases that the risk transcends our defense, financial, and transportation industries, and has the potential to have damaging outcomes for the large number of websites that use the framework.
Organizations that have not kept an accurate list of all components used within each application are forced to scan their entire environment if a vulnerability is announced. Using a vulnerability assessment tool, such as those developed by Tenable or Rapid7, to identify vulnerable versions of Struts can take days, as it did for many organizations when Heartbleed was disclosed. Meanwhile, vulnerabilities are left susceptible in the interim.
This fire drill happens with every new critical vulnerability, because the vulnerability assessment tools have no persistent knowledge of the applications we build and the components used. Additionally, these tools only have plug-ins for a handful of the vulnerabilities reported in open source components each year. Companies that rely solely on the tools are blind to the thousands of vulnerabilities in open source each year for which plug-ins aren’t built.
There is a simpler way to handle these incidents, and it’s not new nor a secret. In fact, the automotive industry solved this problem over one hundred years ago. It’s called a bill of materials; a detailed listing for all parts used in a vehicle. When a recall is issued for a part such as an airbag, the OEMs don’t have to scan every vehicle manufactured to discover which ones are using the defective part. Through the bill of materials, they know precisely which vehicles are affected, down to the VIN.
Doing the same with software — maintaining an accurate list of all components used in each application — makes incident response much easier when vulnerabilities like this are disclosed. While a software bill of material won’t tell you whether or not the vulnerabilities are exploitable — you still need Tenable or Rapid7 for that — it will allow you to quickly know which applications are potentially vulnerable and save your security team hours or days of assessment time.
Get the latest AppSec news and trends sent directly to you.