欢迎来到 无奈人生 安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

熟悉的Str2-045,不一样的认识

来源: 作者: 时间:2019-02-24 19:29 点击: 我要投稿
广告位API接口通信错误,查看德得广告获取帮助

0×01 前言
Struts2漏洞频发的Java主流框架,在利用大佬们的poc或者工具时,我们又是否知道这个漏洞到底谁怎么产生的,那么一大串的POC到底是什么意思?准备从漏洞的调用链,到Bypass安全管理器到POC的拆分理解。
0×02漏洞概述:
(说点废话)Struts是Apache基金会的一个开源项目,Struts框架广泛应用于政府、公安、交通、金融行业和运营商的网站建设,是应用最广泛的Web应用框架之一。
漏洞编号:CVE-2017-5638
漏洞全称:基于Jakarta插件的插件的Struts远程代码执行漏洞
描述:Struts使用的Jakarta解析文件上传请求包不当,当攻击者使用恶意的Content-Type,会导致远程命令执行。
利用条件:Struts 2.3.5 – Struts 2.3.31    Struts 2.5 – Struts 2.5.10
默认模块Jakarta中需要依赖commons-fileupload和commons-io
0×03分析概述:
首先先从简单的漏洞描述开始分析:描述中说道是因为Jakarta插件文件请求包不当导致的远程命令执行,那是不是这个漏洞非常的鸡肋,需要依赖于第三方jar包,才可以攻击成功。
 其实不是的,因为struts2-croe-2.3.20.jar中struts-default.xml中指定默认的处理multipart报文的解析器是jakarta

所以一般只要是Struts2涉及到文件上传,就定会有jakarta插件,而jakarta插件又依赖于依赖commons-fileupload和commons-io两个第三方jar包。
为什么说是一般呢,程序员可以将默认的上传插件在Str2的配置文件改掉。但是我想使用Str2框架写项目的这样做的程序员并不多。所以只要符合Str2影响版本,可以不考虑第三方jar和插件的原因, 直接远程命令执行。相信不需要什么太多的环境依赖和限制条件,直接可以RCE。在当时影响多大就不在絮叨了。
0×04动态调用分析:
首先Str2框架写的所有的请求会被StrutsPrepareAndExecuteFilter的过滤器给拦截做处理

跟进StrutsPrepareAndExecuteFilter,wrapRequest对request进行了封装
继续跟进,发现会对ContentType进行判断,看是否包含multipart/form-data字段,包含就继续,不包含就G,这就是说为什么网上流传的那些poc为什么都需要构造multipart/form-data字段。跟进getMultiPartRequest

发现通过MultPartReques.class的类类型,来获取MultPartReques实例

而MultiPartRequest又由JakartaMultiPartRequest类来实现,也就是咱们刚开始唠的这个依赖Jakarta插件的漏洞到底鸡肋不鸡肋。再一次得到了验证。

接着交给依赖包fileipload进行解析,首先会判断contentType是否为空,如果不为空再判断是否是MULTIPART开头如果不是就报InvalidContentTypeException的异常。这就证明了为啥流传的poc的multipart/form-data字段前面或多或少的老有一些没有任何联系的任意字符。


放发生异常后,又会返回到JakartaMultiPartRequest类的parse方法对异常进行处理。看一看有两异常,第一个文件过大异常,和除文件过大外的其它异常。当发生异常后他们都会进入一个神奇的方法buildErrorMessage。

而buildErrorMessage方法里又存在一个LocalizedTextUtil.findText这个就是我们今天的主角。为什么这么说呢

为了说为什么是主角,拿出了struts2-2.3.32也就是官方修复后不存在漏洞的版本。也就是下图。 

发现官方的修复方案就是对LocalizedTextUtil.findText进行了处理。我们看看到底有什么猫腻

被处理的FindText方法中,有一个重要的参数也就是e.getMessage,里边存了异常信息和咱们恶意的构造的ContentType。最后会把ContentType中的ongl语句去解析执行。所以官方不再把e.getMessage作为而LocalizedTextUtil.findText的defatulMessage参数而是作为args参数传入。

[1] [2]  下一页

0×01 前言
Struts2漏洞频发的Java主流框架,在利用大佬们的poc或者工具时,我们又是否知道这个漏洞到底谁怎么产生的,那么一大串的POC到底是什么意思?准备从漏洞的调用链,到Bypass安全管理器到POC的拆分理解。
0×02漏洞概述:
(说点废话)Struts是Apache基金会的一个开源项目,Struts框架广泛应用于政府、公安、交通、金融行业和运营商的网站建设,是应用最广泛的Web应用框架之一。
漏洞编号:CVE-2017-5638
漏洞全称:基于Jakarta插件的插件的Struts远程代码执行漏洞
描述:Struts使用的Jakarta解析文件上传请求包不当,当攻击者使用恶意的Content-Type,会导致远程命令执行。
利用条件:Struts 2.3.5 – Struts 2.3.31    Struts 2.5 – Struts 2.5.10
默认模块Jakarta中需要依赖commons-fileupload和commons-io
0×03分析概述:
首先先从简单的漏洞描述开始分析:描述中说道是因为Jakarta插件文件请求包不当导致的远程命令执行,那是不是这个漏洞非常的鸡肋,需要依赖于第三方jar包,才可以攻击成功。
 其实不是的,因为struts2-croe-2.3.20.jar中struts-default.xml中指定默认的处理multipart报文的解析器是jakarta

www.wnhack.com


所以一般只要是Struts2涉及到文件上传,就定会有jakarta插件,而jakarta插件又依赖于依赖commons-fileupload和commons-io两个第三方jar包。
为什么说是一般呢,程序员可以将默认的上传插件在Str2的配置文件改掉。但是我想使用Str2框架写项目的这样做的程序员并不多。所以只要符合Str2影响版本,可以不考虑第三方jar和插件的原因, 直接远程命令执行。相信不需要什么太多的环境依赖和限制条件,直接可以RCE。在当时影响多大就不在絮叨了。
0×04动态调用分析:
首先Str2框架写的所有的请求会被StrutsPrepareAndExecuteFilter的过滤器给拦截做处理

跟进StrutsPrepareAndExecuteFilter,wrapRequest对request进行了封装
继续跟进,发现会对ContentType进行判断,看是否包含multipart/form-data字段,包含就继续,不包含就G,这就是说为什么网上流传的那些poc为什么都需要构造multipart/form-data字段。跟进getMultiPartRequest 无奈人生安全网

发现通过MultPartReques.class的类类型,来获取MultPartReques实例

而MultiPartRequest又由JakartaMultiPartRequest类来实现,也就是咱们刚开始唠的这个依赖Jakarta插件的漏洞到底鸡肋不鸡肋。再一次得到了验证。

接着交给依赖包fileipload进行解析,首先会判断contentType是否为空,如果不为空再判断是否是MULTIPART开头如果不是就报InvalidContentTypeException的异常。这就证明了为啥流传的poc的multipart/form-data字段前面或多或少的老有一些没有任何联系的任意字符。

www.wnhack.com



放发生异常后,又会返回到JakartaMultiPartRequest类的parse方法对异常进行处理。看一看有两异常,第一个文件过大异常,和除文件过大外的其它异常。当发生异常后他们都会进入一个神奇的方法buildErrorMessage。

而buildErrorMessage方法里又存在一个LocalizedTextUtil.findText这个就是我们今天的主角。为什么这么说呢

为了说为什么是主角,拿出了struts2-2.3.32也就是官方修复后不存在漏洞的版本。也就是下图。 
本文来自无奈人生安全网
发现官方的修复方案就是对LocalizedTextUtil.findText进行了处理。我们看看到底有什么猫腻

被处理的FindText方法中,有一个重要的参数也就是e.getMessage,里边存了异常信息和咱们恶意的构造的ContentType。最后会把ContentType中的ongl语句去解析执行。所以官方不再把e.getMessage作为而LocalizedTextUtil.findText的defatulMessage参数而是作为args参数传入。
本文来自无奈人生安全网

[1] [2]  下一页

本文来自无奈人生安全网

。 (责任编辑:admin)
【声明】:无奈人生安全网(http://www.wnhack.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱472701013@qq.com,我们会在最短的时间内进行处理。