Java 安全之反序列化漏洞

1.序列化与反序列化：

序列化与反序列化对于 Java 程序员来说，应该不算陌生了，序列化与反序列化简单来说就是 Java 对象与数据之间的相互转化。

那么对于完全面向对象的 Java 语言来说为什么要有序列化机制？

实质上，序列化机制并不只局限于 Java 语言，序列化的本质是内存对象到数据流的一种转换，我们知道内存中的东西不具备持久性，但有些场景却需要将对象持久化保存或传输。例如缓存系统中存储了用户的 Session，如果缓存系统直接下线，带系统重启后用户就需要重新登陆，为了使缓存系统内存中的 Session 对象一直有效，就需要有一种机制将对象从内存中保存入磁盘，并且待系统重启后还能将 Session 对象恢复到内存中，这个过程就是对象序列化与反序列化的过程，从而避免了用户会话的有效性受系统故障的影响。

此外，在 Java 工程中，序列化还广泛应用于 JMX，RMI，网络传输（协议包对象）等场景，可以说序列化机制赋予了内存对象持久化的机会，就像虚拟机镜像（VMware Take a snapshot），也可以将序列化机制看作是内存对象的一种镜像机制。

在 Java 中，只要一个类实现了 java.io.Serializable 接口，那么它就可以通过 ObjectInputStream 与 ObejctOutputStream 序列化，如下我们模拟了 Session 对象持久化存储与从磁盘加载的过程：

结合注释，这段测试代码应该不难理解，我们可以看到 Java 对象序列化就依赖于 ObejctOutputStream 的 writeObject 方法，而反序列化是由 ObjectInputStream 的 readObject 方法实现的，下图是作者画的一个序列化示意图：

2.反序列化漏洞成因

2015 年年底，由公共依赖库 Apache Common Collections 引起的 Java 任意命令执行漏洞的严重安全问题，使得 Java 反序列化漏洞逐渐进入了安全研究人员的视野（在此之前存在，但并未被重视），而任意命令执行的成因正是前文反序列化操作的 ObejctInputStream 类的 readObject 方法触发的。

Java 序列化机制虽然有默认序列化机制，但也支持用户自定义的序列化与反序列化策略。例如对象的一些成员变量没必要序列化保存或传输，就可以不序列化，或者也可以对一些敏感字段进行处理等自定义对象序列化的行为，而自定义序列化规则的方式就是重写 writeObejct 与 readObject。当对象重写了 writeObejct 或 readObject方法时，Java 序列化与反序列化就会调用用户自定义的逻辑了，下图示例我们对 Session 对象重写了序列化处理函数：

OK，到目前为止一切都在程序员的掌控之中！何来的漏洞之说？

呵呵，意外往往就发生在不经意之间，如果反序列化过程中提供了命令执行的机会，那么任意命令执行漏洞就产生了，如下我们在 Session 对象的 readObject 函数中增加了执行命令的代码：

此时，黑客只需要将 Session 对象的 sessionId 构造成想要执行的命令字符串，即可实现远程命令执行的功能，如下成功打开系统 calc.exe 进程：

好了，我们再来梳理一下上例中漏洞存在的条件与利用思路：

条件：

首先 Session 对象重写了反序列化函数 readObject，并且 readObject 方法存在执行命令的机会。

漏洞利用：

正常的反序列化流程会重新生成一个正常 Session 对象，而恶意的序列化数据抓住了反序列化的漏洞执行命令的机会，精心构造了序列化对象，使得数据流反序列化的过程中恶意命令得以执行。

看到这里，作为程序员的你肯定哈哈大笑！对象的反序列化函数谁会这样写？

当然本示例只是为了以最直观的方式演示反序列漏洞产生原因，就直接提供了一个 HelloWorld 级别的漏洞示例.

实际上，近两年 Java Apache-CommonsCollections 造成的序列化漏洞与 Spring 框架的反序列化漏洞（spring-tx.jar）的成因与原理都与上例相似，只是漏洞利用的构成比较复杂而已。

3.Java Apache-CommonsCollections RCE 漏洞解析

该漏洞曝光于 2015 年年底，被誉为当年“最被低估了的漏洞”，利用思路一经爆出，各大 Java web 厂商纷纷躺枪，受此影响的 Web 服务器有：WebLogic、WebSphere、JBoss、Jenkins、OpenNMS等。

介于该漏洞曝光距今已经有两年之久，并且网上也有对此分析的很透彻的文章，本文就来讲一下这个可以通过精心构造触发命令执行的漏洞的要点。该漏洞的主要问题就出现在 org.apache.commons.collections.Transformer 接口上，在 Apache-CommonsCollections 包中，有一个 InvokerTransformer 类实现了 Transformer 接口，并且 InvokerTransformer 这个类也很恰巧，InvokerTransformer 的 transform 方法提供了一个可以通过 Java 反射机制，调用任意 Java 方法的机会：

相信很多漏洞利用者对 invoke 非常敏感，意味着提供了方法调用的机会，再结合方法名与参数都能通过 InvokerTransformer 构造函数来控制，因此该类一定是漏洞挖掘者反复徘徊的地方。那该怎么利用？

InvokerTransformer 结合 ChainedTransformer 就能构造一个 Java 类加载函数调用链，POC 的作者是如下构造的：

这样构造的原因在于 ChainedTransformer 的 transform 函数会依次调用数组中 InvokerTransformer 的 transform 函数，构成一个函数调用链，下图是调试状态下，ChainedTransformer 的 transform 方法的变量状态：

可以看到，通过 ChainedTransformer.transform 的构造相当于反射调用了 Runtime.getRuntime().exec()，触发了命令的执行。

OK，那么问题来了，谁去触发调用 ChainedTransformer.transform 函数呢？

漏洞利用者找到了包中 TransformedMap.checkSetValue() 方法：

这样一来，POC 就可以通过构造一个 TransformedMap 对象，然后再想办法触发 checkSetValue 函数即可，而 TransformedMap 在 Apache-CommonsCollections 这个集合库中可以通过 TransformedMap.decorate 修饰器方法来修饰一个 Map 对象，而 Map 对象在反序列化是只需调用 MapEntiry.setValue 就能触发 checkSetValue 函数，进而进一步触发第一步构造的 ChainedTransformer.transform方法，从而实现漏洞利用的目的。

以上就是 Apache-CommonsCollections RCE 漏洞的利用思路，该漏洞的实质是 Apache-CommonsCollections 为利用者提供了一系列可以构造行命令机会。

但是聪明的你一定会问，上面的漏洞触发条件并不是在反序列化函数 readObject 中实现的，怎么能在反序列化中触发 POC 的执行？

好问题！思路是这样的，可以找到一个这样的对象：

1.该类自定义重写了 readObejct 反序列化函数。

2.readObecjt 方法中调用了 Map 的 checkSetValue 函数，并且该 Map 对象还可以通过构造函数构造。

呵呵，我知道，你又开始笑！的确条件比较苛刻，也难怪该漏洞在 2015 年初没有被重视起来，但是老外还就给你在 JDK 中找到了一个满足条件的的对象--sun.reflect.annotation.AnnotationInvocationHandler。好了，废话不多说，来看一下的 AnnotationInvocationHandler 的反序列化函数满不满足触发要求：

因为 setValue 函数会调用 checkSetValue：

从而在 sun.reflect.annotation.AnnotationInvocationHandler 对象反序列化时，就满足了 ChainedTransformer、TransformerMap构造的 POC 触发的条件，最后我们给出完整的构造 Apache CommonCollections 反序列化漏洞利用POC的代码（来自网络）：

小伙伴们看到这里可能一头雾水了，作者这里借用斗象科技在分析该漏洞时画的一幅漏洞POC构造触发流程图，再来梳理一下漏洞利用的思路：

因此 POC 的流程为：TransformedMap->AnnotationInvocationHandler.readObject()->setValue()->checkSetValue() 最后由反序列化 readObject 时触发执行。

的确，该漏洞的触发方法与构造思路非常精妙，不得不佩服这位写出 POC 的老外。

4.如何防范：

首先，开发者要有安全意识，应该清楚项目使用到的组件是否有漏洞存在，虽然说 Apache-CommonsCollections RCE 漏洞曝光将近两年了，但使用存在漏洞的 3.2.2 之前版本的 web 服务框架依然存在，Apache James 3.0.0 版本的 CVE-2017-12628 漏洞就是还在使用 commons-collections-3.2.1.jar 造成的。

不过安全意识，很多开发者不是没有，而是没有接触过，作者在一个使用 struts 框架的团队待过，他们写出的代码真的是 Web 漏洞一箩筐啊。

可以禁用 JVM 执行外部命令（Runtime.exec），因为 Runtime.exec 对于大多数 Java 正常应用来说是不会用到的，但是确是黑客控制Web服务后运行命令的重要方法，因此该手段是 Java Web 防护常用的且有效的手段，如果从攻击者角度看这种防护效果，那就是攻击工具 webshell 只能文件相关操作，无法执行命令。可以通过扩展 SecurityManager 来禁用 Runtime.exec，当触发运行时还可加入报警逻辑，启动应急响应：

5.反序列化漏洞的其他思考：

作者认为反序列化漏洞的利用应该更为广泛，思路不应该仅仅局限于远程命令执行漏洞的利用，也存在着系统数据篡改污染的危险，造成系统业务安全问题。

例如序列化对象在系统中承担了账单、金额、认证、鉴权等职责，如果可以被反序列化利用，后果也非常严重。

这样的威胁不亚于命令执行的威胁，并且事后难于排查，因为是内存攻击，载荷不落地。

所以，反序列化对于业务安全的威胁也是我们一个值得深思的问题。