Java安全之反序列化漏洞分析

Posted Java面试那些事儿

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Java安全之反序列化漏洞分析相关的知识,希望对你有一定的参考价值。


1

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方法实现的,下图是作者画的一个序列化示意图:

Java安全之反序列化漏洞分析

2

反序列化漏洞成因

2015年年底,由公共依赖库Apache Common Collections引起的Java任意命令执行漏洞的严重安全问题,使得Java反序列化漏洞逐渐进入了安全

研究人员的视野(在此之前存在,但并未被重视),而任意命令执行的成因正是前文反序列化操作的ObejctInputStream类的readObject方法触发的。

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

Java安全之反序列化漏洞分析

OK,到目前为止一切都在程序员的掌控之中!何来的漏洞之说?呵呵,意外往往就发生在不经意之间,如果反序列化过程中提供了命令执行的机会,那么任意命令执行漏洞就产生了,如下我们在Session对象的readObject函数中增加了执行命令的代码:

Java安全之反序列化漏洞分析

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

Java安全之反序列化漏洞分析

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

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

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

看到这里,作为程序员的你肯定哈哈大笑!对象的反序列化函数谁会这样写?当然本示例只是为了以最直观的方式演示反序列漏洞产生原因,就直接提供了一个HelloWorld级别的漏洞示例,实际上,近两年 Java Apache-CommonsCollections 造成的序列化漏洞与Spring框架的反序列化漏洞(spring-tx.jar)的成因与原理都与上例相似,只是漏洞利用的构成比较复杂而已。

3

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方法的机会:

Java安全之反序列化漏洞分析

相信很多漏洞利用者对 invoke非常敏感,意味着提供了方法调用的机会,再结合方法名与参数都能通过InvokerTransformer构造函数来控制,因此该类一定是漏洞挖掘者反复徘徊的点。那该如何利用?在commons-collections包中,InvokerTransformer结合ChainedTransformer就能构造一个Java类加载函数调用链,POC的作者是如下构造的:

Java安全之反序列化漏洞分析

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

Java安全之反序列化漏洞分析

可以看到,通过ChainedTransformer.transform 的构造相当于反射调用了Runtime.getRuntime().exec(),从而触发了命令的执行。OK,那么问题来了,谁去触发调用ChainedTransformer.transform函数呢?漏洞利用者找到了包中TransformedMap.checkSetValue()方法:

Java安全之反序列化漏洞分析

这样一来,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的反序列化函数满不满足触发要求:

Java安全之反序列化漏洞分析

因为setValue函数会调用checkSetValue:

Java安全之反序列化漏洞分析

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

Java安全之反序列化漏洞分析

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

Java安全之反序列化漏洞分析

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


4

漏洞如何防范?

首先,开发者要有安全意识,应该清楚了解项目使用到的组件,以及这些组件是否存在漏洞,虽然说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,当触发运行时还可加入报警逻辑,启动应急响应:

5

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


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







以上是关于Java安全之反序列化漏洞分析的主要内容,如果未能解决你的问题,请参考以下文章

Java安全之反序列化回显与内存马

网络安全之反序列化漏洞复现

Python代码审计实战案例总结之反序列化和命令执行!

2020/2/2 PHP代码审计之反序列化

Java反序列化安全漏洞怎么回事

6-java安全——java反序列化漏洞利用链