WebLogic反序列化(CVE-2020-14644)漏洞分析

0x01 简介

WebLogic是美国Oracle公司出品的一个application server，确切的说是一个基于JAVAEE架构的中间件，WebLogic是用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用的Java应用服务器。

0x02 漏洞概述

Oracle官方在2020年7月份发布的最新安全补丁中披露此漏洞。该漏洞允许未经身份验证的攻击者通过IIOP,T3进行网络访问，未经身份验证的攻击者成功利用此漏洞可能接管Oracle WebLogic Server。CVSS评分9.8。

0x03 影响版本

  • Oracle WebLogic Server 12.2.1.3.0
  • Oracle WebLogic Server 12.2.1.4.0
  • Oracle WebLogic Server 14.1.1.0.0

0x04 环境搭建

WebLogic 安装

由于之前复现 CVE-2020-14645 漏洞时已经搭建完成，因此在此不过多阐述过程，仅记录一些信息。

WebLogic 下载链接：https://www.oracle.com/middleware/technologies/weblogic-server-installers-downloads.html

image-20200928152012609

选择 12.2.1.4 的 Generic 版本进行下载安装即可，安装过程注意JDK版本造成的安装失败（建议JDK 1.8）以及以管理员权限运行安装包。具体安装过程可参照这两篇文章：

此外，安装过程中，为方便后续其他漏洞利用，安装类型可选择“含示例的完整安装”。

安装完之后，直接运行安装目录下的启动脚本即可，路径结构如下：

$Oracle_Home$\12.2.1.4.0\user_projects\domains\wl_server\startWebLogic.cmd
// Oracle_Home指WebLogic安装的绝对路径

启动脚本后，浏览器访问http://127.0.0.1:7001/console。

image-20200928162057678

正常显示控制台登录界面，即代表安装成功。

0x05 漏洞复现

使用 WebLogic 12.2.1.4.0 版本进行复现

poc 文件见：https://github.com/rufherg/WebLogic_Basic_Poc/blob/master/poc/CVE_2020_14644.java

T3 协议 python 脚本见：https://github.com/rufherg/WebLogic_Basic_Poc

运行poc文件生成反序列化数据文件，随后通过 t3 协议传输数据

image-20201028193738062

成功弹出计算器，但是此处同一个Payload无法多次执行，原因在于这个类在第一次触发时已经被加载了（static块）。可以考虑通过生成不同的类，或者其他方式进行反复利用。

0x06 漏洞分析

先来看看漏洞的调用栈

image-20201028204456037

整体来看，调用链比较简单，直接定位到com.tangosol.internal.util.invoke.RemoteConstructor这个类。

image-20201028205202425

可以看到RemoteConstructor这个类是实现了ExternalizableLite接口，而ExternalizableLite接口又继承了Serializable接口。因此，RemoteConstructor这个类可被序列化与反序列化，我们来看其反序列化入口readResolve。

image-20201028210621900

可以看到调用了内部的newInstance方法，跟进分析一下。

image-20201028210708766

这里，我们需要重点关注RemotableSupport.realize方法。

image-20201030155959115

我们很容易注意到两个关键点——defineClass和createInstance方法，调试过一些 java 漏洞的同学，应该很容易就意识到这里是一个通过加载字节码自定义类，然后进行实例化的过程。但是注意这里一开始会调用registerIfAbsent方法，我们先来看看该方法。

image-20201030232320066

image-20201030232431602

这里出现Map类型的f_mapDefinitions是用于充当一个缓存作用，因此每次调用 realize 时会先在缓存中查找 ClassDefinition。

image-20201030233310025

image-20201031011955280

往下可以发现会通过getRemotableClass方法去获取this.m_clz的值，但是其经过transient修饰，无法控制其值。注意这里还有一个同样被transient修饰的m_mhCtor，为一个MethodHandle对象。MethodHandle是 JDK7 的新特性，其引入是为了与已经存在的java.lang.reflect API相配合，以解决不同情况下的问题。在这里先不讨论，在后面再阐述。

image-20201030233633169

回到realize方法走入if分支，这里会调用defineClass方法然后通过setRemotableClass方法进行赋值，跟进分析：

image-20201030165200616

image-20201030165248576

我们可以看到RemotableSupport继承了ClassLoader并且重写了defineClass方法，在方法中先对definition对象进行一些数据处理分割，最后调用原生的ClassLoader.defineClass加载字节码生成Class对象。我们先来看看其怎么处理数据的。

image-20201030200451753

可以看到这里的id实质上就是指ClassIdentity对象，abClass就是需要加载的字节码，跟进其getName方法。

image-20201030200855017

image-20201030205934130

很容易看到，获取的属性都是构造方法中的参数，因此我们只要构造出一个符合条件的ClassIdentity对象。sPackage和sBaseName都比较容易处理，重点在于sVersion的获取，这里采用的方式是Base.toHex(md5(clazz)))（图片篇幅受限没显示出来）。所以最终defineClass方法中获取的sClassName内容形式应该是xxx.xxx.xxx$md5(clazz)，构造对象时我们利用一个存在的class对象，然后生成一个名字为xxx$md5(clazz)的类（字节码的类名需与sClassName一致）。例如：

String classname = "com.tangosol.internal.util.invoke.lambda.LambdaIdentity$" + Base.toHex(md5(LambdaIdentity.class));
ClassPool pool = ClassPool.getDefault();
CtClass ct = pool.makeClass(classname);

所以defineClass方法将会触发加载字节码操作，继续往下看：

image-20201030231037293

image-20201031012931451

这里调用了constructor.getArguments方法，返回的是m_aoArgs属性值，而该属性来自构造方法的参数，因此是可控的。

image-20201031013349628

image-20201031013317022

这里会先获取以aoArgs为参数的构造器，并执行invokeWithArguments方法（即调用构造器生成实例对象）。可以看到m_mhCtor在前面是可以进行赋值的（加载的类只有一个构造器时），并且是对m_clz即加载字节码所生成的类对象进行构造器寻找。如果没赋值，此处会重新寻找构造方法生成MethodHandle。此处，由于 POC 中生成的类是无参的构造方法，所以aoArgs为空的Object[]。至此，便可以通过反序列化漏洞实例化字节码定义的类。

0x07 修复建议

1、安装官方补丁

https://www.oracle.com/security-alerts/cpujul2020.html

2、限制T3访问来源

漏洞产生于WebLogic默认启用的T3协议，因此可通过限制T3访问来源来阻止攻击。

3、禁用IIOP协议

可以查看下面官方文章进行关闭IIOP协议。

https://docs.oracle.com/middleware/1213/wls/WLACH/taskhelp/channels/EnableAndConfigureIIOP.html

0x08 总结

本来已经快写完了，在createInstance打算跳过然后停笔。但是想到了 static 静态块是在类初始化时会自动执行，但是为什么调试时是在createInstance后执行。顺着这个问题，加上对MethodHandle的不了解，翻阅很多资料文章，才纠正了一个很严重的误区。在这里给大家指出来，也希望一些学习 Java 安全的同学不要陷入这样的一个误区，另外再注明几个调试分析中的疑问点。学习与实践是一个相辅相成的过程，通过实践深刻知识，通过学习弥补短板。Java 知识面很广，需要不断多想多学多试，去理解其中的奥秘，像类的加载机制等等底层特性都值得我们去深究。随着你的理解愈发深刻，你会产生更多的新奇思路，不管是漏洞利用方式还是挖洞思维，都格外见效。

类的初始化

引用一张图来理解

很多同学可能以为defineClass之后生成Class对象就是成功加载了一个类并且初始化了，但是事情并不是这样。“加载”通俗来讲就是：将一个类的二进制字节流转化为 Class 对象，例如常见的 .class 文件加载、defineClass方法，而初始化是在链接后才进行的。

以下五种情况将触发类的初始化：

1）遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。

2）使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。

3）当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

4）当虚拟机启动时，用户需要指定一个要执行的主类（包含main（）方法的那个类），虚拟机会先初始化这个主类。

5）当使用JDK 1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

另外还有两个需要对比区分的—— Class.forName 以及 Classloder.loadClass，这两者也经常容易被混淆。Class.forName("类名")默认会初始化被加载类的静态属性和方法，如果不希望初始化类可以使用Class.forName("类名", 是否初始化类, 类加载器)，而ClassLoader.loadClass默认不会初始化类方法（未链接状态）。

疑问1：为什么payload只能用一次？

实质上这个问题，在上面已经有了解答。在realize方法中，会先在缓存中查看是否存在对象，不存在时才会调用defineClass方法，而 static 块对于同一个类对象，只会执行一次。要打破这种禁锢，可以尝试将恶意代码写在恶意类的构造方法中，当然这个得自行测试一下了。另外一个方式，就是生成不同的类，可以看到ClassIdentity类的另外一个构造方法是protected修饰，因此我们可以通过反射去构造，POC相关部分改写如下：

//用于生成不同payload
String packagename = "com/payload";
String basename = "DEADF1SH_CAT";
String version = "" + System.nanoTime();
String classname = "com.payload.DEADF1SH_CAT$" + version;
       
//通过反射构造
Class clazz = ClassIdentity.class;
Constructor IdCon = clazz.getDeclaredConstructor(String.class,String.class,String.class);
IdCon.setAccessible(true);//构造方法为protected
       
ClassIdentity ClassId = (ClassIdentity) IdCon.newInstance(packagename, basename, version);

疑问2：为什么构造的恶意类名一定要带包名？

image-20201031022743080

不带包名getPackage()会返回null，再往下调用就会造成空指针异常。

参考链接：

posted @ 2021-01-05 09:31  DEADF1SH_CAT  阅读(902)  评论(0)  编辑  收藏  举报