This week we saw the announcement of yet another Struts 2 Remote Code Exploit (RCE) vulnerability. What's notable about this instance is that POC code seems to have been released into the wild either just before, or immediately after the disclosure. As was the case with previous Struts1 vulnerabilities, exploits are being observed at large scale in the wild.
Whenever critical vulnerabilities emerge, attackers have first mover advantage. Therefore, the only thing that matters is speed.
How long before you even become aware?
How long does it take you to assess your exposure?
How quickly can you remediate the vulnerability?
In today's world, different companies utilize different tools and processes to manage open source governance and security risk within the software development lifecycle. Forward leaning organizations empowered with DevOps-native intelligence will respond in hours or days. Traditional organizations equipped with waterfall-native intelligence will struggle to respond in weeks or months.
It's now been 3 days since the Struts2 fix and disclosure. Here's the official description available from the Mitre database as of Friday, March 10th:
Meanwhile, over at NVD, the situation is essentially the same:
This type of delay is common because the process requires a project to request an ID for a new vulnerability, but the details aren't publicized until days or weeks later, and sometimes, public data sources like Mitre and NVD are stuck in neutral forever.
They say, "seeing is believing." So go ahead and check right now. See if your open source and application security tools (free or paid) are providing intelligence yet with respect to this new Struts2 vulnerability. More than likely you will find that your tools are out of date, your intelligence is lagging, and your risk is skyrocketing.
Fortunately for you, there's a better way to stay up to speed.
For years Sonatype has automated the detection of policy violations based on attributes such as quality, license and security information. Along the way, we’ve discovered a lot of vulnerability disclosures to be lacking, not only in timeliness, but also in content and precision. Many people assume that NVD (the National Vulnerability Database) is a curated repository of information. Truth be told, it’s not. The actual content of the disclosure is written by the project team that requested the id in the first place, many of which are not experienced application security practitioners.
As with anything in life and software, there are a few outstanding examples of well written disclosures, and then there's everything else. Sometimes you will find descriptions written for ops teams or security specialists but not for the rest of us who write or manage software. (Did you know what a Bleichenbacher attack is and why it's really scary?) Sometimes the disclosures focus on a whole third-application but neglect to name the actual root cause that exists in a party library. You might be using that very same library completely unaware that you are actually vulnerable.
On top of the content issues, the data itself is not automatable without lots of potential false positives. You need precise matching of your libraries against the affected versions in the disclosure in order to rapidly send alert emails or take automatic action to stop further damage without causing wasted effort caused by false alarms.
All of this is a long way of saying that not all data is created equal. The Sonatype data services team is the best in the world. They research, review, and curate issues in real time, not after the fact. They also provide easy-to-understand remediation guidance and actionable intelligence so developers can answer the following questions:
What does this CVE mean to me?
How do I know I’m vulnerable?
How do I fix it?
Why is this showing up in my scan?
Is there a known attack?
All of this is then immediately pushed out to our customers where their policy uses the data to determine how to respond. The default configuration would cause alerts to go out for anything we've previously analyzed that is affected. It will also show up in a developer's IDEs, CI builds, deployment dashboards and, if desired, block attempts to promote builds, releases or deployments until it's fixed.
Additionally, the Sonatype IQ Server dashboard will indicate every application in their portfolio that has this problem so immediate remediation efforts can be targeted at the highest risk applications. While other people are somewhere between completely unaware or scrambling to determine if and where they are affected, our users are already triaging and remediating.
Given the active exploit nature of this vulnerability, I'm going to share the enhanced data so that everyone can act upon it and compare it to their own tools:
Issue
CVE-2017-5638
Severity
Sonatype CVSS 3.0: 9.8
The struts2-core component is vulnerable to Remote Code Execution (RCE) when using the Jakarta Multipart parser. When Struts receives a request that causes an error message that doesn't have an existing error key, it will throw an exception that is displayed to the user. The Content-Type header of the request is used in this process in such a way that allows injected code to be executed. An attacker can exploit this vulnerability by sending a request with an invalid Content-Type header that contains malicious code that will be executed by Struts.
The vulnerable functionality is found in the buildErrorMessage function in JakartaStreamMultiPartRequest.java, MultiPartRequestWrapper.java, and JakartaMultiPartRequest.java in the 2.3.X versions and 2.5.X prior to 2.5.8. As of 2.5.8, the vulnerable functionality is found in the `intercept` function found in FileUploadInterceptor.java.
Detection
The application is vulnerable by using this component with the Jakarta Multipart parser.
We recommend upgrading to a version of this component that is not vulnerable to this specific issue. Alternatively, change Strut's Multipart parser to something other than Jakarta.
Other implementations can be found here: https://cwiki.apache.org/confluence/display/WW/File+Upload#FileUpload-AlternateLibraries
If neither of these are viable options, one could also filter the Content-Type header for unexpected values that do match multipart/form-data before it is received by the Struts application.
Sonatype Categories
Data
Configuration
Third Party: http://blog.talosintelligence.com/2017/03/apache-0-day-exploited.html?m=1
Attack: https://github.com/rapid7/metasploit-framework/issues/8064
Project: https://struts.apache.org/docs/s2-045.html
Run our free Application Health Check to see if your application is affected. Then get one of our Sonatype solutions so you are among the first to know the next time a critical vulnerability is discovered.