传送门
【重大漏洞预警】Struts 2 远程代码实行漏洞(S2-045\S2-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
