图片上传之后清空_Struts2漏洞系列之「S2-045」上传数据异常导致的OGNL表达式执行

Smi1e@Pentes7eam

漏洞信息：https://cwiki.apache.org/confluence/display/WW/S2-045

Struts2默认使用 org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest类对上传数据进行解析。其在处理Content-Type时如果获得非预期的值的话，将会抛出一个异常，在此异常的处理中会对错误信息进行OGNL表达式解析。

漏洞复现

影响范围

Struts 2.3.5 - 2.3.31, Struts 2.5 - 2.5.10

漏洞分析

Struts 2.3.5 - 2.3.31和Struts 2.5 - 2.5.10漏洞入口不同

前者调用栈

在过滤器 org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter的dofilter方法中下断点，跟进this.prepare.wrapRequest(request);，它会封装request对象。

其中会判断 content_type中是否含有字符串multipart/form-data，如果有则实例化MultiPartRequestWrapper对象，并传入对应参数来对请求进行解析。其中this.getMultiPartRequest;会去获取用来处理文件上传请求的解析类，默认是org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest。我们可以通过配置struts.multipart.parser属性来指定不同的解析类。

跟进 this.multi.parse(request, saveDir);，这里的this.multi就是默认的JakartaMultiPartRequest对象。

这里由于对上传请求解析时发现错误所以会进入到下面的 catch操作中，跟进this.buildErrorMessage

它会调用 LocalizedTextUtil.findText处理错误信息

不断跟进会发现他会把message传入 TextParseUtil.translateVariables进行表达式解析。

后面就还是以前的流程了。

而 Struts 2.5 - 2.5.10中 org.apache.struts2.dispatcher.multipart.MultiPartRequestWrapper.buildErrorMessage并没有调用LocalizedTextUtil.findText

它是在拦截器 FileUploadInterceptor中调用的LocalizedTextUtil.findText(error.getClazz, error.getTextKey, ActionContext.getContext.getLocale, error.getDefaultMessage, error.getArgs);从而对错误信息进行OGNL表达式解析

在2.3.30/2.5.2之后的版本，我们可以用来bypass黑名单过滤的 _memberAccess和DefaultMemberAccess都进入到了黑名单中。

不过个人认为沙盒修复的关键是Ognl3.0.18+和Ognl3.1.10+中 OgnlContext删除了_memberAccess这个key，从而禁止了对_memberAccess的访问。Struts2.3.30开始使用的是Ognl3.0.19，Struts2.5.2开始使用的是Ognl3.1.10。从S2-045的payload中也能看出来，直接可以执行(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS)，后面才开始查看是否存在#_memberAccess。

%{(#fuck='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames.clear).(#ognlUtil.getExcludedClasses.clear).(#context.setMemberAccess(#dm)))).(#cmd='CMD').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase.contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=newjava.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start).(#ros=(@org.apache.struts2.ServletActionContext@getResponse.getOutputStream)).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream,#ros)).(#ros.flush)}

在初始化了 OgnlValueStack对象后，会对OgnlValueStack对象进行依赖注入。

这个时候会调用 com.opensymphony.xwork2.ognl.OgnlValueStack$setOgnlUtil将黑名单添加进来赋值给OgnlValueStack的securityMemberAccess对象

这里需要注意的是由于 OgnlUtil默认为singleton单例模式，因此全局的OgnlUtil实例都共享着相同的设置。如果利用OgnlUtil更改了设置项(excludedClasses、excludedPackageNames、excludedPackageNamePatterns)则同样会更改_memberAccess中的值。

为什么改了 OgnlUtil的值以后_memberAccess的值也会改变呢？

首先上面说过了全局的 OgnlUtil实例都共享着相同的设置。然后因为SecurityMemberAccess类的excludedClasses等属性都是集合类型

而在java中集合赋值时传递的是一个引用，我们对集合做的任何操作都会影响到它赋值过的变量。所以在解析Ognl表达式时，当 OgnlUtil的excludedClasses等安全属性被清空时，_memberAccess对象的excludedClasses等安全属性也直接随之被清空了。

漏洞修复

不把报错的信息放到 LocalizedTextUtil.findText方法中去，从而保证报错的content-type不会进行OGNL表达式解析。

2.5.10.1版本修改：https://github.com/apache/struts/commit/b06dd50af2a3319dd896bf5c2f4972d2b772cf2b

2.3.32版本修改：https://github.com/apache/struts/commit/352306493971e7d5a756d61780d57a76eb1f519a

https://www.easyaq.com