CVE-2019-2890 Weblogic t3反序列化漏洞分析

@Adminxe

0x01 漏洞背景

在WebLogic官方发布的10月份安全补丁中，包含了由Venustech ADLab提交的CVE-2019-2890的修复。该漏洞通过T3协议发送恶意的反序列化数据绕过了Weblogic的黑名单，成功反序列化执行任意命令。通过官方公告可知，该漏洞的利用条件是需要认证。

0x02 影响范围

Weblogic 10.3.6.0.0
Weblogic 12.1.3.0.0
Weblogic 12.2.1.3.0

0x03 漏洞分析

下面以10.3.6.0作为分析版本。问题出现在PersistentContext类上，通过查看继承关系我们知道PersistentContext类实现了序列化接口Serializable。

PersistentContext类继承关系

我们来看看它的readObject方法，将ObjectInputStream类对象var1传入readSubject方法。

readObject方法

跟进readSubject方法发现，会先从var1中读取反序列化数据当中的对象数据。然后调用EncryptionUtil.decrypt方法进行解密，最后解密后的数据被用于反序列化为对象。

readSubject方法

至此我们知道PersistenContext序列化数据中还携带了其他对象反序列化后的加密数据。如果我们在序列化PersistentContext时，将恶意对象反序列化数据先加密，然后writeObject，就可以让其携带恶意对象，绕过Weblogic黑名单进行反序列化了。

0x04 漏洞利用

根据以上思路，我们编写一个携带恶意对象的PersistenContext类。只需修改下原来代码中的writeSubject方法为如下，其中Poc.getObject()就是我们的恶意对象。

修改writeSubject方法代码

在进行序列化之前我们要处理四个问题。第一个问题是创建PersistenContext对象报错。

创建PersistenContext对象报错信息

这是因为PersistenContext初始化时调用了SecurityServiceManager.isKernelIdentity()进行内核身份判断。isKernelIdentity方法无论如何都会抛出一个NotSupportedException异常，导致我们序列化被终止。

SecurityServiceManager.isKernelIdentity()方法

我们可以将其注释掉

PersistenContext构造方法要修改的代码

第二个问题是反序列化PersistenContext类会出现卡死现象。这是因为PersistenContext等相关的类都会有一个AuthenticatedSubject静态对象要初始化。

静态AuthenticatedSubject内核id对象

初始化时会进入到如下代码。

导致卡死的代码段

我们需要ceClient变量为true，否则会一直进循环执行ceSubjectManagerLock.wait()进行等待，无法序列化！而ceClient是从系统属性com.bea.core.internal.client获取的，所以在序列化之前需要将该属性设置为true。

ceClient变量的赋值

第三个问题是恶意对象没有被加密。这是因为在调用EncryptionUtil.encrypt方法加密时，会根据Kernel.isServer()为true时才会进行加密，否则返回原数据。
因此加密之前需要调用KernelStatus.setIsServer(true)设置状态为true。