Equifax Breach Year in Review: Vulnerabilities in Apache Struts Still Going Strong
You would think it hard to believe, but the vulnerable version of the popular open source framework that cost 147.9 Americans their personally identifiable information (PII) in the Equifax breach last fall, is still going unrepaired by most companies using the vulnerable versions of Struts. Despite the Apache Foundation issuing fixes as early as March of 2017, and six times subsequently throughout the past year, companies are in no rush to patch the vulnerability, including Fortune 100 enterprises and companies in the finance, banking and insurance spaces notorious for holding the most sensitive of data and the type that hackers are most eager to get to.
A recent Mend survey shows that only 54 percent of developers will remediate a vulnerability immediately once detected in their system, suggesting that nearly half of those that detect vulnerabilities remain slow to take action in the race against hackers. One year post Equifax, many of those affected by the Struts 2 vulnerability left it unfixed allowing themselves to be exposed to exploitation attempts. Hackers, for their part, have not ceased attempting to exploit the Struts 2 vulnerability and still aim to capitalize on the many companies who have yet to remediate.
Knowing What’s In Your Code is Still Not a Given
The Apache Foundation published the Struts 2 vulnerability under the identification CVE-2017-5638 in March 2017. At that time, companies like Equifax should have checked for the presence of the vulnerability in their codebase. Only that in order to check for the vulnerable version, Equifax and tens of thousands of other companies using the Struts 2 framework would have needed to know that they were using that component. They would have needed to know of its existence in their product.
The problem starts here and it is as prevalent today as it was in September of last year. Due to the nature of programming and the lack, still, in many companies of a centralized security protocol that helps developers choose open source components, setting predefined parameters that keep vulnerable components out of their reach that also continuously notifies in real time of the presence of vulnerable components once already in the code, organizations simply don’t know what makes up their product.
Had Equifax executives known that their developers were using Apache Struts, they would have likely asked that the code be checked for the vulnerable version once it was made public in March 2017. More realistically than executives having the bandwidth to deal with vulnerability management, had there been an automated system in place that offered a breakdown of the company’s open source usage, which was also hooked up to the National Vulnerability Database (NVD) and other industry issue trackers, then those in the company that needed to know would have been alerted of the Struts vulnerability in March of 2017 and would have likewise known of its presence in their codebase.
Lack of knowledge led to a lack of action which led to Equifax’s database being exposed to hackers, which five months later led to the company’s public announcement that it had been compromised.
Remediation is Still More Feared than an Exploit
More perplexing than even the continued non-fixing of the vulnerable Struts versions, are indicators that despite a repaired version of Struts 2 being available, companies continue to download the vulnerable versions in 2018. Indeed, the Apache Foundation itself continues to allow users to download legacy versions of the software, even though they contain known security vulnerabilities.
With few organizations startled into action by Equifax’s misfortune, and thousands of businesses downloading the vulnerable Struts versions (2.2.3 through 2.2.3.31, and 2.5 through 2.5.10) in the past year alone, there is something to be said for the presumed sense of safety users gain from downloading popular open source components.
Asked about the aftermath of the Equifax case, author and prominent Security Boulevard contributor, Dan Rheault, concluded in May of this year that “the intentional introduction of vulnerable software indicates that organizations will favor ensured continuity in application and network connectivity over security.”
Component popularity based on number of downloads and word-of-mouth praise within the community is a prime determinate in whether a developer will pull a component or not. Also figuring into this logic is developers’ past experience. With heavy reliance on open source, most developers have already used the popular components in the past. They are more likely to reuse components they have used in the past than try their hand at something new. It’s a matter of habit and a tried and true policy. Until a company becomes affected by a flawed component, the risk remains in the realm of myth not worth the time and effort put into trying out a new, vulnerability free, component.
A 2014 study lead by Dr. Anthony Vance focused on behavioral application security shows that as time goes by and a security event recedes in public interest it is perceived by onlooking companies to be less of a potent threat. If a security vulnerability was not treated in the weeks and months following a breach, it is less likely to get fixed further down the line. Until another security event occurs which brings it back into focus and the cycle begins anew.
Remediation costs can be quantified while the damage of a potential exploit cannot be assumed in advance. In pure economic logic, this creates an equation with a numeric value on one side and a big question mark on the other. The price of remediation offsets the blank variable symbolizing the price of an attack, making the cost of remediation feel greater than it is.
A ‘How Badly Do I Need It’ Mentality
When you take into account the price of halting operation to remediate or update a version, the development hours and the manpower that it requires, when you attempt to quantify the price of rollbacks and downtime, the sheer magnitude of remediation comes into focus.
Upgrading software can also lead to a new set of bugs which then increase the workload in attending to them. And while it is common to equate newer with better, oftentimes newer means having to get familiar with new features and interfaces. These alone generate a sense of panic about remediation that drowns out the potential threat associated with not fixing a known vulnerability.
And beyond the hurdles that come with remediation, developers will have additional reasons to favor old vulnerable versions over new patched ones. “Developers will have a number of reasons for downloading older versions of Apache Struts” says Mark Cox of the Apache Software Foundation. These reasons include the need to reproduce running environments, treat older versions and diagnose regressions.
According to a Mend study, the more experienced a developer is the more likely he is to remediate a vulnerability immediately and the more likely he is to research for possible fixes on his own. These findings lead to the conclusion that experience builds confidence to play around with the system, ‘touch’ the code as it were, and run the risk of offsetting other issues in the process. It also teaches that experience breeds the sense of urgency needed to attend to a vulnerability in a timely manner, and an understanding that once a vulnerability is made public its potential for destruction skyrockets.
Since experience is accumulated over time and with it the confidence to remediate, the only other way to ensure that all developers in an organization, from junior to senior, become minded towards fixing vulnerabilities and forego their fear of remediating, is for organizations to instill a culture of vulnerability management. To compliment this culture, companies will introduce automated SCA tools (software composition analysis) as a means to alleviate the pitfalls of bug fixing, thereby setting new developers as well as seasoned ones down the right path.
Looking to the Future
If the latest Apache Struts vulnerability discovered August 22 is any indication of things to come, it is clear that remote access vulnerabilities of the kind that caused the Equifax breach remain an ongoing threat and companies cannot afford to maintain current levels of complacency and inaction.
If anything, vulnerabilities are getting more aggressive and the extent of the havoc they can wreak seems to grow with every new critical bug that gets disclosed. The latest Struts vulnerability under the identification CVE-2018-11776, for instance, can be triggered just by visiting a specific URL on the affected web server, allowing attackers to execute malicious code and eventually take complete control of the targeted server running the vulnerable application.
It comes down to organizations adopting continuous open source management in a way that effectively detects, tracks and remediates vulnerabilities. The fear of things going wrong as a result of the remediation process is not a good enough reason to turn a blind eye and a deaf ear to known vulnerabilities which hackers are on the lookout for and will exploit at great costs to their victims.
