Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

10:30 AM
Kevin E. Greene
Kevin E. Greene
Connect Directly
E-Mail vvv

'Strutting' Past the Equifax Breach: Lessons Learned

In hindsight, there were two likely causes for last year's massive breach: the decision to use Apache Struts, and a failure to patch in a timely fashion. Both are still a recipe for disaster.

The industry is still feeling the lingering effects of the Equifax breach, and, according to Sonatype, some things still haven't changed. I recently came across a Fortune article that takes a retrospective look at the Equifax breach and examines Sonatype research data on the vulnerable Apache Struts component that caused the breach. The research data used to analyze the usage and consumption of the vulnerable Apache Struts component suggest that people in organizations are still downloading it and could possibly be using the vulnerable component in production systems.

For an example, the article points out that as many as 10,801 organizations — including 57% of the Fortune Global 100 — have downloaded "known-to-be" vulnerable versions of Apache Struts. It further points out that as many as 3,049 organizations have downloaded the exact same vulnerabilities that hackers exploited to break into Equifax — that is, the same holes contained in Struts version 2.2.3 to and 2.5 to 2.5.10 (CVE-2017-5638).

Over the last year or so, my views about vulnerable components have changed, and they've been strongly influenced by the growing reliance and consumption of open source software (OSS) in modern software development. The Apache Struts consumption rate cited in the Fortune article is part of a growing realization to me that developers may have taken the position (or have surrendered to the idea) that all software is vulnerable (or at least the most popular and frequently used OSS components) and have "known" vulnerabilities. I refuse to believe that developers are that careless, reckless, and have zero regard for the potential risks in using insecure software. When time is of the essence, people tend to sacrifice optimal for suboptimal, especially when choices and selections are slim. Organizations are in a dash to beat their competitors to market with new features and functionality for competitive advantage, which often means they take shortcuts to get there.

As a dad with two boys that play sports that involve travel, we are always on the road going from one game or tournament to another, and we tend to eat more fast food during the travel seasons. At times, I feel like I'm sacrificing good eating habits because my choices are slim, and often we are pressed for time. There are other options like packing my own lunch … or for developers, building your own software components. Jim Routh, chief security officer at Aetna indicated on my podcast that based on Build Security-In Maturity Model (BSIMM) research data, the mentality of many companies on the West Coast is to build their own software (they are the supply chain) rather than buy it. I'm sure there is some OSS consumption, but the point is that there is less reliance on third party suppliers, which may ultimately help reduce risks and improve software security.

Mission Impossible: Vulnerability-Free Software
Let's assume that developers don't subscribe to my theory. In that case, I still don't believe that software can be "free" from vulnerabilities. Today's software is too complex, organizations are taking far too many shortcuts to get to market faster, there is a lack of core fundamentals of software engineering being taught in academia, tools that are designed to find weaknesses and vulnerabilities in software don't perform well, developers don't understand the consequences of their coding practices and refactoring activities on software design ... the list goes on and on. All these things become detrimental to the hygiene of software. However, that doesn't mean we should give up ... or not exercise proper due care and due diligence when scouring the software supply chain looking for software components to consume for software development projects. It simply means that we need to adjust our expectations and approaches to software supply chain risks and modern software development, especially as the adoption of DevOps increases. 

So, what does all that have to do with the Equifax breach? The Equifax breach, in my opinion, dispels the notion that "speed" is the new security. The notion behind speed with respect to security is based on the concept that the environment is constantly changing, and that change can be effective in disrupting potential adversarial activity. Ideally, that's a great posture to be in for better cyber resiliency, but I don't think we are there yet or even have figured out how to incorporate that level of resiliency into continuous integration and delivery of software. A recent study from the DevOps Report concludes that only 27% of organizations surveyed have adopted DevOps practices.

People resist change. Consequently, people become the Achilles' heel in the software engineering process. Patching, for example, is one of those hygiene activities that is essential to preventing security breaches. Still, many organizations struggle to patch timely and consistently even in a DevOps environment for fear of the "unknown." Part of the unknown and resistance to change is rooted in the accumulation of technical debt that can grow to the point it become very expensive to pay it down. At some point, owing too much technical debt will impede an organization from doing essential things (like patching). But also, things like vulnerability coordination and disclosure across different suppliers and with key stakeholders can be challenging and time consuming. As a result, the window of exposure widens, and a breach is likely to happen.

All software has known and unknown attack surface areas (minus the zero day vulnerabilities) that are exploitable. The "known" attack surface areas are typically associated with things you can find in the National Vulnerability Database (NVD), and the "unknown" attack surface areas are typically associated with software weaknesses (also known as Common Weakness Enumerations — CWE) that could expose vulnerabilities in software. I tend to think of it as attack proneness and defect proneness. In modern software development, vulnerable software has a lot to do with what Brian Knapp, a software developer calls "software gravity. " He defines software gravity as the force that pulls features, complexity, and resources toward a software system over time.

The Equifax breach reminds me of the importance of making good design decisions, especially as it relates to component hygiene. Poor design decisions increase complexity and make it difficult to patch, and also introduce considerable amounts of technical debt. As indicated in the referenced Fortune article, third-party software like Apache Struts can be challenging to maintain and patch for several reasons: Struts libraries are bundled with disparate Web applications; fixing the issues requires, among other things, knowing which applications use the components (vulnerability prevalence); updating so-called build scripts so they fetch the latest versions of the software; and rebuilding the application and running quality assurance tests to make sure the mended application work as intended.

I would argue that the decision to use Apache Struts had just as much to do with the breach as failing to patch in a timely fashion. But both of these forces together are a recipe for disaster.

Author's Note: My affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE's concurrence with, or support for, the positions, opinions or viewpoints expressed in this column.

Related Content:

Kevin Greene is a thought leader in the area of software security assurance. He currently serves on the advisory board for New Jersey Institute of Technology (NJIT) Cybersecurity Research Center, and Bowie State University's Computer Science department. Kevin has been very ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-04-16
An attacker can place a crafted JSON config file into the project folder pointing to a custom executable. VScode-bazel allows the workspace path to lint *.bzl files to be set via this config file. As such the attacker is able to execute any executable on the system through vscode-bazel. We recommend...
PUBLISHED: 2021-04-16
The unofficial vscode-rpm-spec extension before 0.3.2 for Visual Studio Code allows remote code execution via a crafted workspace configuration.
PUBLISHED: 2021-04-16
Broken Authentication in Atlassian Connect Express (ACE) from version 3.0.2 before version 6.6.0: Atlassian Connect Express is a Node.js package for building Atlassian Connect apps. Authentication between Atlassian products and the Atlassian Connect Express app occurs with a server-to-server JWT or ...
PUBLISHED: 2021-04-16
Broken Authentication in Atlassian Connect Spring Boot (ACSB) from version 1.1.0 before version 2.1.3: Atlassian Connect Spring Boot is a Java Spring Boot package for building Atlassian Connect apps. Authentication between Atlassian products and the Atlassian Connect Spring Boot app occurs with a se...
PUBLISHED: 2021-04-16
A cross-site scripting (XSS) vulnerability has been reported to affect earlier versions of File Station. If exploited, this vulnerability allows remote attackers to inject malicious code. We have already fixed this vulnerability in the following versions: QTS build 20210202 (and later) QT...