JAVA反序列化漏洞浅析

JAVA反序列化漏洞浅析

文章内容相关的POC已经上传至gitee需要自取
GITEE地址

工具

ysoserial

自动生成多种不同payload工具
src: https://github.com/frohoff/ysoserial
jar: https://jitpack.io/com/github/frohoff/ysoserial/master-SNAPSHOT/ysoserial-master-SNAPSHOT.jar

DeserializeExploit

一键自动攻击工具
jar:https://cdn.vulhub.org/deserialization/DeserializeExploit.jar

原理

java 反序列化

复现环境: jdk1.7u11 apache-common-collections-3.1

序列化就是把对象转换成字节流，便于保存在内存、文件、数据库中；反序列化即逆过程，由字节流还原成对象。Java中的ObjectOutputStream类的writeObject()方法可以实现序列化，类ObjectInputStream类的readObject()方法用于反序列化。下面是将字符串对象先进行序列化，存储到本地文件，然后再通过反序列化进行恢复

首先来了解下java下的序列化过程
如果某个类要能够进行序列化，那么这个类应该实现Serializable接口或者Externalizable接口之一。

序列化的使用步骤为

1. 创建一个ObjectOutputStream输出流
2. 调用ObjectOutputStream.writeObject

反序列化的使用步骤为

1. 创建一个ObjectInputStream输出流
2. 调用ObjectInputStream.readObject

特征: AC ED 00 05 开头

使用transient修饰的属性，java序列化时，会忽略掉此字段，所以反序列化出的对象，被transient修饰的属性是默认值。

java提供了可选的自定义序列化。可以进行控制序列化的方式，或者对序列化数据进行编码加密等。
通过重写writeObject与readObject方法，可以自己选择哪些属性需要序列化， 哪些属性不需要。如果writeObject使用某种规则序列化，则相应的readObject需要相反的规则反序列化，以便能正确反序列化出对象

序列化与反序列化，作为一种语言机制存在，本身并没有安全问题，安全问题在于，开发人员
在使用这种机制时，缺乏对信任边界的控制，举个简单例子，如果使用cookie存储登入进来的
用户信息，存储是一个java对象的序列化值，这个处于客户端的序列化值是攻击者完全可控的，
服务端在设计上如果缺乏对这个值的安全检查，直接对其进行反序列化，一定程度来说，客户端
就成功向服务端注入了代码，使用序列化传输的场景同样还有RMI服务，或是一些中间件，框架。

仅仅说服务端对一个恶意用户发送的序列化对象进行反序列化就算是注入了代码，似乎有点苛刻，
也无法直观能感受他到底对服务端带来了什么影响。让我们把视角移到如下场景

环境搭建为，jdk1.7u11，apache-common-collections-3.1
common-collections 是apache开源的第三方工具类库，大量使用在很多框架和中间件中，这套
库低版本中给出一个非常典型的反序列化漏洞利用方式

首先回到我们上面的问题，反序列化中所谓的代码注入，到底有哪些代码的执行是攻击者预料之内，
一个典型通用的方法是readObject，他是反序列化的必经之路，是一切问题的起点，好像是恶意攻击者的
main函数。 从攻击者的角度看，如果服务端存在一些类的声明(由于对服务器状态的不可知，一个好的方向就是关注，通用的框架或类库中的类)，
他们重写了readObject方法，通过提供其中某个对象序列化值给服务端进行反序列化，他至少可以
执行任意攻击者想要执行的readObject方法，尽管他也许无法进一步控制readObject中的内容。

那么问题就是，攻击者是否还有机会能控制readObject中的代码吗？答案是 有机会，apache-common-collections这个
广泛被使用的第三方库和jdk自身提供的类申明，为攻击者提供了思路。我们先来看看common-collections中的对象可以怎样
植入执行攻击者的准备好的代码。

Apache Commons Collections中有一个特殊的接口，其中有一个实现该接口的类可以通过调用Java的