[CVE-2018-3245&3252]Oracle WebLogic Two RCE Deserialization Vulnerabilities

  • A+
所属分类:javasec_cn
摘要

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

Author: Zhiyi Zhang of 360 ESG Codesafe Team


前言

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。
[CVE-2018-3245&3252]Oracle WebLogic Two RCE Deserialization Vulnerabilities

可以看到,var4是通过HTTPHeader中的wl_request_type获取。然后进入不同的处理逻辑中。这里先跟进handleDataTransferRequest函数。
[CVE-2018-3245&3252]Oracle WebLogic Two RCE Deserialization Vulnerabilities

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

再来看handleDeploymentServiceMessage函数,基本逻辑大致相同,也是对DeploymentObjectInputStream对象的反序列化。
[CVE-2018-3245&3252]Oracle WebLogic Two RCE Deserialization Vulnerabilities

看到这里,心里隐隐觉得这个洞应该很好用,还是通过HTTP的方式。细心的同学可能发现,这里我们分析的每个函数都有一个参数是AuthenticatedSubject对象。这就是这个漏洞鸡肋的地方,需要用户认证。有兴趣的同学可以深入分析一下weblogic的用户认证机制,试试bypass,具体函数请参考authenticateRequest,下图关于该函数有做删减,方便大家看到weblogic提供的两种认证方式。
[CVE-2018-3245&3252]Oracle WebLogic Two RCE Deserialization Vulnerabilities
这里我们使用username/password的用户认证方式验证PoC。
[CVE-2018-3245&3252]Oracle WebLogic Two RCE Deserialization Vulnerabilities

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这个类对象绕过。
[CVE-2018-3245&3252]Oracle WebLogic Two RCE Deserialization Vulnerabilities
验证:
[CVE-2018-3245&3252]Oracle WebLogic Two RCE Deserialization Vulnerabilities

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 

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: