JAVA RMI 反序列化攻击 & JEP290 Bypass分析

入门了反序列化之后对RMI、JNDI、LDAP、JRMP、JMX、JMS这些都不了解，所以打算一个问题一个问题的解决它们，这这篇专注于RMI的学习，从RPC到RMI的反序列化再到JEP290都过了一遍。参考了很多很多师傅的文章，如果有写的不对的地方还望师傅们不吝赐教。

RPC（Remote Procedure Call）远程过程调用，就是要像调用本地的函数一样去调远程函数。它并不是某一个具体的框架，而是实现了远程过程调用的都可以称之为RPC。比如RMI(Remote Method Invoke 远程方法调用)就是一个实现了RPC的JAVA框架。

RPC的演化过程可以看这个视频进行了解：https://www.bilibili.com/video/BV1zE41147Zq

对于视频里面实现RPC的方式我画了一个简单的流程图来理解：

Client如果想要远程调用一个方法，就需要通过一个Stub类传递类名、方法名与参数信息给Server端，Server端获取到这些信息后会从本地服务器注册表中找到具体的类，再通过反射获取到一个具体的方法并执行然后返回结果。

代理模式

代理模式是一种设计模式，提供了对目标对象额外的访问方式，即通过代理对象访问目标对象，这样可以在不修改原目标对象的前提下，提供额外的功能操作，扩展目标对象的功能。

Proxy在Client直接调用DoAction()中间加了一层处理，正是这层处理扩展了对象的功能。

静态代理

这种代理方式需要代理对象和目标对象实现一样的接口。

例子如下：

可以看到，在不修改原来对象功能的前提下，在调用方法前后增加了功能。但是这种代理模式有很一些缺点：

动态代理

动态代理利用JAVA中的反射，动态地在内存中构建代理对象，从而实现对目标对象的代理功能。动态代理又被称为JDK代理或接口代理。动态代理对象不需要实现接口，但是要求目标对象必须实现接口，否则不能使用动态代理。

参考文章

定义：

RMI（Remote Method Invocation）为远程方法调用，是允许运行在一个Java虚拟机的对象调用运行在另一个Java虚拟机上的对象的方法。 这两个虚拟机可以是运行在相同计算机上的不同进程中，也可以是运行在网络上的不同计算机中。

Java RMI：Java远程方法调用，即Java RMI（Java Remote Method Invocation）是Java编程语言里，一种用于实现远程过程调用的应用程序编程接口。它使客户机上运行的程序可以调用远程服务器上的对象。远程方法调用特性使Java编程人员能够在网络环境中分布操作。RMI全部的宗旨就是尽可能简化远程接口对象的使用。

JAVA中RMI的简单例子：

Server端

定义一个远程接口：User.java

在Java中，只要一个类extends了java.rmi.Remote接口，即可成为存在于服务器端的远程对象。其他接口中的方法若是声明抛出了RemoteException异常，则表明该方法可被客户端远程访问调用。

JavaDoc描述：Remote 接口用于标识其方法可以从非本地虚拟机上调用的接口。任何远程对象都必须直接或间接实现此接口。只有在“远程接口” （扩展 java.rmi.Remote 的接口）中指定的这些方法才可被远程调用。

远程接口实现类：UserImpl.java

远程对象必须继承java.rmi.server.UniCastRemoteObject类，这样才能保证客户端访问获得远程对象时，该远程对象将会把自身的一个拷贝以Socket的形式传输给客户端，此时客户端所获得的这个拷贝称为“存根”，而服务器端本身已存在的远程对象则称之为“骨架”。其实此时的存根是客户端的一个代理（Stub），用于与服务器端的通信，而骨架也可认为是服务器端的一个代理（skeleton），用于接收客户端的请求之后调用远程方法来响应客户端的请求。

这个Stub和RPC同理，Skeleton可以理解为是服务端的Stub。

服务端实现类：UserServer.java

这个类的作用就是注册远程对象,向客户端提供远程对象服务。将远程对象注册到RMI Service之后，客户端就可以通过RMI Service请求到该远程服务对象的stub了，利用stub代理就可以访问远程服务对象了。

Naming类的介绍：

Client端

UserClient.java

RMI测试

先启动UserServer.java，再启动UserClient.java：

同时在服务端：

直接使用Registry实现的RMI

除了使用Naming的方式注册RMI之外，还可以直接使用Registry实现。代码如下：

Server端：

Client端：

总结

根据RMI的整个过程画出一个的流程图如下:

Java远程方法协议（英语：Java Remote Method Protocol，JRMP）是特定于Java技术的、用于查找和引用远程对象的协议。这是运行在Java远程方法调用（RMI）之下、TCP/IP之上的线路层协议（英语：Wire protocol）。

简单理解就是：JRMP是一个协议，是用于Java RMI过程中的协议，只有使用这个协议，方法调用双方才能正常的进行数据交流。

文章在Bypass JEP290部分有提到JRMP端，是指实现了JRMP接收、处理和发送请求过程的服务。

Registry的获取有两种方式分别是LocateRegistry.createRegistry和LocateRegistry.getRegistry。通过这两种方式对注册中心操作的流程也不一样，如bind、rebind、lookup等。这里把两种不同的方式称作本地操作注册中心和远程操作注册中心。下面通过分析这两种方式的调用过程来了解序列化和反序列化在其中是怎么起作用的，为后面反序列化漏洞的分析作铺垫。

java.rmi.registry 公共接口注册表

注册表是一个简单的远程对象注册表的远程接口，该注册表提供了用于存储和检索绑定有任意字符串名称的远程对象引用的方法。 bind，unbind和rebind方法用于更改注册表中的名称绑定，而lookup和list方法用于查询当前名称绑定。 在其典型用法中，注册表启用RMI客户端引导程序：它为客户端提供了一种简单的方法来获取对远程对象的初始引用。因此，通常使用众所周知的地址（例如，众所周知的ObjID和TCP端口号）导出注册表的远程对象实现（默认值为1099）。

测试代码：

根据createRegistry源码的调用流程，流程图及调用栈如下，其中各种参数的传递这里就不分析了。

处理请求：

需要特别注意的就是这里真正处理请求的部分，以bind操作为例，这里对var3这个变量进行了判断，并根据不同的数字进行不同的处理，最终调用var6.bind进行绑定，最终把服务绑定在this.bingdings上。其中var3对应关系如下：

从上图过程中也可以看出来，这里对传入的对象进行了一个反序列化的处理。那如果传入的内容是一个恶意对象的话，就可能造成反序列化漏洞。

这里再看一下如果是使用LocateRegistry.createRegistry本地获取了注册中心之后，直接绑定服务是什么流程。跟一下就可以看到过程比较简单，经过了一个checkAccess的检测之后就把服务加入了this.bindings里了。(上面对请求处理也会调用到这个方法）

这里的checkAccess就是为了检查绑定时是否是在同一个服务器上。

在低版本的JDK中，Server与Registry是可以不在一台服务器上的，而在高版本的JDK中，Server与Registry只能在一台服务器上，否则无法注册成功。

在LocateRegistry.createRegistry的流程图中可以看到，注册中心对端口进行了监听并接受与处理请求。接着再来看通过LocateRegistry.getRegistry来远程获取注册中心与请求数据的流程是怎么样的。

首先通过LocateRegistry.getRegistry获取到的是RegistryImpl_Stub对象：

跟入bind方法：

把传入的服务名称和对象都进行反序列化传递给类型为ObjectOutput的var4变量。并通过invoke方法传递到Server的Registry那边进行处理。来看一下newCall方法：

这里传递进来的var3为0，继续传入到了new StreamRemoteCall里：

最后将这个var3发送到服务端那边进行处理。

以这个bind为例，所以远程绑定的流程就是：

同样画出流程图如下：

在这个过程中，存在一个序列化和反序列化的过程，所以存在反序列化漏洞的风险。

测试代码：

通过lookup获取到的是一个Proxy代理对象：

跟入调用name的过程，到了invoke方法处，会调用invokeRemoteMethod方法：

这里传入了所调用的代理、方法名、参数和method的hash值到this.ref.invoke方法中。this.ref中包含了远程服务对象的各类信息，如地址与端口、ObjID等。

invoke函数里就是对这些数据进行处理(参数会序列化)发送到Server端那边。具体这里就不再跟入了。

再来看看Server那边是怎么处理传过来的数据的，Server端处理Client端传递过来的数据在 调用栈如下：

sun/rmi/server/UnicastServerRef.class#dispatch

这里会对传递过来的参数进行反序列化，再使用反射调用方法。我们来看下unmarshalValue方法：

在Client端有一个对应的marshalValue，是为了序列化参数。

总结一下调用过程：Client端通过Stub代理将参数都序列化传递到Server端，Server端反序列化参数通过反射调用方法获取结果返回。当然如果返回的内容是一个对象的话，返回后同样会进行反序列化过程。

接着来看不同的场景下的反序列化利用：

根据不同场景下的攻击画出的流程图如下：

四种攻击的方式的利用过程如下：

服务端和客户端攻击注册中心的方式是相同的，都是远程获取注册中心后传递一个恶意对象进行利用。

根据之前我们的分析，远程调用bind()绑定服务时，注册中心会对接收到的序列化的对象进行反序列化。所以，我们只需要传入一个恶意的对象即可。这里用的是Common-Collection3.1的poc作为例子：

这里有一个需要注意的点就是调用bind()的时候无法传入AnnotationInvocationHandler类的对象，必须要转为Remote类才行。这里使用了下面的方式进行转换：

AnnotationInvocationHandler本身实现了InvocationHandler接口，再通过代理类封装可以用class.cast进行类型转换。又因为反序列化存在传递性，当proxyEvalObject被反序列化时，evalObject也会被反序列化，自然也会执行poc链。（存在疑问：为什么要用代理类封装才行？）

Remote.class.cast可以参考：关于JAVA中的Class.cast方法 这个方法的作用就是强制转换类型。 反序列化过程参考：序列化和反序列化

除了bind()操作之外，rebind()也可以这样利用。但是lookup和unbind只有一个String类型的参数，不能直接传递一个对象反序列化。得寻找其他的方式。

unbind的利用方式跟lookup是一样的。这里以lookup为例。

注册中心在处理请求时，是直接进行反序列化再进行类型转换，转换流程如图所示：

如果我们要控制传递过去的序列化值的话，不能直接传递给lookup这个方法，因为它的参数是一个String类型。但是它发送请求的流程是可以直接复制的，只需要模仿lookup中发送请求的流程，就能够控制发送过去的值为一个对象。

构造出来的POC如下：

可以看到，即使报了字符转换的error，还是利用成功了。

除了这种伪造请求，还可以rasp hook请求代码，修改发送数据进行利用，现在还没接触过rasp，就先不复现了。

从上面的代码中也可以看出来，客户端和服务端与注册中心的参数交互都是把数据序列化和反序列化来进行的，那这个过程中肯定也是存在一个对注册中心返回的数据的反序列化的处理，这个地方也存在反序列化漏洞风险。(详细分析可以看Bypass JEP290部分)

可以用ysoserial生成一个恶意的注册中心，当调用注册中心的方法时，就可以进行恶意利用。

开启注册中心：

客户端测试代码：

执行了之后就可以看到命令执行成功了。

除了list()之外，其余的操作都可以进行利用：

例如bind()：

如果注册服务的对象接收一个参数为对象，那么可以传递一个恶意对象进行利用。比如这里可以传递一个Common-collection3.1反序列化漏洞poc构造出的一个恶意对象作为参数利用：

POC：

服务器端会执行命令：

跟客户端攻击服务端一样，在客户端调用一个远程方法时，只需要控制返回的对象是一个恶意对象就可以进行反序列化漏洞的利用了。这里我在原来RMI测试例子的基础上加了一个getwork()方法。

UserImpl.java

开启Server之后，在Client端调用getwork()方法即可以攻击成功。

JEP290是来限制能够被反序列化的类，主要包含以下几个机制：

JEP290支持的版本：

JEP290需要手动设置，只有设置了之后才会有过滤，没有设置的话就还是可以正常的反序列化漏洞利用。所以如果是Client端和Server端互相攻击是没有过滤的。

设置JEP290的方式有下面两种：

测试环境：

pom.xml

测试例子：

在创建注册中心过程中存在一个setObjectInputFilter的过程，因此在客户端(这里代表Server和Client端)攻击注册中心过程中会被过滤。比如这里我给注册中心绑定了一个Common-collection5的恶意对象，结果是报错了，报错信息为：filter status REJECTED。说明传入的恶意对象被拦截了。

接着来跟一下注册中心创建的流程，看看setObjectInputFilter的过程到底是怎么样的。

首先到了RegistryImpl方法处，可以看到，实例化UnicastServerRef时第二个参数传入的是RegistryImpl::registryFilter。传入之后的值赋值给了this.Filter

看一下registryFilter这个方法：

这里的registryFilter默认为null，可以先不管这个判断，后面返回的内容相当于配置了一个白名单，当传入的类不属于白名单的内容时，则会返回REJECTED，否则就会返回ALLOWED。白名单如下：

在bind()操作请求后，注册中心的接收端会调用oldDispatch方法，文件地址：jdk1.8.0_131.jdk/Contents/Home/jre/lib/rt.jar!/sun/rmi/server/UnicastServerRef.class。最终是会去调用this.skel.dispatch去绑定服务的。在这句之前有一个this.unmarshalCustomCallData(var18);跟入进去看看。

可以看到在这里调用了Config.setObjectInputFilter设置了过滤。UnicastServerRef.this.filter就是之前实例化UnicastServerRef时所设置的。规则就是之前所说的白名单，不属于那个白名单的类就不允许被反序列化。

那这个过程其实就是Registry在处理请求的过程中设置了一个过滤器来防范注册中心被反序列化漏洞攻击。有过滤就有绕过，这里的绕过方式是什么样的呢？

UserServer.java

TestClient.java