New Apache Struts 2 zero-day vulnerability: What you need to know

Mar 09, 2017 / 3 min read

Table of Contents

What’s the story behind the Struts 2 zero-day?
What’s the impact of the Struts 2 zero-day?
What is remote code execution?
How do you determine if you’re using Struts 2?
How do you mitigate the Struts 2 issue?
How can you prevent this and similar future security vulnerabilities?

It has been more than 48 hours since this attack was made public. At this time, hackers are actively exploiting the critical vulnerability and are able to take complete control of web servers. Several sources have been discussing details for exploiting this vulnerability.

Rather than focusing on how to exploit it here, we will ensure that you are able to find out whether you are using vulnerable versions and how to prevent this vulnerability in the future.

What’s the story behind the Struts 2 zero-day?

The critical bug CVE-2017-5638 is clearly documented in the Metasploit Framework on their GitHub site. The bug is also very easy to exploit. It requires no authentication in the Apache Struts 2 web application framework. The bug appears within the upload function of the Jakarta Multipart parser.

The affected Struts 2 versions are Struts 2.3.5 to 2.3.31, in addition to Struts 2.5 to 2.5.10.

Nike Zheng posted a PoC showing how easy it was to inject operating system commands using Apache Struts 2.

Struts 2.5.10.1 was released on March 7 with a patch for this exact same issue.

What’s the impact of the Struts 2 zero-day?

The Apache Struts release page mentions this as a potential security vulnerability. It also mentions the possibility of remote code execution when performing file uploads based on Jakarta Multipart parser – S2-045. This may have been misleading to many companies.

Even if your application has no file upload functionality, hackers can still exploit the bug, which is troublesome. The security rating given is ‘High.’ However, since the attack requires no authentication or even the file upload functionality to be implemented in an application, it should have been classified as a ‘Critical’ bug.

What is remote code execution?

A remote code execution (RCE) vulnerability may give an attacker the possibility to execute arbitrary code on the affected system. Thus, compromising the vulnerable application server. An attacker can use this to gain an initial foothold on the system after which an attacker usually tries to gain more privileges and install backdoors for future use. RCE vulnerabilities can also be used for denial of service and information leakage, and in the case of the Struts 2 vulnerability, it’s able to turn off the firewall on application servers and execute malicious payloads.

The impact of a well-executed remote code execution is devastating, as we’ve seen with the Struts 2 vulnerability in the past 48 hours. It gives an attacker the possibility to copy files and execute the files on the affected host. This can later disable the firewall when the system boots.

How do you determine if you’re using Struts 2?

If you already have a solid open source management system and have automated the solution, it should be trivial to find out if you are using the affected versions.

If not, look at the inventory of all the open source software your organization is using. Run scans using software composition analysis (SCA) tools such as Black Duck to identify the Struts version you are using.

How do you mitigate the Struts 2 issue?

If you determine that you are using the vulnerable versions Struts 2.3.5 – 2.3.31 and Struts 2.5 – 2.5.10, upgrade to Apache Struts version 2.3.32 or 2.5.10.1.

Most component projects do not create vulnerability patches for old versions. Instead, most simply fix the problem in the next version like Apache Struts did. Upgrading to these new versions 2.3.32 or 2.5.10.1 is critical.

Since there is no backward compatibility issue, upgrading the version should be fairly trivial.

How can you prevent this and similar future security vulnerabilities?

Unpatched system software is a huge problem that is compounded by the fact that an attacker can easily figure out which version of the software your system is running. Once this information is pieced together, they simply look up published vulnerabilities that apply to your system.

Here are some key points to remember to make sure open source software in use within your firm is secure:

Identify all components and the versions you are using. This includes all dependencies. (e.g., the version plugins).
Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up to date. There are several resources online that list known vulnerabilities for different components. Some of the most well-known vulnerability databases are the National Vulnerability Database (NVD), and Open Source Vulnerability Database (OSVDB). These will often quickly show you if there are any known vulnerabilities in specific components.
Establish security policies governing component use. These include requiring certain software development practices, passing security tests, and acceptable licenses. Restrict the use of unapproved libraries.
Where appropriate, consider adding security wrappers around components to disable unused functionality and/or secure weak or vulnerable aspects of the component.
Integrate SCA tools to identify vulnerable components.
Automate SCA tools in your continuous integration and continuous delivery/deployment pipelines.
Break the builds when you find critical or high vulnerabilities in these open source components.