Oracle WebLogic Two RCE Deserialization Vulnerabilities

Oracle 官方在7月份釋出 ofollow,noindex">關鍵補丁更新 之後，我在當月隨後陸續提交了一些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…這些漏洞也都存在，並且利用簡單方便。 或許，試著找些其他型別的漏洞配合使用，也是可以達到遠端程式碼執行的效果。