Java安全之Weblogic 2016-3510 分析

nice_0e3發表於2021-01-12

Java安全之Weblogic 2016-3510 分析

首發安全客:Java安全之Weblogic 2016-3510 分析

0x00 前言

續前面兩篇文章的T3漏洞分析文章,繼續來分析CVE-2016-3510漏洞,該漏洞一樣是基於,前面的補丁進行一個繞過。

Java安全之初探weblogic T3協議漏洞

Java安全之Weblogic 2016-0638分析

0x01 工具分析

這裡還需要拿出上次的weblogic_cmd的工具來看一下CVE-2016-3510的命令執行payload怎麼去進行構造。

來到原始碼中的Main這個入口點這裡,前面的TYPE需要修改為marshall,因為這次是需要使用到MarshalledObject來進行封裝物件。

填入引數,打個斷點測試一下。

前面的都分析過了,在此略過,主要是這張圖片裡面的地方傳入命令,並且生成payload,跟蹤進行檢視。

這裡的blindExecutePayloadTransformerChain方法是返回構造利用鏈的Transformer[]陣列內容,這裡主要來跟蹤serialData方法。

該方法中是將剛剛構造好的Transformer[]陣列傳入進來,聯合下面的程式碼構造成了一個惡意的物件,然後呼叫BypassPayloadSelector.selectBypass方法處理這個惡意的物件。跟蹤檢視該方法的實現。

這個位置呼叫了marshalledObject方法處理payload,跟蹤檢視。

marshalledObject內部使用了MarshalledObject的構造方法,將payload作為引數傳遞進去。然後得到該值。這裡payload就構造好了。

跟蹤進MarshalledObject裡面進行檢視。

這個地方又new了一個MarshalledObject.MarshalledObjectOutputStream物件,跟蹤檢視。

MarshalledObject.MarshalledObjectOutputStream繼承了ObjectOutputStream物件,並且呼叫的是父類的構造器。這就和直接new一個ObjectOutputStream沒啥區別。

var1是我們傳遞進來的payload,在這裡使用的是CC1的利用鏈,var1也就是一個惡意的AnnotationInvocationHandler物件。var2是ByteArrayOutputStream物件,var3相當於是一個ObjectOutputStream物件。在這裡會將var1 的內容進行序列化後寫入到var2裡面。

而序列化後的物件資料會被賦值給MarshalledObjectthis.objBytes裡面。

執行完成,退回到這一步過後,則是對構造好的MarshalledObject物件呼叫Serializables.serialize方法進行序列化操作。

0x02 漏洞分析

在前面並沒有找到CVE-2016-0638漏洞的補丁包,那麼在這裡也可以直接來看到他的利用方式。

前面CVE-2016-0638這個漏洞是基於前面的補丁將payload序列化過後封裝在weblogic.jms.common.StreamMessageImpl類裡面,然後進行反序列化操作,StreamMessageImpl類會呼叫反序列化後的物件的readobject方法達成命令執行的操作。而補丁包應該也是在ClassFileter類裡面將上次我們利用的weblogic.jms.common.StreamMessageImpl類給進行拉入黑名單中。

那麼在該漏洞的挖掘中又找到了一個新的類來對payload進行封裝,然後繞過黑名單的檢測。

而這次使用得是weblogic.corba.utils.MarshalledObject類來進行封裝payload,將payload序列化過後,封裝到weblogic.corba.utils.MarshalledObject裡面,然後再對MarshalledObject進行序列化MarshalledObject,MarshalledObject不在WebLogic黑名列表裡面,可以正常反序列化,在反序列化時MarshalledObject物件呼叫readObject時,對MarshalledObject封裝的序列化物件再次反序列化,這時候繞過黑名單的限制,對payload進行反序列化操作觸發命令執行。

下面來直接看到weblogic.corba.utils.MarshalledObject#readResolve方法的位置

這地方就有意思了,前面在分析工具的時,我們得知構造的繞過方式是將payload序列化放在這個this.objBytes中,而在此如果呼叫MarshalledObject.readResolve方法就可以對被封裝的payload進行反序列化操作。達到執行命令的效果。

在這裡還需要思考到一個問題readResolve這個方法會在什麼時候被呼叫呢?

在Weblogic從流量中的序列化類位元組段通過readClassDesc-readNonProxyDesc-resolveClass獲取到普通類序列化資料的類物件後,程式依次嘗試呼叫類物件中的readObject、readResolve、readExternal等方法。而上一個CVE-2016-0638的漏洞就是藉助的readExternal會被程式所呼叫的特點來進行繞過。我們這次使用的是readResolve這個方法,這個方法也是同理。

後面也還需要知道一個點,就是反序列化操作過後,readResolve具體是如何觸發的?下來來斷點檢視就清楚了。

先在InboundMsgAbbrev.ServerChannelInputStream#resolveClass方法先打一個斷點,payload傳送完成後,在該位置停下。

在這這裡可以看到傳遞過來的是一個MarshalledObject物件,不在黑名單中。

那麼下面在readResolve上下個斷點看一下呼叫棧。

在這裡面會被反射進行呼叫,再前面的一些方法由於不是原始碼進行調式的跟蹤不了。

回到weblogic.corba.utils.MarshalledObject#readResolve方法中檢視

和前面說的一樣,這裡new了一個ByteArrayInputStream物件,對this.objBytes進行讀取,前面說過我們的payload封裝在this.objBytes變數裡面,而這時候new了一個ObjectInputStream並且呼叫了readObject方法進行反序列化操作。那麼這時候我們的payload就會被進行反序列化操作,觸發CC鏈的命令執行。

先來檢視docker容器裡面的內容

然後執行來到下一行程式碼中。

readobject執行過後,再來檢視一下docker裡面的檔案有沒有被建立。

檔案建立成功,說明命令能夠執行。

0x03 結尾

本文內容略少,原因是因為很多內容都是前面重複的,並不需要拿出來重新再敘述一遍。這樣的話並沒有太大的意義,如果沒有分析過前面的兩個漏洞,建議先從前面的CVE-2015-4852和CVE-2016-0638這兩個漏洞除錯分析起,除錯分析完前面的後面的這些繞過方式理解起來會比較簡單。

相關文章