Struts2 and Webwork Remote Command Execution Vulnerability Analysis

Author: the heart of emptiness, source: IT expert network

Link: http://security.ctocio.com.cn/100/11466600.shtml

The POC released by the Vulnerability discoverer does not affectXworkVersions earlier than 2.1.2 (some versions earlier than this version are collectively referred to as the old version and later are called the new version ), for example, struts 2.0.14 (the first version and the most common version after struts fixes N high-risk vulnerabilities) cannot be used. This article will analyze the causes and results of this vulnerability, the idea of killing the POC is also given.

People who want to understand this article can focus on analysis ideas, but do not want to hold the POC everywhere. This article does not provide any hacking tools, and all POC files have been published, countless people know this.

　　The tragedy of xwork vulnerability fixing (vulnerability history ):

As struts2 andWebworkHas fixed the "xwork parameter interceptor allows ognl method execution" vulnerability and provided a vulnerability announcement.

Http://struts.apache.org/2.x/docs/s2-003.html

S2-003

　First repair

However, the final result of this patch is a tragedy. As you may recallFramework securityDefects, a developer who does not understand web security completely, filters the character "script" only for the POC to fix XSS 〉", once the user submits "script xxx", it bypasses the silly x patching method.

They maintain a consistent style and use the regular "{\ p {Graph} & [^, #: =]} *" to fix this vulnerability. In addition, only the POC provided by the attacker is repaired and published after the POC test is passed.

 

Parse several tragic test cases that xwork developers use POC.

To make ParametersInterceptor think it is a legal ognl statement, the variable must eventually contain #.

This line cannot be verified. When java performs string operations, u0023 is escaped as # Before matching is performed. Therefore, false is returned. We can see that u0023 and # are completely equal.

Therefore, the vulnerability fix developer can use regular expressions to kill the bug.

Although the attacker sent a message of u0023, this character is converted to \ u0023 before being computed in the memory. To ensure data integrity, java automatically adds an escape character when processing a string segment submitted by the user. For example, when the user submits the data "" and performs a string operation in the memory, it does not really use line breaks for computation, but compares them with the "\ n" character. The u0023 submitted by the user is converted\ U0023The # check will be bypassed.

Evidence

The two cases do not pass the code verification for the same reason.

The tragedy is here. Although it is \ u0023, it is in line with the scenario submitted by the user. The tragedy is that there is space in the character, and it is on both sides of the +, so it cannot pass, if the attacker removes spaces, the attacker passes.

This is the official release. In fact, a vulnerability version is released.

This is the first patch. We all know this patch because it was released. Although the official announcement is highly risky, the official website only knows that attackers can modify server session information through ognl expressions. At this time, the official website has not realized that this is actually a remote code execution vulnerability. ognl not only supports modification, but also supports executing some static methods, such as @runtime@getruntime(cmd.exe c ("calc ").

　Second repair

Until one day, it may be in version xwork2.1.2 that the official team secretly modified the Security Configuration. By default, the value of allowStaticMethodAccess of SecurityMemberAccess (class for managing ognl permissions) is false, which causes the static method to fail to be executed, for some reason, the system secretly modifies the Regular Expression and also releases the restriction on space characters in parameter names.

　　Vulnerability exposed

This time, the Remote Code Execution (Struts2/XWork <2.2.0 Remote Command Execution Vulnerability) was launched. The Vulnerability discovery found that the u0023 restriction was actually invalid and found a way to bypass the default security configuration, in addition, ognl allows static methods to execute code remotely.

　　Principles:

1. the user submitted u0023 and escaped it as \ u0023. After verifying the parameter name, The ognl becomes u0023, that is, #, and complies with the ognl syntax.

2. By executing Ognl statements, you can overwrite some default configurations in the ognl context when running struts2 and webwork. The vulnerability discoverer provides a number of override values.

3. Although static method execution is disabled by default, the xwork configuration can be overwritten. Once the value "used to disable static method execution" is overwritten, of course, you can execute it again.

4. The section runtime.getruntime(cmd.exe c () can actually be called as a static method, resulting in the execution of system commands. The Ognl statement calls the static method: @runtime@getruntime(cmd.exe c ("calc ").

The vulnerability discoverer gave shellcode. However, after my tests, shellcode does not affect all versions, but is only valid for versions xwork2.1.2 and later, xwork2.1.2 and above are applied in some versions of struts2 and webwork, so they are indirectly affected, but the patching code is done by xwork.

　　The vulnerability discoverer provides the POC:

　　Consequences of shanzhai repair methods

I have seen a lot of people who have simply analyzed this vulnerability. Some people who do not know the truth believe that this is because of the consequences of the parameter name \ u0023. The official website did not fix this vulnerability well, you can filter \ u0023 to solve this problem.

This is one of the "one" vulnerability analysts I have met. I have built my own shanzhai patch. The principle is to disable \ u0023:

From an article on the Internet, the second solution does not comply with the XML rule -_-!.

This is only one of the solutions. Many people say that \ u0023 can be disabled. I have to say that this person should have analyzed the vulnerability and understood the principle. He knows that although the official patch has been released, it uses the white list form and imposes too strict restrictions on parameter names. Many special symbols cannot be used, which may cause problems in some applications, this is a typical developer thinking.

　　This is an official patch:

Http://svn.apache.org/viewvc/struts/struts2/trunk/xwork-core/src/main/java/com/opensymphony/xwork2/interceptor/ParametersInterceptor.java? View = markup & pathrev = 956389

To prioritize Business Protection, you can fix vulnerabilities by disabling \ u0023. Therefore, the above solution seems feasible and cannot be used after testing the POC.

I also saw this method. This is really a tragedy. Can the interception of u0023 solve the problem?

Why does the vulnerability discoverer bypass # restriction through u0023? Is there any other code that can be bypassed?

The answer is that there are other codes that can be bypassed and only u0023 is controlled, which is a tragedy. After my actual test, I found that #'s octal Code 43 is also used here, and 43 is also available. So I smiled:

This new POC does not have any u0023, but can execute calc. After actual tests, it bypasses all the defenses that only filter u0023. Let them fix it slowly. We don't have to worry about it. When we put a patch for filtering u0023, we will release this new POC.

I was very cautious when I saw neeao. I went directly to the official patch. This is his analysis of this vulnerability:

Http://neeao.com/archives/59/

　The POC of struts and webwork in earlier versions is not common.

During the implementation of the repair solution, developers always fix vulnerabilities from their own perspective and experience. They also adopt the u0023 filtering solution, with a minimum correct attitude. Unlike the development of some internet companies, the reason is simple. He uses old versions of struts and webwork. For struts2 and webwork of the core below xwork2.1.2, POC playing has no effect, so I think this security level is not high. Please wait for the official announcement (so far, the official announcement has not been released, fix the code and submit it to SVN. The version is not released after compilation ).

Out of curiosity, I decided to study it carefully. I am not familiar with xwork source code and ognl. I have studied only the struts2 part before.