The Apache Software Foundation may have just released new versions of its Struts web application framework, but looking back at what happened with past Struts flaws suggest security teams should prioritize applying the updates.
Attackers are highly motivated to develop a working exploit for Struts vulnerabilities as soon as possible because so many organizations rely on the open source Java framework for their publicly-accessible customer-facing web applications. A quick flashback: The Equifax breach, which exposed information belonging to 147 million consumers last year, was traced back to the fact that the credit rating agency’s servers had not been updated to address a critical Struts vulnerability(CVE-2017-5638) that had been fixed in March. The proof-of-concept code for that flaw appeared on a Chinese-language exploit site within 24 hours of the patch being available, according to Cisco Talos.
Patching is strongly recommended. Assess applications to understand potential exposure..
The critical vulnerability(CVE-2018-11776) in Struts 2 exists because user-provided input is insufficiently validated before it is evaluated, according to the advisory from security startup Semmle, which found and reported the flaw to the Apache Software Foundation back in April. While there are many potential avenues of attack, Semmle identified two in the advisory: if the alwaysSelectFullNamespace flag is set to true in the Struts configuration or if the application’s Struts configuration file contains an action that does not specify the optional namespace attribute, or specifies a wildcard (/*) Semmle said other attack vectors applying to different configurations may be found later.
If exploited on an affected Java application, the latest vulnerability would allow the attacker to execute malicious code and gain complete control over the server.
“Attackers can attack vulnerable applications by injecting their own namespace as a parameter in an HTTP request,” wrote Man Yue Mo, the security researcher at Semmle who found the vulnerability, noting that the value of that parameter was “insufficiently validated” by the framework, and could be any OGNL (Object-Graph Navigation Language) string. Attackers are familiar with the language, as it is used to customize Apache Struts’ behavior and has been used in exploits in the past.
Mo said the latest vulnerability was “more critical” than the critical bug fixed(CVE-2017-9805) last September. Exploit and proof-of-concept code for that bug was published a day later.
A working proof-of-concept is already available.
Exploit in the Works?
Recent research from Cyentia Institute and Kenna Security showed that just two percent of published vulnerabilities ever have active exploits in the wild. The majority of vulnerabilities never have exploits developed, let alone actively used in an attack. Half of the exploits were published within two weeks of the vulnerability being discovered, and 13 percent had exploits after 30 days.
History shows that attacker motivation (and expected payoff) is significantly high for Struts vulnerabilities.
VulnDB has rated the ‘Social Risk Score’ for this vulnerability as High, meaning that the “already strong social media presence discussing the vulnerability” puts the odds of active exploitation at “higher than average,” Risk Based Security wrote.
Exploits may become available soon simply because exploit developers may have had a head start working on the code. Semmle's Mo reported the flaw to the Apache Software Foundation in April, and the Struts development team released the code fixing the issue in June. It took the a bit longer than usual to prepare the official release, which is why there is a two month period between when the flaw was fixed and the software update became available.
It is of course in the nature of OSS [open source software] that commits happen in the public, and there is always a theoretical chance that the attack vectors might be reverse engineered from such information before a release can be issued,” said René Gielen vice president of Apache Struts Project Management Committee. “This is why we did and always push hard to get a quality tested release out the door soon after the commits, but technical issues prolonged this phase more than usual.
The issues were related to creating test builds for the 2.3 release line, which is guaranteed to run with Java 6, using then-publicly-available Java Development Kit editions, Gielen said. It took the team until Aug. 9 to successfully create test builds for both releases (Strut 2.3 and Struts 2.5).
While it is possible that exploit developers could have been working on exploits since June, that is no different than if attackers had already uncovered the problematic pattern where the vulnerability was and had kept the flaw a secret, said Tim Mackey, technology evangelist at Synopsys. The nature of open source means that any code changes, not just security fixes, are discoverable, so interested parties could already be analyzing commits for potential security impacts.
“Successful open source security management is an information flow exercise—you want to know when the risks are changing for your dependencies and then measure those risks against your security governance plan,” Mackey said.
The Struts security team and Semmle researchers worked together to analyze root causes and identify suitable mitigations. “A number of other places where security could and should be improved were found and addressed together with the attack vector in question,” Gielen said.
No More Struts?
This isn’t the first time critical vulnerabilities have been found in Struts, so it’s no surprise that there are calls to stop using Struts.
“My one takeaway, not a joke—stop using Apache Struts. 100% serious,” Habitu8 CEO and founder Chad Loder wrote on Twitter. He was basing his recommendation on “non-public details” he had about past high-profile security breaches over the last decade and a half.
Stopping using Struts isn’t something an organization can do quickly, or while responding to a public advisory about a critical vulnerability. Migrating applications Struts requires careful planning and work as it would potentially require changes to the architecture or rewriting the application. In some cases, the changes to the codebase may be extensive enough to require modifying the application’s information flow and business logic.
It’s one thing to decide that all new projects should be based on a different framework instead of Struts. That could mean running different technology stacks in order to support legacy Struts and newer applications, whether they are using Spring MVC or a new combination of languages and frameworks, such as Go and AngularJS. Migrating existing applications would require rewriting the application. Refactoring isn’t an option because the entire framework is being replaced.
The first step would be to analyze the codebase to assess the current exposure to Struts and understand the level of rewriting that would be required. The new technology stack may require switching the database layer, which would require updated queries and schema references. Depending on the level of changes required, it may make sense to consider newer architecture elements such as using micro services, upgrading messaging services, and using newer search engines. Testing the changes will also be a huge part of the migration.
Assessing the codebase will also help with incident response, which is critical and needs to be ongoing. The assessment will clearly identify which versions of Struts are used in which surface areas. “When new vulnerabilities come out, you can quickly put together a response plan,” Loder said.