java并发编程实战之基础知识（Java安全之反序列化漏洞分析）

java并发编程实战之基础知识（Java安全之反序列化漏洞分析）好了，我们再来梳理一下上例中漏洞存在的条件与利用思路：此时，黑客只需要将Session对象的sessionId构造成想要执行的命令字符串，即可实现远程命令执行的功能，如下成功打开系统calc.exe进程：研究人员的视野（在此之前存在，但并未被重视），而任意命令执行的成因正是前文反序列化操作的ObejctInputStream类的readObject方法触发的。Java序列化机制虽然有默认序列化机制，但也支持用户自定义的序列化与反序列化策略。例如对象的一些成员变量没必要序列化保存或传输，就可以不序列化，或者也可以对一些敏感字段进行处理等自定义对象序列化的行为，而自定义序列化规则的方式就是重写writeObejct与readObject。当对象重写了writeObejct或readObject方法时，Java序列化与反序列化就会调用用户自定义的逻辑了，下图示例我们对Session对象重写了序列

Java序列化与反序列化

序列化与反序列化对于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方法实现的，下图是作者画的一个序列化示意图：

反序列化漏洞成因

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）的成因与原理都与上例相似，只是漏洞利用的构成比较复杂而已。

Apache-CommonCollections REC 漏洞解析

该漏洞曝光于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构造函数来控制，因此该类一定是漏洞挖掘者反复徘徊的点。那该如何利用？在commons-collections包中，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构造与触发流程图，小伙伴们可以借此再来梳理一下该漏洞利用的思路：

因此，POC的触发流程为：TransformedMap->AnnotationInvocationHandler.readObject()->setValue()->checkSetValue() 最后由反序列化readObject时触发执行。的确，该漏洞的触发方法与构造思路非常精妙，就不得不佩服这位构造出POC的老外。

漏洞如何防范？

首先，开发者要有安全意识，应该清楚了解项目使用到的组件，以及这些组件是否存在漏洞，虽然说Apache-CommonsCollections RCE漏洞曝光将近两年时间，但使用3.2.2版本之前的Apache-CommonsCollections的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，当触发运行时还可加入报警逻辑，启动应急响应：

反序列化漏洞利用的其他思考

作者认为反序列化漏洞的利用应该更为广泛，思路不应该仅仅局限于远程命令执行漏洞的利用，也存在着系统数据篡改污染的危险，造成系统业务安全问题。例如序列化对象在系统中承担了账单、金额、认证、鉴权等职责，如果可以被反序列化恶意利用，后果也非常严重。这样的威胁不亚于命令执行的威胁，并且事后难于排查，因为是内存攻击，载荷不落地。所以，反序列化对于业务安全的威胁也是我们一个值得深思的问题。

对了，有兴趣的从代码层面研究一把的小伙伴可以私信回复：java，获取相关代码。