注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

0与1构筑世界,程序员创造时代

软件架构设计 Java编程

 
 
 

日志

 
 

Struts2/WebWork高危漏洞(远程执行任意代码)及解决方法 / Struts2/XWork < 2.2.0 Remote Command Execution Vulnerability  

2010-07-26 22:43:47|  分类: 安全 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
  文章声明

作者:傲风(aofengblog@163.com)       编写时间:2010年07月26日

网址:http://aofengblog.blog.163.com

作者保留所有权利,转载请保留文章全部内容!



7月14日,exploit-db 网站曝出一个Struts2/WebWork可以远程执行任意代码的高危漏洞。
 
漏洞名称:Struts2/XWork < 2.2.0 Remote Command Execution Vulnerability
漏洞影响范围:Struts-2.2.0以下所有版本,WebWork所有版本。
漏洞危险性:

漏洞分析

Struts2的核心是使用的WebWork,处理Action时通过ParametersInterceptor(参数过滤器)调用Action的getter/setter方法来处理http的参数,它将每个http参数声明为一个ONGL语句。
例如:
1、请求参数
    ?company.name=AILK&level=no1
2、经ONGL转义后,在Action中执行代码如下:
    getCompany.setName("AILK") 
    setLevel("no1") 
 
为了防范篡改服务器端对象,XWork的ParametersInterceptor不允许参数名中出现“#”字符,但如果使用unicode字符串表示\#,攻击者就可以绕过保护,修改保护Java方式执行的值。
例如:
在请求Action中带上如下参数:
?('\#_memberAccess[\'allowStaticMethodAccess\']')(meh)=tr&(aaa)(('\#context[\'xwork.MethodAccessor.denyMethodExecution\']\=\#foo')(\#foo\=new%20java.lang.Boolean("false")))&(asdf)(('\#rt.exit(1)')(\#rt\=@java.lang.Runtime@getRuntime()))=1 
 
可以停止当前Action所在的J2EE服务器(Tomcat, Resin, WebLogic,……)。
 
经过我的测试,利用该漏洞已经顺利地执行了mkdir, rm操作。

解决方法

1、修改Struts2的配置文件,过滤\#。
<interceptor-ref name="params"> 
    <param name="excl?Params">.*\\#.*</param> 
</interceptor-ref>

说明:如果应用中各个模块是直接从package struts-default继承的,需要修改每一个模块的struts配置文件。
 
2、编写一个过滤器(Filter),配置在web.xml中,只要参数中带有\#就拒绝请求跳转到错误页面。

说明:整个应用只需要一个过滤器即可。

附录:exploit-db 网站描述该漏洞原文

Friday, July 9, 2010
CVE-2010-1870: Struts2/XWork remote command execution
Update T Jul 13 2010: Added proof of concept
 
Apache Struts team has announced uploaded but has not released, d to an unreasonably prolonged voting process, the 2.2.0 release of the Struts2 web framework which fixes vulnerability that I've reported to them on May 31st 2010. Apache Struts team is ridiculously slow in releasing the fixed version and all of my attempts to expedite the process have failed.
 
Introd tion
Struts2 is Struts + WebWork. WebWork in turn uses XWork to invoke actions and call appropriate setters/getters based on HTTP parameter names, which is achieved by treating each HTTP parameter name as an OGNL statement. OGNL (Object Graph Navigation Lang ge) is what turns:
 
user.address.city=Bishkek&user['favoriteDrink']=kumys
 
into
 
action.getUser().getAddress().setCity("Bishkek")
action.getUser().setFavoriteDrink("kumys")
 
This is performed by the ParametersInterceptor, which calls ValStack.setVal() with user-supplied HTTP parameters as arguments.
NOTE: If you are using XWork's ParametersInterceptor or operate with OGNL ValStack in a similar way then you are vulnerable (ParametersInterceptor is on by default in struts-default.xml).
 
In addition to property getting/setting, OGNL supports many more features:
 
    * Method calling: foo()
    * Static method calling: @java.lang.System@exit(1)
    * Constr tor calling: new MyClass()
    * Ability to work with context variables: #foo = new MyClass()
    * And more...
 
Since HTTP parameter names are OGNL statements, to prevent an attacker from calling arbitrary methods via HTTP parameters XWork has the following two variables g rding methods execution:
 
    * OgnlContext's property 'xwork.MethodAccessor.denyMethodExecution' (set to tr by default)
    * SecurityMemberAccess private field called 'allowStaticMethodAccess' (set to false by default)
 
OGNL Context variables
To make it easier for developer to access various freqntly needed objects XWork provides several predefined context variables:
 
    * #application
    * #session
    * #reqst
    * #parameters
    * #attr
 
These variables represent various server-side objects, s h as session map. To prevent attackers from tampering with server-side objects XWork's ParametersInterceptor disallowed # in parameter names. About a year ago I found a way to bypass that protection(XW-641) using Java's unicode String representation: \#. At the time I felt like the fix that was implemented (OGNL val stack clearing) was ins?icient, but had not time to investigate this further.
 
CVE-2010-1870
Earlier this year I finally got a chance to look at this again and found that in addition to the above mentioned context variables there were more:
 
    * #context - OgnlContext, the one g rding method execution based on 'xwork.MethodAccessor.denyMethodExecution' property val.
    * #_memberAccess - SecurityMemberAccess, whose 'allowStaticAccess' field prevented static method execution.
    * #root
    * #this
    * #_typeResolver
    * #_classResolver
    * #_traceEval tions
    * #_lastEval tion
    * #_keepLastEval tion
 
You can probably see the problem already. Using XW-641 trick I was able to modify the vals that were g rding Java methods execution and run arbitrary Java code:
 
#_memberAccess['allowStaticMethodAccess'] = tr
#foo = new java .lang.Boolean("false")
#context['xwork.MethodAccessor.denyMethodExecution'] = #foo
#rt = @java.lang.Runtime@getRuntime()
#rt.exec('mkdir /tmp/PWNED')
 
Act l proof of concept had to use OGNL's expression eval tion when crafting HTTP reqst. PoC for this bug will be p lished on July 12 2010. To test whether your application is vulnerable you can use the following proof of concept, which will call java.lang.Runtime.getRuntime().exit(1):
 
 
http://mydomain/MyStruts.action?('\#_memberAccess[\'allowStaticMethodAccess\']')(meh)=tr&(aaa)(('\#context[\'xwork.MethodAccessor.den
yMethodExecution\']\=\#foo')(\#foo\=new%20java.lang.Boolean("false")))&(asdf)(('\#rt.exit(1)')(\#rt\=@java.lang.Runtime@getRunti
me()))=1
 
 
Fixing CVE-2010-1870
Struts2 users must upgrade to the 2.2.0, which whitelists a set of characters that excl?s characters required to exploit this vulnerability.
 
 
In cases where upgrade isn't possible you can use ParameterInterceptor's "excl?Params" parameter to whitelist the characters required for your application to operate correctly(us lly A-z0-9_.'"[]) alternatively you can blacklist \()@ which are the characters required to exploit this bug.
 
Timeline
May 31st - email to security@struts.apache.org with vulnerability report.
June 4th - no response received, contacted developers again.
June 5th - had to find an XWork developer on IRC to look at this.
June 16th - Atlassian fixes vulnerability in its prod ts. Atlassian and Struts developers worked together in coming up with the fix.
June 20th - 1-line fix commited
June 29th - Struts 2.2.0 release voting process started and is still going...


<正文结束>
  评论这张
 
阅读(5695)| 评论(4)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017