Apache Struts, RCEs, and the Equifax Breach Anniversary

We just passed the one-year anniversary of Equifax’s announcement of their massive data breach due to an exploit of an Apache Struts vulnerability (CVE-2017-5638) – and incidentally, at nearly the same time that Apache announced another critical Apache Struts security flaw (). The latest Apache Struts vulnerability, CVE-2018-11776, was published in NVD on August 22, although it’s still awaiting analysis.

A Partial History of Apache Struts Remote Code Execution Vulnerabilities

All three of these vulnerabilities can lead to Remote Code Execution, which is an attacker’s ability to access another computing device and make changes, regardless of where that device is located.

• CVE-2018-11776: discovered by researchers and published in NVD this August, this vulnerability is caused by insufficient validation of untrusted user data in the core Struts framework. Considered more critical than the vulnerability exploited in the Equifax breach, this bug has multiple attack vectors that threat actors could use to exploit the vulnerability.
• CVE-2017-9805: Man Yue Mo disclosed details of the severe Remote Code Execution vulnerability in early September 2017, which had multiple working exploits available on the internet almost immediately after it was publicly announced. This vulnerability was the result of unsafe deserialization in Java.
• CVE-2017-5638: This famous vulnerability was exploited to steal 145M+ people’s data from Equifax in September 2017. The vulnerability itself, however, was disclosed in early March 2017. In this case, it’s possible to perform an RCE attack by sending malicious code in the Content-Type header. Exploits for this vulnerability were quickly and readily available in the wild as well.

None of this is a criticism of The Apache Software Foundation (ASF), or the Apache Struts framework, however. The ASF’s commitment to open source and the collaborative development model it provides has produced many high quality projects that are used across the software ecosystem today. Chances are you’re using an ASF project – they list more than 350 open source projects and initiatives! More to the point, all software – open source and closed source code alike – contains flaws and weaknesses.

Open Source Is Essential to Building Software

GitLab’s 2018 Global Developer Survey makes it clear that open source is essential to building software. In fact, 92% of survey respondents indicated that open source tools are important to software innovation. One responded indicated: “As a developer I find using open source to be critical to the overall quality of software for everyone.” With so many developers building applications using open source it’s essential to integrate software composition analysis into your build environment and automatically enforce open source analysis as part of your SDLC. This visibility into your code base, including open source code components and the version deployed in your environment, will help your team ensure that vulnerable components are not part of your portfolio. Even better, when new vulnerabilities are disclosed, you’ll be able to remediate them rapidly, before they become a problem and expose your software and your organization to risks such as a data breach.

Securing Open and Closed Source Code

The Apache Struts Project Management Committee released a statement regarding the Equifax breach that includes several critical suggestions for securing any open or closed source code that supports libraries in software products and services, which I’ll summarize here:

1. Understand which supporting frameworks and libraries are used in your software products and which versions. Keep track of security announcements affecting any open source or third-party code in your applications.
2. Establish a process to roll out a security fix release of your software product rapidly. By rapidly, plan to release a fix in a few hours or a few days, not weeks or months. Most breaches are caused by failure to update software component, despite being a known disclosed vulnerability and an available patch – some of which have been available for months or even years.
3. Any software contains flaws. Don’t build a security policy assuming that the software components you’re using are flawless, particularly when it comes security vulnerabilities.
4. Establish security layers. It is good software engineering practice to have individually secured layers behind a public-facing presentation layer (such as the Apache Struts framework). A breach into one layer should not empower access to significant or even all back-end information resources.
5. Institute monitoring for unexpected or odd access patterns to your public Web resources. Monitoring is a good operations practice for business-critical Web-based services.

The Responsibility to Secure Software

These recommendations cover many of the responsibilities organizations have regarding the software they build, but they’re easier said than done. The problem lies in the difficulty organizations face as they try to keep up with increased software complexity and rapid release cycles. Managing the risks created is critical, and it goes beyond application security. To accurately understand and reduce business risk, organizations today need to understand and manage their software exposure holistically. To do that, you need full visibility into the composition of your software, regardless of whether it’s comprised of open source code, custom code, or a combination. Visibility alone isn’t enough, however. Security testing throughout the SLDC and developer training are necessary to continuously support all stages of the DevOps cycle.

Learn more about the Checkmarx Software Exposure Platform