传送门
【重大漏洞预警】Struts 2 远程代码执行漏洞(S2-045S2-046) (含PoC)
【漏洞分析】Strust2 S2-046 远程代码执行漏洞两个触发点分析
作者:hezi@360GearTeam
背景介绍
Struts2又爆了一个等级为高危的漏洞—S2-046,仔细一看,S2-046和S2-045的漏洞触发点一样,利用方式不一样。不过也因为S2-046和S2-045触发点相同,所以之前通过升级或者打补丁方式修补S2-045漏洞的小伙伴们就不用紧张了,如果是仅针对Content-Type做策略防护的话,还需要对Content-Disposition也加一下策略。当然最好的方式还是升级到最新版。
S2-046漏洞的利用条件是在S2-045的基础上的。S2-046基本利用条件有两点:
1. Content-Type 中包含multipart/form-data
2. Content-Disposition中filename包含OGNL语句
这里解释一下Content-Disposition。Content-disposition 是 MIME 协议的扩展,当浏览器接收到请求头时,它会激活文件下载对话框,请求头中的文件名会自动填充到对应的文本框中。
S2-046有两个利用方式,一个是Content-Disposition的filename存在空字节,另一个是Content-Disposition的filename不存在空字节。其中,当Content-Disposition的filename不存在空字节并想要利用成功的话,还需要满足以下两个条件:
a. Content-Length 的长度值需超过Struts2允许上传的最大值(2M),如图。
b.数据流需要经过JakartaStreamMultiPartRequest。(需在struts.xml添加配置: <constant name="struts.multipart.parser" value="jakarta-stream" />)
需要注意的是,在Struts使用Jakarta默认配置时,数据流并没有经过JakartaStreamMultiPartRequest。根据官方解释,在Struts 2.3.20以上的版本中,Struts2才提供了可选择的通过Streams实现Jakarta组件解析的方式。在Struts 2.3.20以上的版本中,通过Jakarta组件实现Multipart解析的流程可以有两种,一种是默认的Jakarta组件,一种是在struts.xml中主动配置<constant name="struts.multipart.parser" value="jakarta-stream" />。而只有在struts.xml中添加了相应配置,数据流才会经过JakartaStreamMultiPartRequest。
下图分别为Struts 2.3.8和Struts 2.3.24.1的multipart部分的源码包。可以看到Struts 2.3.24.1比Struts 2.3.8新增了一个文件JakartaStreamMultiPartRequest。所以,如果构造的poc中Content-Disposition的filename不存在空字节,则它的影响版本为2.3.20以上的版本。
源码分析
以下源码分析基于Struts 2.3.24.1,我们根据利用方式不同分析下这两个数据流的执行过程。
Content-Disposition的filename存在空字节
对上传的文件解析
创建拦截器后解析header,如图:Content-Type和Content-Disposition都在此解析。
Filename从Content-Disposition获取。
解析到filename后,会对文件名进行检查,若Content-Disposition的filename存在空字节时,则会抛出异常。如图。
最后进入到触发点。
Content-Disposition的filename不存在空字节
这个利用方式有一个条件是Content-Length 的长度需超过Struts允许上传的最大长度,并且数据流要经过JakartaStreamMultiPartRequest,这是因为JakartaStreamMultiPartRequest和JakartaMultiPartRequest对Content-Length的异常处理方式不一样。当数据经过JakartaStreamMultiPartRequest时,判断长度溢出后,进入addFileSkippedError(),如下图。这里注意,addFileSkippedError有一个参数为itemStream.getName,会对filename进行检查,如果filename中存在空字节, 则和上一个利用方法的数据流一样,在checkFileName()就抛出异常,不会再进入到addFileSkippedError()了。
跟进addFileSkippedError()可以看到, buildErrorMessage()抛出异常时调用了filename,这个filename就是通过Content-Disposition传递的filename。而buildErrorMessage()就是漏洞触发点,传递来的filename被解析,形成了漏洞。
而在JakartaMultiPartRequest数据流中,在判断长度后,抛出的异常中并没有包含文件名解析,如下图。所以漏洞就不会被触发了。
个人感想
相同的触发点采用不同的绕过方式,这种事情已经不是第一次发生了。因为Struts2的交互性和扩展性,同一个触发点有可能有多个绕过方式。而这种漏洞的产生,也告诉我们,想要拿全cve,不仅要关注官方的patch,也要对数据流有比较全面的了解。以上分析为个人分析,感谢360GearTeam小伙伴们的支持。
参考文献
1. https://community.hpe.com/t5/Security-Research/Struts2-046-A-new-vector/ba-p/6949723#
2. http://bobao.360.cn/learning/detail/3571.html
3. http://struts.apache.org/docs/s2-046.html
4. https://github.com/apache/struts/commit/352306493971e7d5a756d61780d57a76eb1f519a
传送门
发表评论
您还未登录,请先登录。
登录