Struts2/XWork & amp; lt; 2.2.0 remote execution of arbitrary code vulnerability analysis and repair

The. exploit-db website broke out in July 14Struts2 Remote Arbitrary Code Execution VulnerabilityThis vulnerability is very harmful. It can be said to be the root of a hundred machines. As long as the Struts2 and webwork framework systems are used (for the webwork version, it is not clear that I have no environment to test it one by one here,The relationship between the two is described here..

2. after receiving a reminder from a friend yesterday, I quickly fixed some of the company's project vulnerabilities developed using this framework. I think most of the large companies have fixed the issue almost immediately, however, there are still many companies that do not have a security team. It is estimated that they are still hacked. I feel it is necessary to remind friends who are using struts for development here, after all, I did java development.

3. the vulnerability causes are described in detail in the vulnerability poc, but they are all in English. People who do not know Java may be confused, in fact, it is also a rough translation of the original text. If you are not familiar with the terms, please Google:

The core of Struts2 is the webwork framework, and webwork is used.XWork to process the action, and by calling the underlyingThe getter/setter method is used to process http parameters. It declares each http parameter as an ONGL (Here is the ONGL Introduction) Statement. When we submit an http parameter:

user.address.city=Bishkek&user[favoriteDrink]=kumys

ONGL converts it:

action.getUser().getAddress().setCity("Bishkek")

action.getUser().setFavoriteDrink("kumys")

This is executed through ParametersInterceptor (parameter filter), and ValueStack. setValue () is called using the HTTP parameter provided by the user ().

In addition to parameter settings and reading, ONGL supports other features:

• Call method:foo()
• Call static methods:@java.lang.System@exit(1)
• Class call:new MyClass()
• Processing context variables:#foo = new MyClass()

Because ONGL calls can be performed through http passing parameters, Xwork sets two parameters to prevent attackers from calling arbitrary methods:

• OgnlContextXwork. MethodAccessor. denyMethodExecution (true by default)
• SecurityMemberAccess private fieldAllowStaticMethodAccess (false by default)


To make it easier for developers to access various objects, XWork defines many predefined context variables:

• #application
• #session
• #request
• #parameters
• #attr

These variables represent various Server variables. To prevent attackers from tampering with server objects, the ParametersInterceptor of XWork does not allow # In parameter names. About a year ago, the vulnerability discoverer found a way to bypass this protection (XW-641), Which is represented by a java unicode string:U0023. At that time, I felt like using a method.(OGNL value stack clearing)It is not enough, but there is no more time to study.

Earlier this year, vulnerability discoverers discovered some XworkSome predefined variables:

• # Context-whether the method can be called is the value of the xwork. MethodAccessor. denyMethodExecution Attribute Based on OgnlContext
• # _ The allowStaticAccess field of memberAccess-SecurityMemberAccess is used to prevent the execution of static methods.
• # Root
• # This
• # _ TypeResolver
• # _ ClassResolver
• # _ TraceEvaluations
• # _ LastEvaluation
• # _ KeepLastEvaluation

UseXW-641As described, the vulnerability discoverer can modify some values to call protected Java code and execute any Java code:

View source Print?

1	#_memberAccess[allowStaticMethodAccess] = true

2	#foo = new java .lang.Boolean("false")

3	#context[xwork.MethodAccessor.denyMethodExecution] = #foo

<