New vulnerability discovered in Apache Struts threatens remote code execution
Just in time for the one year anniversary of the now famous Equifax hack of 2017, security researchers have announced a new remote execution exploit in Apache Struts 2 that has developers across the world scrambling to patch lest they find themselves victim to the next headline-busting data breach.
As one of the most popular open source frameworks used for helping developers build web applications such as public facing web portals, vulnerabilities in Apache Struts projects can have wide-reaching effects and significant impact on its users.
According to the reports, this latest vulnerability, listed as CVE-2018-11776, was uncovered by Semmle Security’s researcher Man Yue Mo back in April of this year and was passed on to the Apache team for analysis and work on creating a patch.
The Nitty Gritty — What you need to know about this CVE
In the alert that was posted on August 22, researchers warn of a “Possible Remote Code Execution when using results with no namespace and in same time, its upper action(s) have no or wildcard namespace,” noting that there is the same possibility, “When using url tag which doesn’t have value and action set.”
The team notes that this affects all users and developers of Apache Struts 2, which according to some estimations equals some 65% of Fortune 100 companies, and surely thousands more.
While still awaiting a full report by analysts to be posted on the National Vulnerability Database, this vulnerability is considered Critical. There are legitimate concerns that this flaw in the code could be utilized by attackers to easily break into servers and manipulate the data there. Hackers may choose to add or delete information in these systems for possible financial gain, or steal the information like personally identifiable information such as birth dates, addresses, social security numbers, and even credit card numbers for sale to fraudsters.
Thankfully, a fix has already been developed and can be applied by upgrading to either Struts version 2.3.35 or 2.5.17. The hope here is that, in the aftermath of the Equifax hack, we will see more organizations making moves to patch their systems, an aspiration that may be a bridge too far as many companies are believed to have not yet patched the 2017 vulnerability.
To understand how such a critical threat to an organization’s data can go unaddressed, we need to look at why open source security is a different game than protecting commercial or proprietary code.
Open source vulnerabilities — A force multiplier for hackers
Open source vulnerabilities have long been a favorite among hackers since a single exploit in a popular project can lead to thousands of breaches. This is because open source components are reusable components that help developers add powerful features to their products without having to write new code from scratch.
Adding to the risk is that when an open source component is found to have a vulnerability, all the information about what is vulnerable and how to exploit it is posted on a wide range of databases and security advisories with the goal that it will help get the word out to developers that they need to remediate an issue in their products.
In practice though, this process has its own problems built in. First, hackers are also watching these security resources, and basically receiving intelligence on what and how to hack. If we take the example of the Apache Struts vulnerability, it is now public knowledge that the component is exploitable, and the race is on between the red and blue teams, with hackers hoping that they can pop some shells before the defenders realize that they have to patch.
This leads us to our second difficulty for security teams, knowing that they are vulnerable.
Knowing what you have — Why tracking your open source usage is so critical
Developers will go to resources like GitHub or Maven Central to pull open source components that solve the issues they are facing in their code. This is a good practice and helps to speed up production to meet those tight deadlines.
The problem is that they are often not keeping track of what they have in their development environment or products. During development, this can prove costly if they include an open source component with a known vulnerability. Security testing tools like SAST only check proprietary code, so open source vulnerabilities are likely to get past these tests.
Assuming however that there was a process to ensure that no components with known vulnerabilities made it into the development of the product, there is still a risk that new vulnerabilities can be discovered and exploited post-deployment.
If we look back at the 2017 Equifax hack, the vulnerability that was exploited to perform the breach was uncovered in their deployed customer web portal. By all accounts, the failure to patch came as a result of the company being unaware that they were using the vulnerable version of Apache Struts 2 in that product, so the warnings of a newly discovered exploit went unaddressed.
Just a little bit of history repeating?
With the announcement of the vulnerability just having been made last week, it is still too early to guess what the impact will be on organizations using the vulnerable version of Apache Struts.
Before running for our fallout shelters, it is worth taking a little bit of perspective. First off, as noted in the alert, this vulnerability requires a certain (yet not altogether uncommon) configuration in order for it to be exploited. This means that not everyone using the vulnerable version of the framework is about to have their systems broken into. That’s the good news.
The question though will be to see if the industry has gotten any wiser, learning the lessons of the last hack. With word of a new Apache Struts vulnerability going around, will security teams make a point of looking to see if they are using those versions, hoping not to be the next Equifax?
Possibly, but I doubt that everyone will and some unlucky companies will get breached. Developers know that they need to upgrade when new versions are released, but in practice, this does not happen as often as it should since it can mean hours of added configurations and sorting out unintended changes to the product from the new version.
Even if the extra effort is made to catch this high profile vulnerability, what should security and developers be doing to prevent the next exploit that we have not yet heard about? Sometimes history can repeat itself with an unaddressed exploit coming back to bite you, and other times it rhymes with similar mistakes.
Hopefully, these high profile cases will push the development community to adopt better practices across the board. Only time will tell.