转载

Oracle WebLogic Two RCE Deserialization Vulnerabilities

Oracle 官方在7月份发布关键补丁更新之后，我在当月随后陆续提交了一些weblogic的不同类型漏洞，由于官方并没有全部修复完成，本次的补丁修复了我报送的6个漏洞，其中有3个漏洞由于某些原因合并成1个CVE，本文针对10 月份这次补丁修复的其他两个漏洞进行简单分析。其中CVE-2018-3245是补来补去一直没有修好的 Weblogic JRMP 反序列化漏洞，另一个漏洞CVE-2018-3252是 DeploymentService 组件的反序列化漏洞。

CVE-2018-3252 (DeploymentService Deserialization via HTTP)

当我在阅读 DeploymentService 这个 servlet 的时候，在 doPost 函数中看到用于对通过HTTP方式提交的POST数据处理的核心函数 internalDoPost 。

Oracle WebLogic Two RCE Deserialization Vulnerabilities

可以看到， var4 是通过HTTPHeader中的 wl_request_type 获取。然后进入不同的处理逻辑中。这里先跟进 handleDataTransferRequest 函数。

在上图箭头所指向的地方，程序对 var9 进行了反序列化，而 var9 是通过 DeploymentObjectInputStream 的构造函数生成，其中函数中的参数都是我们可控制的。

再来看 handleDeploymentServiceMessage 函数，基本逻辑大致相同，也是对 DeploymentObjectInputStream 对象的反序列化。

看到这里，心里隐隐觉得这个洞应该很好用，还是通过HTTP的方式。细心的同学可能发现，这里我们分析的每个函数都有一个参数是AuthenticatedSubject对象。这就是这个漏洞鸡肋的地方，需要 用户认证 。有兴趣的同学可以深入分析一下weblogic的用户认证机制，试试bypass 。具体函数请参考 authenticateRequest ，下图关于该函数有做删减，方便大家看到weblogic提供的两种认证方式。

这里我们使用 username/password 的用户认证方式验证PoC。

CVE-2018-3245(JRMP Deserialization via T3)

在拿到7月份补丁后迅速去diff了一下，果然不出所料，针对JRMP反序列化修复的方式依旧是增加黑名单。黑名单package(DEFAULT_BLACKLIST_PACKAGES)新增 java.rmi.activation sun.rmi.server ;黑名单class(DEFAULT_BLACKLIST_CLASSES)新增 java.rmi.server.UnicastRemoteObject java.rmi.server.RemoteObjectInvocationHandler 。

 private static final String[] DEFAULT_BLACKLIST_PACKAGES = {
"org.apache.commons.collections.functors", "com.sun.org.apache.xalan.internal.xsltc.trax",
"javassist", "java.rmi.activation", "sun.rmi.server" };

  private static final String[] DEFAULT_BLACKLIST_CLASSES = {
"org.codehaus.groovy.runtime.ConvertedClosure",
"org.codehaus.groovy.runtime.ConversionHandler", "org.codehaus.groovy.runtime.MethodClosure",
"org.springframework.transaction.support.AbstractPlatformTransactionManager",
"java.rmi.server.UnicastRemoteObject", "java.rmi.server.RemoteObjectInvocationHandler" };

其实如果认真分析过之前相关漏洞和补丁的同学，都能够很容易找到绕过的方式。

正如之前和 lpwd 讨论的所谈到，只要满足继承 java.rmi.server.RemoteObject ,且不在黑名单之中的类对象。这里我通过 ReferenceWrapper_Stub 这个类对象绕过。

验证:

WebLogic Console Log:

 java.lang.ClassCastException: com.sun.jndi.rmi.registry.ReferenceWrapper_Stub cannot be cast to
weblogic.rjvm.ClassTableEntry.
java.lang.ClassCastException: com.sun.jndi.rmi.registry.ReferenceWrapper_Stub cannot be cast to
weblogic.rjvm.ClassTableEntry
    at weblogic.rjvm.MsgAbbrevInputStream.readClassDescriptor(MsgAbbrevInputStream.java:410)
    at
weblogic.utils.io.ChunkedObjectInputStream$NestedObjectInputStream.readClassDescriptor(ChunkedO
bjectInputStream.java:284)
    at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1564)
    at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495)
    at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1582)
    Truncated. see log file for complete stacktrace

总结

可能目前谈到weblogic漏洞的挖掘，马上想到的是反序列化漏洞。依照之前多次补丁更新的迹象，虽然可能还是会有新的绕过，但是能够使用的gadget越来越少，会让漏洞的利用难度提高很多。其实，我在阅读weblogic代码的过程中发现，很多在java中常见的漏洞:文件下载、上传、SSRF、XXE、DoS…这些漏洞也都存在，并且利用简单方便。或许，试着找些其他类型的漏洞配合使用，也是可以达到远程代码执行的效果。

原文 https://blogs.projectmoon.pw/2018/10/19/Oracle-WebLogic-Two-RCE-Deserialization-Vulnerabilities/

正文到此结束