前言

在java的学习过程中,少不了对 ysoserial 的使用和学习,这里记录了整个 JRMP 相关的分析,分享出来,有什么地方不对的请大哥们直接喷就对了 ; )

简介

这个 JRMPListener 是 ysoserial 工具里的其中一个利用模块,作用是通过反序列化,开启当前主机的一个 JRMP Server ,具体的利用过程是,将 反序列化数据 发送到 Server 中,然后 Server 中进行反序列化操作,并开启指定端口,然后在通过 JRMPClient 去发送攻击 payload

流程

其实触发流程已经在 playloads/JRMPListener 里写出来了,如下:

被序列化的类是 ActivationGroupImpl ,反序列化的也是他,里面包括了RemoteObject(构造函数) 、 RemoteRef(构造函数的参数类型) 、 UnicastServerRef(构造函数的具体参数)

RemoteObject 的构造函数(paramType为RemoteRef)是最先被创建的,UnicastServerRef 是最后在返回 ActivationGroupImpl 实例的时候被使用的 sc.newInstance( UnicastServerRef )

平日里接触到的反序列化利用不都是,要么重写了 readObject ,要么像是 RMI 的利用那样,利用 Proxy 类中一个 InvocationHandler 成员的反序列化过程来实施攻击( invacationHandler 其实可以指定为那个 AnnotationInvocationHandler 的),那么这里的 JRMP 又是咋回事的.....感觉完全没有以上两者的影子

他用 ActivitionGroupImpl 来当做想要得到的对象,原因是为了得到一个 UnicastRemoteObject,跟踪了一下, UnicastRemoteObject 只有几个子类:

最合适的当然是 ActivationGroupImpl,其次,真正关键的流程在于 UnicastRemoteObject 的 readObject 函数和 reexport 函数,他会把接收到的序列化的 UnicastRemoteObject 类进行反序列化,并且重新 export 出去

在 UnicastServerRef 的 exportObject 中已经后续流程里,就是在研究 RMI 过程中的服务端开启监听端口的整个流程

简单来说,最主要的是 UnicastRemoteObject 自己实现了 readObject ,并且将会重新开启 JRMP 的监听服务,反序列化利用的就是这一点,然后 UnicastRemoteObject 的直接子类(同一路径下)是 ActivationGroupImpl , 所以要先得到 ActivationGroupImpl 的一个实例,并且将其序列化,设置的端口是单独设置的

然后感觉这个 port 的设置,主要在于这一句:

但是我把payload 的生成方式改了一下,不使用 UnicastRemoteObject 的子类 ActivationGroupImpl ,直接使用 UnicastRemoteObject 也是可以反序列化后监听端口成功的

分析总结

payloads/JRMPListener
利用的是 UnicastRemoteObject 里的 readObject 函数,在其反序列化的时候,此 readObject 函数会被调用

其中 UnicastServerRef 的 exportObject 函数就是之前研究过的 RMI 的 RMI Server 端的东西,后面的触发流程在 RMI 的相关笔记里有

然后就是依靠 newConstructorForSerialization 函数创建出的 UnicastRemoteObject ,其需要的参数有四,其一是需要得到的对象类,其二是需要得到的类的构造函数所在的类(第一个条件的父类),其三是所需要的构造子的参数类型(便于从父类中查找对应的构造函数),其四就是构造函数所需的具体参数

在 JRMPListener 中,第一个参数使用的是 ActivationGroupImpl ,对其跟踪后发现,本身就是利用的 UnicastRemoteObject 的 readObject 函数,所以将第一参数改为 UnicastRemoteObject 也未尝不可,第二个参数不能乱选,满足两个条件,一要为 UnicastRemoteObject 的父类,二要不能在创建的过程中有其他什么多余的操作,满足这两个条件的两个类是:RemoteObject、RemoteServer,通过实验发现,使用这两个类没啥区别....第三个参数和第四个参数都是根据第二个参数来的,所以不做解析

最后,序列化的是 UnicastRemoteObject 或者是其子类,并将其 port 属性设置为想要开通的端口值,那么发送到目标主机后,经过其反序列化就会发现,UnicastRemoteObject 的 readObject 被调用了,然后紧跟着调用了 reexport 函数.....

其实这么来看的话,还是不偏离反序列化那两个利用的条件(满足其一即可)

  1. 一个将要被反序列化的类其中的成员是一个 gadget ,在反序列化的时候调用了它的自定义 readObject .... 例子: RMI 的反序列化 payload
  2. 将要被反序列化的类自己或者是其父类中,有自定义过 readObject 的情况,并且 readObject 可以用来搞事情..... 例子: AnnotationInvocationHandler 的利用,还有这个 JRMPListener 的利用,都是要么自己实现了 readObject 函数,要么父类实现了这个函数,并且在函数中可以达到某些目的

一个小问题

这里有个疑问,既然 RMI 也是根据 JRMP 实现的,那么能不能使用 RMI Client 去打 payload 呢(指的是向目标机发送 exploit/RMIRegistryExploit ,然后自己服务器挂起 exploit/JRMPListener)

问题答案

应该是可以的,因为 exploit/JRMPListener 利用的是,最终 client 里接受 server 端反馈的异常,JRMPListener 是将 payload 写入了反馈异常中的一个成员变量里的.....

不过呢,在本地测试中,并没有弹出计算器,有点问题如下:

显然,目标机中报错了,但是明明这个 BadAttributeValueExpException 就是 exploit/JRMPListener 构造的呀,应该是已经反序列化成功了

经过测试,不使用 ysoserial 里的 RMIRegistryExploit ,我自己去写一个 rmi 的时候,也会弹出计算器

n1nty 师傅说是 java 沙盒的原因,查看 ExecCheckingSecurityManager 里的 checkExec,限制了命令执行

那么意思就是,如果直接使用自定义的 rmi 反序列化利用工具打过去,没有设置沙盒的话,可能会被人家反打一波........因为这个 JRMPListener 就是一个很好的例子,我开启一个监听端口后,等着你来打,然后反手就是一耳光......

点击收藏 | 0 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖