WebLogic兩處任意文件上傳漏洞動態分析是怎樣的

這篇文章將為大家詳細講解有關WebLogic兩處任意文件上傳漏洞動態分析是怎樣的，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

0x01 前言

CNCERT前幾天發公告稱發現Oracle公司出品的基于JavaEE結構的中間件WebLogic產品存在一個遠程上傳漏洞，并得到了廠商的確認，危害程度評分高達9.8分。鑒于廠商已進行了安全修復，筆者對該漏洞進行了一次分析。

WebLogic管理端未授權的兩個頁面存在任意上傳getshell漏洞，可直接獲取權限。兩個頁面分別為/ws_utc/begin.do，/ws_utc/config.do；漏洞的影響范圍 Oracle WebLogic Server，版本10.3.6.0，12.1.3.0，12.2.1.2，12.2.1.3；相關鏈接：    http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html#AppendixFMW  , 下文筆者從這兩個文件入手來系統調試跟蹤找出漏洞產生的原理和位置。    

0x02 簡介和原理

筆者首先訪問了一下 http://IP/ws_utc/config.do  并且將默認的目錄WSTestPageWorkDir修改為 user_projects\domains\base_domain\tmp\sd\  如下圖：

工作臺設置一個新的目錄后，weblogic會將原來目錄下的子目錄和文件一起轉移到新設定的目錄下，但舊的目錄依然保留。因為不是重點，筆者對這塊的分析就此略過。筆者從攻擊者的維度簡單的畫了一個草圖，最初攻擊者肯定需要配置工作目錄，因為默認的工作目錄在URL訪問的時候不可達，然后攻擊者考慮是從config.do頁面上傳keystore文件還是從begin.do上傳，最終都是成功上傳小馬，只是小馬的訪問格式和路徑不盡相同。如下圖：

如果要從原理上徹底搞清楚weblogic漏洞產生的過程還需要看下圖，簡單的描述一下，攻擊者開始攻擊后，Weblogic在服務端做了很多的判斷，如果設定了新的工作目錄，那么程序會自動拷貝所有舊目錄下的子目錄和文件到新的設定目錄里，并且設定新的目錄作為工作目錄，如果攻擊者通過begin.do上傳的話，Weblogic在服務端會判斷有沒有upload目錄，如果不存在會自動創建，再接著在upload目錄下創建Rs_Upload_格式化后的作為目錄名，緊接著獲取到import_file_name字段名作為后續的文件名拼接的一部分；如果通過config.do上傳的話就獲取GET請求中的timestamp參數作為后續webshell的文件名中的一部分，還是看下圖吧：    

0x03 begin.do頁面上傳漏洞

首先在IDE里搭建好WebLogic環境，把應用跑起來后點擊頁面右上方的文件夾按鈕，這里實現的是一個導入的功能    

選擇任意文件上傳，筆者選擇上傳jsp文件：

抓取數據包可以看到其實真正存在上傳漏洞的地址是：

http://IP:7001/ws_utc/resources/ws/config/import?timestamp=1532403983779

因為是漏洞復現和分析，筆者一邊上傳的時候就一邊把數據包抓取下來，得到下圖的HTTP：

這段沒什么可說的就是一個簡單的上傳數據流，表單字段import_file_name是關鍵值，從產品防御的角度來看檢測它們也是關鍵的特征之一。

接下來就需要在IDE里動態定位到漏洞的觸發點，因為weblogic大多數漏洞都和T3協議有關聯，根據之前分析過的weblogic漏洞定位的調試斷點是在com.bea.core.weblogic.rmi.client_4.0.0.0.jar包里，多次調試后一步步跳轉到了漏洞觸發的核心包 

并且查到了對應的觸發漏洞類名的位置： \com\oracle\webservices\testclient\ws\util\RSDataHelper.class

定位到的方法convertFormDataMultiPart，代碼如下：

代碼中檢查了當前工作目錄下是否存在upload目錄，如果沒有的話則創建，并且調用了cleanObsoleteFile方法強制遍歷了一次目錄中所有的文件，并且發現文件就刪除掉，調試過程如下圖 ：

再創建了一個以字符串Rs_Upload_打頭的加格式化后的時間命名的目錄，并且作為上傳文件保存的目錄。    

接下來程序獲得了上傳的表單的form-data , 經過循環遍歷獲取了所有的表單字段和對應的value，數據做兩塊存儲，一塊保存在kvMap集合中、獲取的附件通過saveAttacheFile方法保存到磁盤中，代碼如下：

下圖紅圈處是拼接后的物理路徑名：

接著追蹤調試到 execute方法，位于ImportTestCaseAction.class類中，實際的路徑是：\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_internal\com.oracle.webservices.wls.ws-testclient-app-wls_12.1.3\cmprq0\war\WEB-INF\lib\ws-testpage-impl.jar!\com\oracle\webservices\testclient\ws\action\ImportTestCaseAction.class

由于筆者導入的文件格式以及數據并非weblogic能處理的，所以程序在context.createUnmarshaller方法處拋出空指針異常的錯誤，這就導致了上傳成功后Response的狀態碼是500，這也可以作為防御產品檢測的特征之一。動態調試異常如下圖：

到此begin.do頁面未授權訪問引起的任意文件上傳漏洞已經很明朗，防御的策略可以檢測表單字段

0x04 config.do頁面上傳漏洞

訪問 http://IP:7001/ws_utc/config.do 頁面后點擊左側的“安全”菜單，添加一個Keystore，任意設置名字和密碼，當然文件也是任意格式上傳，這里真的很隨意。

點擊提交后，抓取觸發地址： http://IP/ws_utc/resources/setting/keystore?timestamp=1532400069848     ; 抓取的包如下        

和之前的套路一樣，上傳的時候就已經打開了IDE調試功能，斷點后還是定位到RSDataHelper.class 文件，如下圖

這次獲取的表單字段是ks_filename，值得收藏，加入特征檢測范疇內；再跟進看下關鍵的shell生成那一步

上傳后的shell位于工作臺配置的目錄下的/config/keystore/目錄中，文件名的格式相對來說簡單，采用了POST請求中URL地址上攜帶的參數timestamp的值加上下劃線拼接起來的文件名，讓筆者大跌眼鏡的是weblogic作為知名軟件提供商存在這樣低級的漏洞實在匪夷所思，再加上其一系列的反序列化繞過漏洞，只能說weblogic的產品能不用就不用，實在不行少用為妙。

0x05 防御措施

1.設置Config.do、begin.do頁面登錄授權后訪問；

2.IPS等防御產品可以加入相應的特征；

3.升級到官方最新版本。

關于WebLogic兩處任意文件上傳漏洞動態分析是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。