作者：Zhiyi Zhang of 360 ESG Codesafe Team
作者博客：https://blogs.projectmoon.pw/2018/10/19/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。

可以看到，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…這些漏洞也都存在，并且利用簡單方便。 或許，試著找些其他類型的漏洞配合使用，也是可以達到遠程代碼執行的效果。

參考

感謝你的閱讀，文中如有問題，可以通過projectmoon.pw@gmail.com與我聯系。

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/721/