怎么進行WebSphere遠程代碼執(zhí)行漏洞CVE-2020-4450分析

這篇文章將為大家詳細講解有關(guān)怎么進行WebSphere遠程代碼執(zhí)行漏洞CVE-2020-4450分析，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

0x01 漏洞簡述

2020年06月08日，360CERT監(jiān)測到 IBM官方發(fā)布了 WebSphere遠程代碼執(zhí)行 的風(fēng)險通告，該漏洞編號為 CVE-2020-4450，漏洞等級：嚴重，漏洞評分：9.8分。

此漏洞由IIOP協(xié)議上的反序列化造成，未經(jīng)身份認證的攻擊者可以通過IIOP協(xié)議遠程攻擊WebSphere Application Server，在目標服務(wù)端執(zhí)行任意代碼，獲取系統(tǒng)權(quán)限，進而接管服務(wù)器。

對此，360CERT建議廣大用戶及時安裝最新補丁，做好資產(chǎn)自查以及預(yù)防工作，以免遭受黑客攻擊。

0x02 風(fēng)險等級

360CERT對該漏洞的評定結(jié)果如下

0x03 影響版本

• WebSphere Application Server: 9.0.0.0 to 9.0.5.4

• WebSphere Application Server: 8.5.0.0 to 8.5.5.17

• WebSphere Application Server: 8.0.0.0 to 8.0.0.15

• WebSphere Application Server: 7.0.0.0 to 7.0.0.45

0x04 漏洞詳情

iiop觸發(fā)反序列化

按照zdi給出的分析，iiop的攔截是在com.ibm.ws.Transaction.JTS.TxServerInterceptor#receive_request，那么下斷點進行遠程調(diào)試，由于websphere自己實現(xiàn)了一套iiop，所以想要走到iiop觸發(fā)反序列化的點還需要構(gòu)造滿足條件的iiop客戶端，這里需要走到demarshalContext方法，前提是滿足validOtsContext為true，也就是需要serviceContext不為null。

假如我們已經(jīng)構(gòu)造了serviceContext不為null，繼續(xù)往下看，將serviceContext.context_data傳入demarshalContext方法。
調(diào)用createCDRInputStream創(chuàng)建CDRInputStream，實際上生成的是EncoderInputStream，CDRInputStream的子類，之后調(diào)用EncoderInputStream#read_any方法。

之后的調(diào)用有些繁瑣，就不列出來了，調(diào)用棧為：

serviceContext賦值

由于需要serviceContext不為null,才能走到demarshalContext方法體里面，在com.ibm.rmi.iiop.Connection#setConnectionContexts方法中，該方法如下：

setConnectionContexts方法可以對ServiceContext屬性進行設(shè)置，但是我們需要從iiop生成的默認上下文中獲取存儲著的當前Connection信息。

參考@iswin師傅的文章，可以知道，在com.ibm.rmi.iiop.GIOPImpl里，存在一個getConnection方法，可以獲取當前上下文的Connection實例對象，

不過該方法需要傳遞當前ior參數(shù)，而GIOPImpl的對象在orb里，

這些都能通過反射從defaultContext中獲取。

惡意數(shù)據(jù)流構(gòu)造

看一下數(shù)據(jù)流是怎么被解包的，具體在demarshalContext方法里，也就是構(gòu)造完ServeicContext下一步要執(zhí)行的。

與之對應(yīng)的，marshalContext方法里有相應(yīng)的數(shù)據(jù)包生成代碼，所以只需要將關(guān)鍵代碼單獨掏出來，再把PropagationContext對象構(gòu)造一下，就能生成gadgets對象的數(shù)據(jù)流。

構(gòu)造的關(guān)鍵代碼為：

gadgets

既然iiop已經(jīng)通了，那么我們就根據(jù)zdi給出的gadgets進行構(gòu)造，首先需要明確的是，反序列化的入口是org.apache.wsif.providers.ejb.WSIFPort_EJB（因為websphere自身類加載器的問題，導(dǎo)致現(xiàn)有的gadgets都無法利用，所以我們只能基于新的挖掘的類來構(gòu)造gadgets）。

這里我們利用的是handle.getEJBObject方法，handle是一個Handle類型，在實現(xiàn)了Handle接口的類中，能夠進行利用的是com.ibm.ejs.container.EntityHandle這個類，事實上，我們在對handle進行賦值的時候，比較復(fù)雜，需要反射多個對象。

我們來看一下他的getEJBObject方法。
這里有幾處需要注意的：

lookup加載本地factory

先來看第一處，也就是lookup方法，這里的homeJNDIName是我們在反序列化流程中可以控制的。于是，在能夠出網(wǎng)的情況下，可以指向我們的rmi服務(wù)。

這里首先會調(diào)用registry.lookup，獲取我們在rmi上bind的對象，由于jdk版本過高的原因，所以導(dǎo)致com.sun.jndi.ldap.object.trustURLCodebase選項默認被設(shè)置為false，也就是說，我們不能利用jndi去遠程服務(wù)器上利用URLClassLoader動態(tài)加載加載類，只能實例化本地的Factory，這里利用的方式是加載本地類，具體細節(jié)參考：Exploiting JNDI Injections in Java。

簡單來說，正常情況下，jndi的利用會在RegistryImpl_Stub.lookup之后返回一個ReferenceWrapper的客戶端代理類，ReferenceWrapper提供了三個參數(shù)，className,factory,factoryLocation，如果本地加載不到className，那么就會去factoryLocation上加載factory，大致流程為：

而現(xiàn)在不能遠程去加載factoryLocation，那么我們尋求一個本地factory來實例化，并利用該factory的getObjectInstance方法，根據(jù)zdi提供的漏洞細節(jié)，滿足條件的factory是org.apache.wsif.naming.WSIFServiceObjectFactory。

前邊的調(diào)用棧是這樣的，

com.sun.jndi.rmi.registry.RegistryContext#lookupcom.sun.jndi.rmi.registry.RegistryContext#decodeObjectjavax.naming.spi.NamingManager#getObjectInstance

rmi服務(wù)端可以在reference對象里對factory進行設(shè)置，當然這個factory需要滿足一些條件，當調(diào)用WSIFServiceObjectFactory.getObjectInstance，我們看一下這個方法。這里wsdlLoc,serviceNS等值都可以在rmi端通過Reference進行設(shè)置。

這里會對ref進行判斷，也就是Reference對象的第一個參數(shù)，也是可控的。我們需要走到下面的判斷里，也就是讓ref為WSIFServiceStubRef，原因是這樣的，需要回過來看到前面，
我們需要指定返回代理的類型是EJBHome。這里有兩個地方需要指定接口的類型，一個是narrow第二個參數(shù)homeClass，一個是在Reference指定className，用來控制返回的代理類型。

WSIF web服務(wù)

這里的getObjectInstance調(diào)用將從遠程URL初始化WSIF服務(wù)，該URL指向可由攻擊者控制的遠程XML定義，在遠程xml里，我們可以將方法進行映射，這里只說個概念，后面再仔細說。

指定生成的stub的接口類型

當ref是WSIFServiceStubRef類型的時候，可以通過className來指定生成stub的接口類型，這樣就能生成實現(xiàn)EJHome接口的代理，這里前面已經(jīng)提到過了，具體在rmi服務(wù)端通過Reference進行設(shè)置。

創(chuàng)建動態(tài)代理

這里會在getStub里創(chuàng)建代理類。

根據(jù)提供的接口，最終返回WSIFClientProxy代理類。

el表達式注入

接著，在this.findFindByPrimaryKey獲取homeClass接口的findByPrimaryKey方法。

之后，就會調(diào)用動態(tài)代理類的invke方法，傳入findFindByPrimaryKey和this.key，也就是方法的參數(shù)。

在WSIFClientProxy.invoke的方法里，會調(diào)用WSIFPort實現(xiàn)類的createOperation方法。

這個createOperation方法就能將方法進行映射，這里我們可以將findFindByPrimaryKey方法映射為本地存在的方法，比如javax.el.ELProcessor的eval方法，這里的映射就主要體現(xiàn)在之前提到的WSIF web服務(wù)里，需要將映射內(nèi)容體現(xiàn)在我們自定義的遠程xml文件里。主要語法可以參考：WSDL Java Extension_（https://ws.apache.org/wsif/providers/wsdl_extensions/java_extension.html）_，具體的調(diào)用就在自定義rmi服務(wù)上進行設(shè)置，之后的調(diào)用棧如下：

最終在ELProcessor#eval方法里執(zhí)行el表達式。

漏洞利用

利用成功的截圖如下：

版本修復(fù)

在官網(wǎng)下載補丁_（https://www.ibm.com/support/pages/node/6220276）_進行分析，發(fā)現(xiàn)對反序列化入口WSIFPort_EJB進行了修改，在readObject方法里，將原本的handle.getEJBObject方法給取消了，這樣，也就把這個鏈的入口給殺死了。

0x05 時間線

2020-06-04  IBM發(fā)布預(yù)警

2020-06-08  360CERT發(fā)布預(yù)警

2020-07-21  ZDI發(fā)布分析報告

2020-08-05  360CERT發(fā)布分析報告

關(guān)于怎么進行WebSphere遠程代碼執(zhí)行漏洞CVE-2020-4450分析就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。