• 本文作者: 
  • |
  • 2020年12月14日
  • |
  • 未分类
  • |

Java反序列化系列 ysoserial Hibernate2

1.Hibernate简介

Hibernate是一个开放源代码的对象关系映射框架,它对JDBC进行了非常轻量级的对象封装,它将POJO与数据库表建立映射关系,是一个全自动的ORM框架,hibernate可以自动生成SQL语句,自动执行,使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。 Hibernate可以应用在任何使用JDBC的场合,既可以在Java的客户端程序使用,也可以在Servlet/JSP的Web应用中使用,最具革命意义的是,Hibernate可以在应用EJB的JaveEE架构中取代CMP,完成数据持久化的重任。

2.RPC简介

RPC(Remote Procedure Call)远程过程调用。允许一台计算机程序远程调用另外一台计算机的子程序,不用关心底层网络通信。

很多人对RPC的概念很模糊,其实RPC是建立在Socket的基础上的。通过Socket将对另一台计算机中的某个类的某个方法的请求同时包含该方法所需要传输的参数序列化传输过去,然后在另一台计算机接收后判断具体调用的哪个类的哪一个方法,然后通过反射调用该方法并传入参数,最终将方法的返回值序列化并通过Socket传输回发送方法调用请求的那台计算机上,这样的一个过程就是所谓的远程方法调用

一次RPC调用的过程大概有10步:

1.执行客户端调用语句,传送参数

2.调用本地系统发送网络消息

3.消息传送到远程主机

4.服务器得到消息并取得参数

5.根据调用请求以及参数执行远程过程(服务)

6.执行过程完毕,将结果返回服务器句柄

7.服务器句柄返回结果,调用远程主机的系统网络服务发送结果

8.消息传回本地主机

9.客户端句柄由本地主机的网络服务接收消息

10.客户端接收到调用语句返回的结果数据

以下是一张截取自网上的RPC执行流程图

1

接下来通过java代码来实现一个最简化的RPC Demo

先看一下文件结构首先是client端也就是发起远程方法请求的一方

2

然后是server端也就是处理远程方法请求的一方

3

首先看RpcPrincipleTestInterface接口,此接口是公开的,也就是这个接口文件是client端和server端中都存在的,接下来是RpcPrincipleTestInterface的代码

然后我们观察client端的RpcPrincipleClientTestimpl.java

下面是执行结果

4

可以看到我们执行了RpcPrincipleTestInterface接口中的方法但是我们在本地并未有任何RpcPrincipleTestInterface接口的具体实现?那这些个执行结果究竟是谁给出的呢?

我们通过观察代码不难发现,为rpcPrincipleTestInterface变量赋值的是Stub.getStub()方法,该方法的返回值被我们强转成了RpcPrincipleTestInterface类型。那Stub.getStub()方法的返回值究竟是什么我们继续深入来看

下面是Stub.java的代码

不难看出最终返回的结果是一个实现了RpcPrincipleTestInterface接口的动态生成的Proxy对象,传入的handler参数中包含了调用远程方法的核心操作。

首先熟悉java动态代理的同学都清楚,当我们调用动态代理对象的某个方法时,其实都是在调用InvocationHandler对象中被重写的invoke方法。所以当我们在RpcPrincipleClientTestimpl中调用rpcPrincipleTestInterface.myAdd()方法时本质调用的是InvocationHandler.invoke方法。同时方法名“myAdd”作为参数传入invoke中,我们首先创建一个socket对象将请求的地址和端口作为参数传入。然后获取方法名,接下来判断当前调用的方法是哪一个,判断完成后,将方法名,参数类型,还有参数的值序列化发送给server端,然后通过DataInputStream读取socket接收到的数据并反序列化,然后进行返回。

讲完了client端,我们再来看看server端,首先来看RpcPrincipleTestImpl.java的代码

我们看到RpcPrincipleTestInterface接口真正的实现类是RpcPrincipleTestImpl,那刚才我们究竟是怎么做到在client端调用了server端的RpcPrincipleTestImpl的呢?关键在于RpcPrincipleServerSkeleton这个类,我们观察下他的源码

在RpcPrincipleServerSkeleton中我们首先监听了8888端口,然后将Socket对象传入process方法中。process方法中接收客户端传的,调用方法的方法名,参数类型,以及参数值。按顺序将其反序列化出来然后通过反射调用RpcPrincipleTestImpl对象中的对应方法,然后将得到的返回值进行类型的判断,紧接着就将其进行序列化然后通过socket返回給client端,至此就是一个RPC的基础流程,我在这里演示的RPC demo可以说是简陋,真实的RPC框架背后的实现要比这复杂n倍,但是复杂归复杂,原理都是一样的。

3.RMI简介

介绍完了RPC,接下来就介绍一下RPC框架的一种实现,也就是RMI,直接通过代码来进行演示

先看一下远程方法调用方,也就是client端的目录结构

5

然后是远程方法服务提供方,也就是server端

6

RMITestInterface是一个公开接口,就像上一节所讲的,底层生成的代理类是需要实现该接口的,此公共接口一定要继承java.rmi.Remote接口,否则编译时会报错,以下是RMITestInterface的代码,

我们在RMIClientTest类中发起远程方法调用的请求,以下是RMIClientTest的代码

接下来就是server端的代码,首先我们看RMITestInterfaceImpl,可以看到该类实现了RMITestInterface接口,同时同学们应该也注意到该类继承了一个UnicastRemoteObject类,在RMI中如果一个类要绑定进行远程方法提供的话有两种方法,一就是继承UnicastRemoteObject类,第二种就是在实例化时通过调用UnicastRemoteObject.exportObject()静态方法来实例化该对象。

最后我们来看RMIServerTestImpl类,在该类里我们绑定了一个RMITestInterface对象来进行提供远程方法调用的服务

最后我们在client端执行RMIClientTest可得到以下结果

7

4.Hibernate2漏洞原理深度分析

整体漏洞的执行逻辑同Hibernate1并无太大差别,首先看一下ysoserial Hibernate封装恶意代码的逻辑,这次还是用了和上次一样的脑图,对其中利用到的不同的类进行了修改17

除了一开始被封装而且是用来最终执行代码的TemplatesImpl类变成了JdbcRowSetImpl类以外几乎没有什么变化了,也就是说前期的执行调用链是一样的。

为了方便大家理解就再把执行过程从头简述一遍。

首先反序列化我们最终封装完成的HashMap对象,自然会调用HashMap的readObject()方法,然后在readObject()方法的末尾有一个for循环,

18

由脑图可知这里的key和value对象存储的是同一个Type对象

19

20

接下来在putForCreate()方法里又调用的hash()方法

21

最终嵌套执行到BasicPropertyAccessor$BasicGetter的get()方法。22

这里调用了Method.invoke方法,我们看一下method变量和target的具体信息23

可以看到最终通过反射的方式调用了JdbcRowSetImpl.getDatabaseMetaData()方法,漏洞触发真正的重点从这里才开始和ysoserial Hibernate1有所不同。

我们跟进getDatabaseMetaData()方法,看到该方法同时调用了自身的connect方法,我们继续跟进

24

Var1.lookup(this.getDataSourceName())就是触发远程代码执行的罪魁祸首

25

但这么说大家肯定有人会不理解,为何这个函数会造成代码执行。

首先我们先看这个var1,var1是一个InitialContext对象,存在于javax.naming这个包中26

那么javax.naming这个包又是干什么的?我们百度一下就可以知道,这个包就是我们常听到的一个概念JNDI

关于JNDI的基础概念就不再过多赘述了

正如第3节内容所讲的RMI远程方法调用一样,JNDI功能中的一部分就是帮我们又封装了一下RMI,从而可以让我们更方便的实现远程方法调用。

下面用代码来复现这个漏洞的原理

首先是jndi client端

然后是一个恶意server端

紧接着是一个用来提供恶意类加载的一个简易http Server

最后就是我们包含有恶意代码的类了

可以看到在静态代码块中写有我们要执行的命令

我们先启动server端和http server。然后运行client端就可以出发命令执行27

这是为什么呢?在第三节中我们简单介绍了RMI,RMI可以进行远程方法调用,RMI还可以进行动态类加载,即可以从一个远程服务器以http://、ftp://、file://等形式动态加载一个.class文件到本地然后进行操作。但是这种RMI动态类加载的限制极大。有以下要求

  1. 由于Java SecurityManager的限制,默认是不允许远程加载的,如果需要进行远程加载类,需要安装RMISecurityManager并且配置java.security.policy,这在后面的利用中可以看到。
  2. 属性 java.rmi.server.useCodebaseOnly 的值必需为false。但是从JDK 6u45、7u21开始,java.rmi.server.useCodebaseOnly 的默认值就是true。当该值为true时,将禁用自动加载远程类文件,仅从CLASSPATH和当前虚拟机的java.rmi.server.codebase 指定路径加载类文件。使用这个属性来防止虚拟机从其他Codebase地址上动态加载类,增加了RMI ClassLoader的安全性。

我们使用JNDI同样可以进行动态类加载,而且限制相比于使用RMI要小很多。在jdk1.7.0_21版本我们可以不做任何配置直接进行远程class的加载。

但当jdk版本大于等于JDK 6u132、JDK 7u122、JDK 8u113 之后,系统属性 com.sun.jndi.rmi.object.trustURLCodebase、com.sun.jndi.cosnaming.object.trustURLCodebase的默认值变为false,即默认不允许RMI、cosnaming从远程的Codebase加载Reference工厂类。

我们更换jdk版本演示一下,可以看到jdk版本为1.8.0._221时会抛出com.sun.jndi.rmi.object.trustURLCodebase 为flase的异常

28

至此 ysoserial Hibernate2 漏洞原理分析完毕,感谢观看。

5.总结

此次漏洞利用的思路相较于之前的Hibernate1 主要变化在最终触发命令执行的类由TemplatesImpl类变成了JdbcRowSetImpl类,最终执行漏洞方式又由加载本地通过动态字节码生成的类从而触发其静态代码块中的恶意代码换成了通过RMI+JNDI+Reference, 然后最终由lookup()方法动态加载一个远程class文件从而触发其静态代码块中的恶意代码。

Written by