Apache Struts2 Remote Code Execution Vulnerability Analysis (S2-013)

Summary

Apache official struts2 product, recently issued a remote code execution vulnerability, number "S2-013", is currently 0 day, the official no repair solution appeared.
Http://struts.apache.org/development/2.x/docs/security-bulletins.html-(Announcement)
The official Security Bulletin provides numbers and A brief introduction, "A vulnerability, present in the includeParams attribute of the URL and Anchor Tag, allows remote command execution ".
However, I did not discuss the principle or release any patches.
Analysis:
In fact, this struts2 officially issued a total of two vulnerabilities, there is a called s2-012, but this vulnerability, to see the question, it should be my previous Xcon2012 attack java web has burst out, so this article only describes the other one.
Official development of struts2 is dumb. For example, this vulnerability should be released by the official team. Since it has been released, it should be patched, but the official team only published this article. For details, normal users do not open access.

From this section, we can summarize the following points:
1. unpatched Remote Code Execution Vulnerability
2. The includeParams parameter has a problem in the URLTAG.
Based on these two points, anyone familiar with the struts2 operating mechanism and previous vulnerability principles can easily analyze the specific POC usage.
Vulnerability trigger:
The latest version of struts2 is vulnerable because no patch is officially released. You can download the latest example application of Apache Struts 2.3.14 GA.
After a simple test, we can see the desired results.
According to the official information, the problem lies in tag a. Therefore, write a jsp page with the following content:

<S: a required deparams = "all"> Click here. </s: a>

This is the tag of the struts2 tag library. The tag displays the current URL on the page. When includeParams is set to all, the specific parameter content is displayed.
The only mystery that needs to be solved is how to make the parameter content as an OGNL to indicate trial execution, but it is not a good guess. I will test the result at will.
Access url:

Http: // localhost: 8080/blank/error. jsp? Aaa =$ {common POC of struts2, you know}

You can directly play the calculator, and everyone has the POC code. I only need to cut a picture:

There was almost no analysis process, and the POC was obtained. Finally, in order to study the repair solution, we had to study the vulnerability principle.
Vulnerability principle:
The url tag in the Struts2 tag Library and the includeParams attribute of the tag indicate the meaning of the Request access parameter. Once the value is assigned to ALL, GET, or POST, the specific request parameters are displayed. According to the normal requirements, it is enough to set the urlEncode parameter. The problem is that struts has done a step more, and the parameter has been parsed by OGNL!
Code:

Package org. apache. struts2.views. uti. DefaultUrlHelper parseQueryString method of this class. Public Map <String, Object> parseQueryString (String queryString, boolean forceValueArray) {Map <String, Object> queryParams = new LinkedHashMap <String, Object> (); if (queryString! = Null) {... if (paramName! = Null) {paramName = translateAndDecode (paramName); String translatedParamValue = translateAndDecode (paramValue );...... translateAndDecode calls private String translateVariable (String input) {ValueStack valueStack = ServletActionContext. getContext (). getValueStack (); return TextParseUtil. translateVariables (input, valueStack );}

In the end, TextParseUtil. translateVariables directly calls OGNL for parsing and execution.
Vulnerability repair:
Wait for the official team. I'm not in a hurry. Or when there are good people forwarding, please write down the scheme by the way