Making the Struts2 app more secure: Don’t include Config Browser

Struts2 allows a developer to include other Struts2 applications via the Plugin architecture. From the site:

Struts2 plugins contain classes and configuration that extend, replace, or add to existing Struts framework functionality. A plugin can be installed by adding its JAR file to the application’s class path, in addition to the JAR files to fulfill whatever dependencies the plugin itself may have. To configure the plugin, the JAR should contain a struts-plugin.xml file, which follows the same format as an ordinary struts.xml file.

This makes security code reviews in a Struts2 application a bit more challenging. Here’s a sample procedure:

• Examine all JAR files accessible by the web application under the WEB-INF/lib directory.
• For each JAR, examine it for a struts-plugin.xml file.
• If it contains a struts-plugin.xml, examine it like it’s a normal Struts2 web application (entry points, sinks, and everything in-between).

Plugin auditing procedures aside, one plugin that stands out as a security risk is Config Browser.

Config Browser is a really nice plugin in that it helps a developer understand details on a deployed Struts2 application. And vice versa, when deployed to production, Config Browser helps everyone else understand how that application is deployed 🙂 What does it disclose, I hear ya ask?

• All Struts2 entry points into the application, the classes which expose the entry points, and helpful URLs to the entry points
• Result codes, the files to which they point, and default parameter values
• Variable names and types within the entry point
• Version of Struts2
• Interceptor stack and ordering
• Et cetera, et cetera, et cetera…

Unless a default parameter value contains sensitive information, none of this is really directly exploitable. But c’mon, this is a lot of information! Make your attackers work a little bit 😉 At least let them be noisy when trying to guess URLs versus giving them all out.

Getting back to plugins, remember how they’re deployed? The Config Browser plugin just needs to be on the class path. It’s not declared anywhere within the main application’s source code or config files. That is, there’s no obvious indication the plugin would be loaded. Ouch!

However, hope isn’t lost. If the application is using Maven, take a look at the application’s pom.xml for something like this:

<dependency>
    <groupId>org.apache.struts</groupId>
    <artifactId>struts2-config-browser-plugin</artifactId>
    <version>2.3.15.1</version>
</dependency>

The above tells Maven to download the Config Browser JAR and include it within the web application. Notice that we’re looking at how the application is compiled versus the application code itself. Yeah… If the application is using some other build system, then check if something similar is declared. Or maybe just look for all *config*.jar or *struts2*.jar files. If the application is live, try scanning for config-browser/index or config-browser/index.action. And for the Google dorks out there, here are a couple fun searches:

• inurl:config-browser/index
• inurl:config-browser/index.action
• intitle:”Actions in namespace”

Happy hacking!