Apache Struts research at scale, Part 2: Execution environments

Our initial environment

We started with a quick and dirty approach for running our different versions of Struts. We had set up a basic Tomcat installation on Ubuntu 18 LTS using the system’s provided Tomcat 8 and Java 8 packages. Java 8 was capable of compiling for 1.5, our starting point. And Tomcat 8 was known to be backward compatible back to the 1996 Java servlet 1.0 specification, which was far older than what we expected from the Struts 2 WAR files. Also, it was modern enough that in theory, many later versions of Struts could run in the same instance.

Surprisingly, it’s quick and trivial to set this up on Ubuntu 18. It requires only a few chained commands, and within a few minutes, you’ll have our initial configuration running:

Creation and reproduction of exploits

When reproducing exploits, or creating new exploits based on known information, we ran into a variety of barriers, which we will detail below.

Tomcat

S2-021
 

This vulnerability allows a denial-of-service (DoS) via an insufficient ban in CookieInterceptor leading to ClassLoader manipulation.

When we started sending payloads to the server, we noticed with remote debugging that the payload was not triggering anything. When we looked closer for the payload’s existence, we couldn’t find it at all in our remote debugging tools. It was also returning a Tomcat 404 error message.

Considering the payload, we didn’t expect this to be a problem produced by the environment. However, it eventually became clear that something was sanitizing the data before it was passed to the servlet. Even more curious, when we checked the access log produced by Tomcat, we saw that the accessed URL was different from what we had expected.

We tried switching to Tomcat 6.5 and reran the exploit. We discovered that the payloads functioned properly. Further, the Tomcat 6.5 access log also looked very different.

This is a good example of how far you can go toward mitigating vulnerabilities simply by keeping infrastructure around older software upgraded. On the reverse side, it might mean that exploits like these exist in other products but go undetected because the average install is expected to be running more modern infrastructure.

S2-008

This vulnerability allows OGNL evaluation on ExceptionDelegator. OGNL expressions are Turing complete and often have access to base Java classes, which attackers can further use to execute code within the context and capabilities of the host application, leading to remote code execution (RCE).

This vulnerability introduced a payload through the cookie header. What was interesting about this vulnerability was that the inclusion of Apache Struts was enough to make it exploitable, so even the blank.war application was susceptible. In our example payload, we decided just to launch a shell command using OGNL and touch a file:

This worked and produced /tmp/RCE when it came to Tomcat 6. However, when we tried this same payload on Tomcat 8, it was quick to sanitize the cookie input and declare its displeasure in status logs:

Again, this shows that keeping infrastructure around older software upgraded can go a long way toward mitigating vulnerabilities.

Java Runtime Environment

S2-052

This vulnerability allows an RCE attack when using the Struts REST plugin with XStream handler to parse XML.

We set out to validate whether this RCE attack would function. We were able to reproduce the vulnerability, which results in a cast exception, using an adapted version of the publicly known payloads.

When we tried these same exploits against Java Runtime Environment 11 and a variety of others, we discovered that the payloads did not work. This was in part due to changes that occurred in runtime distributions, which lead to a com.thoughtworks.xstream.mapper.CannotResolveClassException.

However, we were able to modify the payload further so it did function in 11. Our experience shows that there are cases where a vulnerability seems mitigated but further modifications can be made to create an exploitation. In this case, it wasn’t enough just to upgrade the environment around the vulnerable component to mitigate it.

In our next blog post about exploitation, we’ll go into more depth about why it is necessary to modify exploits and similar scenarios to this.

Validation

S2-006

The error pages now describe S2-006 as a cross-site scripting (XSS) vulnerability, thanks to this project.

S2-006 was originally published with basic information that didn’t make much sense:

Researchers

• Stephen Mort
• Padraig Donnelly
• Ashley Stone
• Omer Demirok