About CVE-2014-0094 and Struts 1 Countermeasures

Introduction

This article summarizes the impact of CVE-2014-0094 on Struts 1.
Unless otherwise noted, all versions were verified using Java 1.7.0_02, Struts 1.3.10, Apache Tomcat 6.0.39, and FreeBSD 8.2.

In no event shall we be liable for the content of the source code, text, etc.
Also, I shall not be involved in any incidents that occur. In particular, I take no responsibility for misuse of this content. (Though there is nothing new to report.)

I have presented concrete examples of solutions based on various web references.
Except for known facts, I have cited the URLs referenced in the sources.
I am grateful to those who made this information public.

I have tried to avoid technical jargon where possible and use plain language, even if it may be somewhat misleading.

The vulnerability in Struts 1 appears to be referred to as CVE-2014-0094, S2-020, etc., though the naming is not entirely clear. For now, I will call it CVE-2014-0094.

Background

Needless to say, CVE-2014-0094 is a very serious issue.

http://www.nta.go.jp/sonota/sonota/osirase/service.htm

According to "Notice of Service Suspension (Important) – e-Tax Software (WEB version), Tax Return Preparation Corner, NISA (Japan-version ISA) Corner – April 25, 2014", the National Tax Agency's web service used Struts 1 and suspended the service on the same day the vulnerability was discovered.

It is believed that the service was immediately halted to minimize damage.

When we conducted a proof-of-concept test,
we confirmed that simply accessing a URL could cause service disruption and leakage of arbitrary files.

Simply by accessing a URL, it is easy to carry out an attack—for example, sending an email with a URL to a mailing list from an anonymous email address makes it difficult to identify the attacker, and the service can be easily halted.

This is truly a trivial attack to perform.

First Step: Stop the System

This is the most important step. If a third-party organization announces that there may be an impact, the proper approach is to stop the system first to prevent further damage. Even if later investigation shows no actual impact, leaked information cannot be recovered. Naturally, this requires a political decision. For companies, this tests ethics, everyday awareness of issues, risk management, and so on.

Investigate What Kind of Attack is Possible

This problem arises because some configuration values held by the system can be partially overwritten.
It is necessary to investigate which configuration values can be overwritten.
Depending on those values, the possible attacks differ.

These configuration values vary by Servlet container.
In Tomcat 6, arbitrary code execution is likely impossible, but in Tomcat 8, arbitrary execution is possible.
In other environments such as Jetty or WebSphere Application Server, it is necessary to verify which configuration values exist.

In Tomcat 6, it is said that 23 such values can be modified.
If class.classLoader.resources.dirContext.docBase is changed, normal system operation becomes impossible, and instead of displaying JSPs, any file on the server can be retrieved (leaked) by specifying that file.

In Tomcat 8, arbitrary code can be executed,
because the number of configurable values has increased compared to Tomcat 6.
If the Servlet container in use does not have those configurable values, there is likely little issue at present.

Check for Signs of Attack

The modification of configuration values can be done not only by including the string in the URL, but also as a hidden field in a normal request or by including the value in a cookie.
From access logs alone, it is impossible to detect modifications made via hidden fields.

There are often cases where the system is restarted late on Sunday nights.
If an attacker rewrites docBase and retrieves files shortly before that restart, the system administrator may not notice the anomaly because the restart occurs soon after.
If there are many 404 or 500 status errors during that time window, it is highly likely that some files have been leaked.

Countermeasures

Struts 1 has reached end-of-life (setting aside the question of what open-source support means), and no security patches are released.
You must resolve the issue yourself.

The root cause lies in BeanUtils; you need to implement a mechanism to ignore inappropriate strings.
BeanUtils is a tool that modifies object property values (this is a very simplified explanation).

Example implementation:

  com.haselab.struts.filter
  web.xml

Brief explanation:
In web.xml, a program that changes the behavior of BeanUtils at system startup is invoked.
SafeResolverListener.java is called, and SafeResolver.java will subsequently be used by BeanUtils.
In SafeResolver.java, if the string being parsed is 'classLoader' (case-insensitive), it returns "".
This prevents any arbitrary value from being set to classLoader.
This behavior is based on:

 https://gist.github.com/nakamura-to/11347570

(It’s a short program, so it is used as-is.)

If your application needs to change a setting named 'classLoader', this method cannot be used because it prevents that setting.
However, in general, it is unlikely that a property would be named 'classLoader', so this should not be a problem.
If you are concerned, you can search all application source code with:

grep -r -i classLoader *

to confirm that no such property exists.

Verification Details

We verified the rewriting of docBase. After deploying with Maven, please view the Struts directory in your browser.
Each button press rewrites docBase and displays the /etc/passwd file.