近期，Oracle官方發布了7月份關鍵補丁更新CPU（Critical Patch Update），其中修復了一個在4月份CPU補丁中未能完全修復的WeblogicServer反序列化漏洞（CNVD-2018-07811，CVE-2018-2628）。

該漏洞通過JRMP協議利用RMI機制的缺陷達到執行任意反序列化代碼的目的。攻擊者可以在未授權的情況下將payload封裝在T3協議中，通過對T3協議中的payload進行反序列化，從而實現對存在漏洞的WebLogic組件進行遠程攻擊，執行任意代碼並可獲取目標系統的所有許可權。

安全狗攻防研究實驗室針對該漏洞進行了一些分析，希望對行業和用戶有所補益。

WebLogic Server是美國甲骨文（Oracle）公司開發的一款適用於雲環境和傳統環境的應用服務中間件，它提供了一個現代輕型開發平台，支持應用從開發到生產的整個生命周期管理，並簡化了應用的部署和管理。

RMI目前使用Java遠程消息交換協議JRMP（Java Remote Messaging Protocol）進行通信，JRMP協議是專為Java的遠程對象制定的協議。在WebLogic Server的 RMI（遠程方法調用）通信中，T3協議（豐富套接字）用來在 WebLogic Server 和其他 Java 程序（包括客戶端及其他 WebLogic Server 實例）間傳輸數據，該協議在開放WebLogic控制台埠的應用上默認開啟。由於在WebLogic中，T3協議和Web協議共用同一個埠，因此只要能訪問WebLogic就可利用T3協議，將payload發送至目標伺服器。

01

PoC驗證

PoC驗證分為「漏洞環境搭建」與「攻擊實施」兩部分。在漏洞環境搭建時，設置有「靶機」和「攻擊機」兩台機器。「靶機」上運行有Weblogic伺服器（開啟了T3服務，埠為7001）。「攻擊機」上運行有能配合「遠程方法調用」的JRMPListener伺服器（埠為1099）以及一個SimpleHTTPServer伺服器（埠為8000）。PoC驗證的實驗示意圖如圖1所示。

圖 1 PoC驗證的實驗示意圖

在實施攻擊時，「攻擊機」會發送含有惡意代碼的payload給靶機的會解包Object結構的T3服務，以觸發T3協議在WebLogic Server中的反序列化漏洞，這將使得「靶機」的JRMPClient對「攻擊機」的JRMPListener伺服器進行遠程方法調用；JRMPListener會將含有惡意代碼的payload發送給JRMPClient，接著JRMPClient會解包Object結構並執行惡意代碼。因而「攻擊機」可以在「靶機」執行「指定命令」。

本實驗的「指定命令」是「對攻擊機的8000埠進行HTTP請求」。如果攻擊機可以從自身的8000埠檢測到來自靶機的HTTP請求，則證明RCE攻擊實施成功。

1、PoC來源

本實驗的PoC來源：

https://www.exploit-db.com/exploits/44553/

2、環境搭建

本實驗的環境搭建分為「靶機」和「攻擊機」兩部分。

「靶機」是Docker的Weblogic容器，「攻擊機」是「Kali 2」虛擬機。

為了搭建靶機，執行以下命令：

(1)從遠程拉取一個image

(2)創建並運行一個新容器

靶機的搭建結果如下圖所示

圖2靶機的搭建結果

為了搭建攻擊機，進行以下操作：

(1)下載ysoserial-0.0.6-SNAPSHOT-BETA-all.jar 與

ysoserial-0.1-cve-2018-2628-all.jar

(2)搭建Python SimpleHTTPServer

(3)開啟JRMPListener

攻擊機的搭建結果如下圖所示

圖3攻擊機的搭建結果

3、驗證步驟

在攻擊機執行 exploit.py]腳本，命令如下。

注：ysoserial-0.1-cve-2018-2893-all.jar中的JRMPClient2893類來自於360CERT寫的技術文章《CVE-2018-2893：Oracle WebLogic Server 遠程代碼執行漏洞分析預警》。為了成功編譯該類，筆者在IntelliJ IDEA的工程中導入了ysoserial-0.1-cve-2018-2628-all.jar這一jar包。在得到JRMPClient.class文件後，運用歸檔管理器打開ysoserial-cve-2018-2628.jar文件，接著將JRMPClient2893.class放入/ysoserial/payloads/文件夾。

這樣，該jar包就包含了JRMPClient2893.class。接著，將該jar包重命名為ysoserial-cve-2018-2893.jar，如圖4所示。

圖4將「JRMPClient2893.class」放入jar包

4、驗證結果

驗證結果如圖5所示，在攻擊機上的「SimpleHTTPServer」終端可以接收到IP為「192.168.1.106」的機器（靶機）所做的Get請求，這也證明了攻擊實施成功。

圖 5驗證結果

02

漏洞原理分析

這個漏洞是結合了歷史問題實現了遠程命令執行，具體概括有繞過黑名單、RMI與反射機制這三點：

(1)繞過黑名單

Oracle經常採用「黑名單」的方式對Weblogic的漏洞進行修復，Weblogic的歷史CVE如圖6所示。事實證明，如果「黑名單」設置得不夠完備，就可能被攻擊者繞過。

圖 6 Weblogic的歷史CVE

(2)RMI

RMI是Remote MethodInvocation的簡稱，是Java SE的一部分，能夠讓程序員開發出基於Java的分散式應用。一個RMI對象是一個遠程Java對象，可以從另一個Java虛擬機上（甚至跨過網路）調用它的方法，可以像調用本地Java對象的方法一樣調用遠程對象的方法，使分布在不同的JVM中的對象的外表和行為都像本地對象一樣。

RMI傳輸過程都使用序列化和反序列化，如果RMI服務端埠對外開發，並且服務端使用了像Apache Commons Collections這類包含反序列化漏洞的庫，則會導致遠程命令執行。

RMI依賴於Java遠程消息交換協議JRMP（Java Remote Messaging Protocol），該協議為Java定製，要求服務端與客戶端都為Java編寫。

(3)反射機制

Java反射機制是在運行狀態中，對於任意一個類，都能夠知道這個類的所有屬性和方法；對於任意一個對象，都能夠調用它的任意一個方法和屬性；這種動態獲取的信息以及動態調用對象的方法的功能稱為Java語言的反射機制。

接下來從「繞過黑名單」「RMI」與「反射機制」等角度對該漏洞的利用原理進行分析。

(1)繞過黑名單，初步理解CVE-2018-2893的黑名單繞過方式

在看到CVE-2018-2893的漏洞信息時，可以感覺到該漏洞來自於對今年4月份的CVE-2018-2628的二次挖掘。而這兩個漏洞都對歷史的官方補丁所設置的黑名單進行了繞過。

圖7WeblogicFilterConfig.class的黑名單

關於對CVE-2018-2628的「黑名單繞過」的詳細分析，大家可以參閱《CVE-2018-2628：WeblogicRCE漏洞復現與分析筆記》。

現在著重來分析CVE-2018-2893的繞過方式，通過IDEA的Compare With功能來比較JRMPClient2893與JRMPClient2的代碼，如圖8所示。

圖8比較JRMPClient2893與JRMPClient2的代碼

接著，對「CVE-2017-3248的payload」（對應「cve-2017-3248.poc.ser」）、「CVE-2018-2628的payload」（對應「cve-2018-2628.poc.ser」）以及「CVE-2018-2893」的payload（對應「cve-2018-2893.poc.ser」）進行比較，如圖9所示。

圖9CVE-2017-3248、CVE-2018-2628以及CVE-2018-2893的payload

在上圖中對比CVE-2017-3248與CVE-2018-2628的payload，可以觀察到CVE-2018-2628所用的「用Activator替代Registry」的繞過方式。並且，3組payload均出現了以下的RMI調用方式：

但同時，也產生了兩個疑問：

(2)在針對CVE-2018-2628的補丁中，已經將UnicastRef放入黑名單了，而「CVE-2018-2893」的payload中還有UnicastRef，為什麼該payload還能攻擊成功呢？

對於第1個疑問，有安全團隊曾經指出了針對於「CVE-2018-2628」的補丁繞過方式（結合CVE-2016-0638的利用方式與CVE-2017-3248的payload來繞過補丁），他們也將這一補丁繞過方式申請成了CVE-2018-2893。StreamMessageImpl這個點在反序列化的時候沒有被resolveProxyClass方法檢查。

所以可以使用StreamMessageImpl將RemoteObjectInvocationHandler序列化，以此來繞過resolveProxyClass方法。將JRMPClient生成的 payloadObject 用StreamMessageImpl封裝生成新的payload。

對於第2個疑問，有安全人員指出啟用Weblogic調試模式，利用上述payload進行攻擊，設置斷點跟蹤調試，可以發現如下反射鏈：

(2)RMI，為什麼攻擊機發送給靶機的payload可以觸發遠程方法調用？

首先來看攻擊機進行攻擊的命令：

這條命令向靶機的T3服務（192.168.1.106:7001）發送由ysoserial-0.1-cve-2018-2893-all.jar中的JRMPClient2893生成的payload（JRMPListener為192.168.1.129:1099）。這個payload可以在靶機繞過Weblogic的黑名單限制，並在靶機與攻擊機之間建立「JRMPClient與JRMPListener之間的的遠程方法調用」，即在靶機反序列化RemoteObjectInvocationHandler，它會利用UnicastRef建立到攻擊機的TCP連接，以獲取RMI Registry，載入回來再利用readObject解析，從而造成反序列化遠程代碼執行。

(3)反射機制，為什麼可利用CommonsCollections1來做PoC?

首先來看開啟JRMPListener的命令：

這裡利用了ysoserial的CommonsCollections1，因為weblogic依賴的jar包包含了CommonsCollections 3.2.0。所以可以在解壓Weblogic的dev版本wls1036_dev.zip後，找到CommonsCollection的文件路徑，如圖10所示。

圖10 Weblogic包含了CommonsCollections的jar包

Apache CommonsCollection的InvokerTransformer類和ChainedTransformer類彷彿引發攻擊的導火索。而AnnotationInvocationHandler彷彿火花。

該漏洞的原理示意圖如圖11所示。

圖 11 Apache commonscollection 反序列化漏洞原理示意

有很多大牛已經對CommonsCollections的經典漏洞進行過詳細分析了，在此不做詳細的敘述。

03

漏洞修復方案

1、廠商修復方案

Oracle官方已經在2018年7月18日的關鍵補丁更新（CPU）中修復了該漏洞，強烈建議受影響的用戶儘快升級更新進行防護。

鏈接：

2、安全狗解決方案

(1) 控制T3協議的訪問

此漏洞產生於WebLogic的T3服務，因此可通過控制T3協議的訪問來臨時阻斷針對該漏洞的攻擊。當開放WebLogic控制台埠（默認為7001埠）時，T3服務會默認開啟。

具體操作如下：

圖12在Weblogic控制台控制T3協議的訪問

(2) 建議用戶將JDK升級到 jdk-8u20以上的版本

04

總結

針對該漏洞的攻擊方式正與歷史問題息息相關。

比如，在「繞過黑名單」方面，漏洞的發現者很可能通過反編譯與文件比對等方式分析官方的歷史補丁以及Web應用所依賴的類庫 ，以快速找到修改了哪段代碼，判斷修改的部分是不是已成功修補了這個漏洞或者未公開的漏洞，也可以根據這個方法快速找到漏洞的位置。此外，可以對歷史漏洞的攻擊方式與繞過方式進行組合，以尋找繞過方式或風險點。補丁的發布者也應對歷史問題引起重視，可對引發漏洞的類庫做重點研究，以使黑名單更加完備；

在「RMI」方面，目前已有多個Java反序列化漏洞利用該技術進行漏洞的觸發。比如2016年的「Spring 框架的反序列化漏洞」；

在「反射機制」方面，幾乎所有的開發框架以及應用技術都是基於反射技術的應用。「反射技術」可以對惡意代碼的意圖進行掩蓋。比如2015年的「Java Apache-CommonsCollections反序列化漏洞」。

在今後的漏洞研究中，我們實驗室會更加關注歷史問題。以下附上本次漏洞分析中所涉及到的歷史同類漏洞相關情況。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！