Vulnerabilities / Threats

6/6/2018
10:30 AM
Kevin E. Greene
Kevin E. Greene
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

'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 2.2.3.1 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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Microsoft Fixes 11 Critical, 39 Important Vulns
Kelly Sheridan, Staff Editor, Dark Reading,  6/12/2018
Why CISOs Need a Security Reality Check
Joel Fulton, Chief Information Security Officer for Splunk,  6/13/2018
Cisco Talos Summit: Network Defenders Not Serious Enough About Attacks
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/13/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-12580
PUBLISHED: 2018-06-19
library/DBTech/Security/Action/Sessions.php in DragonByte vBSecurity 3.x through 3.3.0 for vBulletin 3 and vBulletin 4 allows self-XSS via $session['user_agent'] in the "Login Sessions" feature.
CVE-2018-12578
PUBLISHED: 2018-06-19
There is a heap-based buffer overflow in bmp_compress1_row in appliers.cpp in sam2p 0.49.4 that leads to a denial of service or possibly unspecified other impact.
CVE-2018-1061
PUBLISHED: 2018-06-19
python before versions 2.7.15, 3.4.9, 3.5.6 and 3.7.0 is vulnerable to catastrophic backtracking in the difflib.IS_LINE_JUNK method. An attacker could use this flaw to cause denial of service.
CVE-2018-1073
PUBLISHED: 2018-06-19
The web console login form in ovirt-engine before version 4.2.3 returned different errors for non-existent users and invalid passwords, allowing an attacker to discover the names of valid user accounts.
CVE-2018-12557
PUBLISHED: 2018-06-19
An issue was discovered in Zuul 3.x before 3.1.0. If nodes become offline during the build, the no_log attribute of a task is ignored. If the unreachable error occurred in a task used with a loop variable (e.g., with_items), the contents of the loop items would be printed in the console. This could ...