An Apache Struts Vulnerability You Really Need to Fix
Table of Contents
Another open source security vulnerability was discovered in a popular open source project. This time its Apache Struts 2 and this is yet another Remote Code Execution (RCE) vulnerability that adds up to a long list of severe vulnerabilities in Apache Struts.
What makes things worse, is that this Apache Struts vulnerability has been actively exploited in the wild since before it was formally released.
Unfortunately, even after the CVE was released with a fix, there have been many victims. So far two Canadian government agencies have reported they were attacked and evidence gathered show us they are not alone. As usual in these cases, we will know the total impact only a few months from now, but what should you do today?
About Apache Struts 2
Apache Struts 2 is an open-source web application framework for developing Java EE web applications. It uses and extends the Java Servlet API to encourage developers to adopt a model view controller (MVC) architecture. The WebWork framework spun off from Apache Struts aiming to offer enhancements and refinements while retaining the same general architecture of the original Struts framework.
In the past 6 years, 71 security vulnerabilities were discovered in Apache Struts projects. Even though all vulnerabilities have been mitigated through patches or new versions, hackers still constantly exploit these vulnerabilities to launch attacks as companies’ response time to open source vulnerabilities is extremely slow. Just take into consideration that even 3 years after Heartbleed, the most notorious open source vulnerability out there, was released, nearly 200,000 online services are still vulnerable to it. Just imagine how many companies are using those vulnerable Apache Struts versions without eve knowing about the risk they are putting their software to.
The most commonly exploited Apache Struts vulnerabilities are known as Remote Code Execution (RCE), which allow the attacker to take over the server by running arbitrary malicious code.
What happened this time?
On March 6th, a new remote code execution (RCE) vulnerability was announced in Apache Struts 2 by publishing a new vulnerability (CVE-2017-5638). However, only the CVE number was announced and it was under ‘reserved’ status with no other information until March 10th, when full exploitation and remediation information were made public.
Although data was not made public until March 10th, an official first exploitation was made a day after the vulnerability was announced and by March 14th multiple attacks were reported from over 1,500 IP addresses from over 40 countries (almost 70% originated from China).
The recommended fix is to upgrade your Apache Struts versions. The vulnerable versions of Struts 2.3 to 2.3.31 should be upgraded to Struts 2.3.32 and Struts 2.5 to Struts 2.5.10 should be upgraded to Struts 2.5.10.1. VMWare, Huawei, Cisco and Atlassian have already issued an alert regarding their vulnerable product versions as a result from this CVE. Considering the fact that 2.3.1 was released in December 2011, there are millions of users worldwide that are probably unaware they are using this component or unaware that it’s vulnerable.
Furthermore, although a fix was released on March 10th, all evidence shows that the vulnerability is still exploited in the wild. The Government of Canada confirmed on March 13th that some of its servers were breached by attackers making use of the Apache Struts flaw.
How does CVE-2017-5638 work?
According to Apache, the vulnerability exists in the Jakarta Multipart parser. When an invalid value is placed in the Content-Type header, an exception is thrown. The exception is used to display the error to the user. An attacker can exploit this vulnerability to escape the data scope into the execution scope through the Content-Type header.
The Content-Type header field is used to specify the format of information being sent so that the receiving application will know how to handle it. In HTTP requests, the “Unauthorized Request Content-Type” rule is triggered when either the Content-Type cannot be correctly established according to the RFC or when the Content-Type is identified as an unauthorized type.
What’s the lesson?
The lesson here is definitely not that open source components are not safe. Our regular readers know very well that we believe open source is as safe, if not more, compared to proprietary code.
What companies should understand is that nowadays, when their in-house code accounts for only 10% to 20% of their products, identifying whether they have known security vulnerabilities in their open source components should be done through automated tools.
This case is no different than many other open source vulnerabilities that are discovered on a regular basis. However, unlike many other open source vulnerabilities, this bug has gotten a lot of publicity and therefore alerted many security and software development teams to check if they are using the vulnerable versions. But what about the many other exploitable vulnerabilities in open source components that you are not aware of?
Mend.io customers were alerted a few hours after the details and remediation of the CVE were made public and could proactively protect their software from possible attacks.
