0x00 前言

---

目前在公開途徑還沒有看到利用JAVA反序列化漏洞控制開放HTTPS服務的weblogic伺服器的方法，已公佈的利用工具都只能控制開放HTTP服務的weblogic伺服器。我們來分析一下如何利用JAVA反序列化漏洞控制開放HTTPS服務的weblogic伺服器，以及相應的防護方法。

建議先參考修復weblogic的JAVA反序列化漏洞的多種方法中關於weblogic的JAVA反序列化漏洞的分析。

0x01 HTTPS服務的架構分析

---

如果某伺服器需要對公網使用者提供HTTPS服務，可以在不同的層次實現。

使用SSL閘道器提供HTTPS服務

當使用SSL閘道器提供HTTPS服務時，網路架構如下圖所示（無關的裝置已省略，下同）。

SSL閘道器只會向後轉發HTTP協議的資料，不會將T3協議資料轉發至weblogic伺服器，因此在該場景中，無法透過公網利用weblogic的JAVA反序列化漏洞。

使用負載均衡提供HTTPS服務

當使用負載均衡提供HTTPS服務時，網路架構如下圖所示。

安全起見，負載均衡應選擇轉發HTTP協議而不是TCP協議，因此在該場景中，也無法透過公網利用weblogic的JAVA反序列化漏洞。

使用web代理提供HTTPS服務

當使用web代理（如apache、nginx等）提供HTTPS服務時，網路架構如下圖所示。

web代理只會向後轉發HTTP協議的資料，因此在該場景中，也無法透過公網利用weblogic的JAVA反序列化漏洞。

使用weblogic提供HTTPS服務

當使用weblogic提供HTTPS服務時，網路架構如下圖所示。

weblogic能夠接收到利用SSL加密後的T3協議資料，因此在該場景中，透過公網能夠利用weblogic的JAVA反序列化漏洞。

根據上述分析，僅當HTTPS服務由weblogic提供時，才能夠利用其JAVA反序列化漏洞。

0x02 weblogic開放SSL服務時的T3協議格式分析

---

利用weblogic的JAVA反序列化漏洞時，必須向weblogic傳送T3協議頭。為了能夠利用提供SSL服務的weblogic的JAVA反序列化漏洞，需要首先分析當weblogic提供SSL服務時的T3協議格式。

SSL資料包為加密的形式，無法直接進行分析，需要進行解密。當已知SSL私鑰時，可以利用Wireshark對SSL通訊資料進行解密。

weblogic可以使用演示SSL證照提供SSL服務，也可以使用指定SSL證照提供SSL服務。

可以使用兩種方法進行分析，一是使用weblogic提供的演示SSL證照進行分析，二是使用自己生成的SSL證照進行分析。

使用weblogic演示證照進行分析(方法一)

使用weblogic演示證照開放SSL服務

登入weblogic控制檯，將AdminServer的“啟用SSL監聽埠”鉤選，並填入SSL監聽埠號。

檢視AdminServer的金鑰庫配置，確認為“演示標識和演示信任”（Demo Identity and Demo Trust），可以看到演示金鑰庫的檔名為“DemoIdentity.jks”，演示信任金鑰庫檔名為“DemoTrust.jks”。

檢視AdminServer的SSL配置，可以看到演示金鑰庫的私鑰別名為“DemoIdentity”。

使用HTTPS方式登入weblogic控制檯，確認可以正常登入。

生成weblogic演示證照的私鑰檔案

以下為weblogic演示金鑰庫的密碼資訊。

Property	Value
Trust store location	DemoTrust.jks檔案，可在控制檯檢視
Trust store password	DemoTrustKeyStorePassPhrase
Key store location	DemoIdentity.jks檔案，可在控制檯檢視
Key store password	DemoIdentityKeyStorePassPhrase
Private key password	DemoIdentityPassPhrase
Private Key Alias	DemoIdentity，可在控制檯檢視

使用以下命令生成weblogic演示金鑰庫的私鑰檔案。

#!bash
set keystore=DemoIdentity.jks
set tmp_p12=tmp.p12

set storepass=DemoIdentityKeyStorePassPhrase
set keypass=DemoIdentityPassPhrase
set alias=DemoIdentity
set pwd_new=123456

keytool -importkeystore -srckeystore %keystore% -destkeystore %tmp_p12% -srcstoretype JKS -deststoretype PKCS12 -srcstorepass %storepass% -deststorepass %pwd_new% -srcalias %alias% -destalias %alias% -srckeypass %keypass% -destkeypass %pwd_new%

set out_pem=tmp.rsa.pem
set final_pem=final.key

openssl pkcs12 -in %tmp_p12% -nodes -out %out_pem% -passin pass:%pwd_new%
openssl rsa -in %out_pem% -check > %final_pem% 

最終生成的final.key即為weblogic演示金鑰庫的私鑰檔案。final.key的金鑰格式為

-----BEGIN RSA PRIVATE KEY-----  
......  
-----END RSA PRIVATE KEY-----  

修改weblogic停止指令碼

需要修改weblogic的停止指令碼“stopWebLogic.xx”，將ADMIN_URL欄位的“t3”改為“t3s”，並在java呼叫weblogic.WLST類的JVM啟動引數中加入“-Dweblogic.security.TrustKeyStore=DemoTrust”，使weblogic在呼叫停止指令碼時使用演示證照，否則會出現證照不被信任的錯誤。

使用自定義證照進行分析(方法二)

生成自定義金鑰庫

使用以下命令生成自定義金鑰庫。

#!bash
set keystore=keystore.jks
set alias=server
set pwd=123456
set url=url-test
set validity=7300

keytool -genkey -alias %alias% -keyalg RSA -keysize 2048 -keystore %keystore% -storetype jks -storepass %pwd% -keypass %pwd% -dname "CN=%url%, OU=companyName, O=companyName, L=cityName, ST=provinceName, C=CN" -validity %validity%

生成的金鑰庫名稱為keystore.jks，金鑰庫密碼與私鑰密碼均為“123456”。

使weblogic使用指定的金鑰庫

將上述步驟生成的金鑰庫檔案keystore.jks複製到weblogic的domain目錄中。

登入weblogic控制檯，在AdminServer的金鑰庫介面，選擇金鑰庫型別為“定製標識和 Java 標準信任”(Custom Identity and Java Standard Trust)，定製標識金鑰庫輸入“keystore.jks”，定製標識金鑰庫型別輸入“JKS”，定製標識金鑰庫密碼短語與確認定製標識金鑰庫密碼短語輸入“123456”，儲存上述修改。

在AdminServer的SSL介面，私有金鑰別名輸入“server”，私有金鑰密碼短語與確認私有金鑰密碼短語輸入“123456”。

使用HTTPS對應的URL開啟weblogic控制檯，確保可以正常登入，檢視證照資訊如下。

將自定義證照匯入java信任金鑰庫中

在上一步驟中可以看到Java標準信任金鑰庫對應的檔案為weblogic的JDK目錄中的“jdk\jre\lib\security\cacerts”檔案，金鑰型別也是JKS。

當weblogic作為SSL客戶端連線伺服器時，會檢查伺服器的證照鏈是否與weblogic的JDK目錄中的cacerts檔案匹配。

需要將自定義證照的公鑰匯入weblogic的JDK目錄中的cacerts檔案中，否則在呼叫weblogic停止指令碼時，會由於證照不受信任而失敗。

使用以下命令匯出自定義證照的公鑰。

#!bash
set keystore=keystore.jks
set alias=server
set pwd=123456
set exportcert=export.cer

keytool -export -alias %alias% -keystore %keystore% -file %exportcert% -storepass %pwd%

匯出的公鑰檔案為export.cert。

使用以下命令將公鑰匯入weblogic的JDK目錄的cacerts檔案中，在匯入前需要備份cacerts。cacerts金鑰庫的預設密碼為changeit，可進行修改。

#!bash
set keystore=cacerts
set alias=server
set pwd=changeit
set cert=export.cer

keytool -import -alias %alias% -keystore %keystore% -trustcacerts -storepass %pwd% -file %cert%

生成自定義證照的私鑰檔案

使用以下命令生成自定義證照的私鑰檔案。

#!bash
set keystore=keystore.jks
set tmp_p12=tmp.p12

set storepass=123456
set keypass=123456
set alias=server
set pwd_new=123456

keytool -importkeystore -srckeystore %keystore% -destkeystore %tmp_p12% -srcstoretype JKS -deststoretype PKCS12 -srcstorepass %storepass% -deststorepass %pwd_new% -srcalias %alias% -destalias %alias% -srckeypass %keypass% -destkeypass %pwd_new% 

set out_pem=tmp.rsa.pem
set final_pem=final.key

openssl pkcs12 -in %tmp_p12% -nodes -out %out_pem% -passin pass:%pwd_new%
openssl rsa -in %out_pem% -check > %final_pem% 

最終生成的final.key即為自定義證照的私鑰檔案。

修改weblogic停止指令碼

需要修改weblogic的停止指令碼“stopWebLogic.xx”，將ADMIN_URL欄位的“t3”改為“t3s”，並在java呼叫weblogic.WLST類的JVM啟動引數中加入“-Dweblogic.security.TrustKeyStore=DemoTrust”。

除了以上修改外，還需在停止指令碼的JVM啟動引數中加入“-Dweblogic.security.SSL.ignoreHostnameVerification=true”，避免因自定義證照中的地址與停止指令碼實際訪問的ssl服務的地址不一致而出現錯誤。

呼叫weblogic停止指令碼並抓包

前文中已將weblogic的停止指令碼“stopWebLogic.xx”中的訪問連結改為t3s協議，會使用SSL協議進行通訊。

需要呼叫weblogic的停止指令碼並進行抓包。由於停止指令碼會與同一臺機器的weblogic通訊，在Linux環境中抓包較為方便，需要使用tcpdump對Loopback對應的網路卡進行抓包。

使用Wireshark解密SSL通訊資料

前文已生成了weblogic的私鑰檔案，並對weblogic停止指令碼呼叫過程進行了抓包，可以使用Wireshark解密對應的SSL通訊資料。

首先在Wireshark中設定需要使用的私鑰檔案，開啟Wireshark選單的“Edit->Preferences”，開啟“Protocols->SSL”，點選“RSA keys list”旁的“Edit”按鈕，如下圖。

新增一行配置，IP為weblogic伺服器的IP，Port為weblogic的SSL監聽埠，Protocol為tcp，Key File為之前已生成的weblogic的SSL證照的私鑰檔案。

使用Wireshark開啟抓包檔案，可以看到原本為加密形式的通訊資料有部分已被解密，找到T3協議頭相關資料，可以看到停止指令碼向weblogic傳送的T3協議頭以“t3s”開頭。

伺服器返回的資料如下。

費了老大的勁，才發現原來weblogic開放HTTPS服務後，t3協議頭的前幾個位元組由“t3”變成了“t3s”。

以上步驟在Linux環境的weblogic 10.3.4測試成功。

JAVA反序列化漏洞呼叫過程

當weblogic開放HTTPS服務時，JAVA反序列化漏洞的呼叫過程如下。

#!bash
at org.apache.commons.collections.functors.InvokerTransformer.transform(InvokerTransformer.java:132)  
at org.apache.commons.collections.functors.ChainedTransformer.transform(ChainedTransformer.java:122)  
at org.apache.commons.collections.map.TransformedMap.checkSetValue(TransformedMap.java:203)  
at org.apache.commons.collections.map.AbstractInputCheckedMapDecorator$MapEntry.setValue(AbstractInputCheckedMapDecorator.java:191)  
at sun.reflect.annotation.AnnotationInvocationHandler.readObject(AnnotationInvocationHandler.java:334)  
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)  
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)  
at java.lang.reflect.Method.invoke(Method.java:597)  
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974)  
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849)  
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)  
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)  
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)  
at weblogic.rjvm.InboundMsgAbbrev.readObject(InboundMsgAbbrev.java:65)  
at weblogic.rjvm.InboundMsgAbbrev.read(InboundMsgAbbrev.java:37)  
at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:283)  
at weblogic.rjvm.MsgAbbrevInputStream.init(MsgAbbrevInputStream.java:210)  
at weblogic.rjvm.MsgAbbrevJVMConnection.dispatch(MsgAbbrevJVMConnection.java:498)  
at weblogic.rjvm.t3.MuxableSocketT3.dispatch(MuxableSocketT3.java:330)  
at weblogic.socket.BaseAbstractMuxableSocket.dispatch(BaseAbstractMuxableSocket.java:298)  
at weblogic.socket.SSLFilterImpl.dispatch(SSLFilterImpl.java:258)  
at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:950)  
at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:898)  
at weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:130)  
at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:29)  
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:42)  
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:145)  
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:117)

0x03 如何控制開放HTTPS服務的weblogic伺服器

---

如何傳送T3協議資料

利用weblogic的JAVA反序列化漏洞時，必須向weblogic傳送T3協議頭。當weblogic開放HTTPS服務時，向其傳送的T3協議頭應以“t3s”開頭。向weblogic傳送資料時應使用SSL協議，且不應對伺服器的證照進行驗證。

無論weblogic開放HTTP服務還是HTTPS服務，在向weblogic傳送利用JAVA反序列化漏洞的序列化資料時，資料內容不需要改變。

如何呼叫weblogic的RMI服務

可以利用weblogic的JAVA反序列化資料使weblogic在伺服器生成指定的jar檔案並載入，在jar檔案中開啟weblogic的RMI服務，可以從公網直接呼叫，能夠控制伺服器。

當weblogic開放HTTPS服務時，呼叫weblogic的RMI服務時有幾點需要進行修改。

1. 在呼叫weblogic的RMI服務時，使用的URL應改為以“t3s”開頭；
2. 在呼叫weblogic的RMI服務時，客戶端需要引入weblogic.jar。使用t3s協議時，weblobic.jar會嘗試從當前目錄讀取weblogic授權檔案license.bea，需要保證weblogic.jar能正確地讀取該檔案；
3. weblogic.jar中會對伺服器證照進行驗證，判斷其是否為可信證照。由於可能遇到伺服器的證照未經過CA認證，因此需要修改證照驗證的相關程式碼，忽略證照未經認證的問題；
4. JVM啟動引數需要增加“-Dweblogic.security.SSL.ignoreHostnameVerification=true”，避免因自定義證照中的地址與停止指令碼實際訪問的ssl服務的地址不一致而出現錯誤。

0x04 可行的漏洞修復方法

將SSL服務轉移至其他裝置

將SSL服務轉移至weblogic伺服器外層的裝置實現，如SSL閘道器、負載均衡、單獨部署的web代理等，將HTTP請求轉發至weblogic，可以修復JAVA反序列化漏洞。

優點	缺點
對系統影響小，不需測試對現有系統功能的影響	需要對SSL證照進行格式轉換；需要購買裝置；無法防護從內網發起的JAVA反序列化漏洞攻擊

將SSL服務轉移至weblogic伺服器的web代理

在weblogic所在伺服器安裝web代理應用，如apache、nginx等，將SSL服務轉移至web代理應用，使web代理監聽原有的weblogic監聽埠，並將HTTP請求轉發給本機的weblogic，可以修復JAVA反序列化漏洞。

優點	缺點
對系統影響小，不需測試對現有系統功能的影響；不需要購買裝置	需要對SSL證照進行格式轉換；無法防護從內網發起的JAVA反序列化漏洞攻擊；會增加伺服器的效能開銷

將SSL服務轉移至weblogic伺服器的web代理並修改weblogic的監聽IP

將weblogic的監聽地址修改為“127.0.0.1”或“localhost”，只允許本機訪問weblogic服務。

在weblogic所在伺服器安裝web代理應用，如apache、nginx等，將SSL服務轉移至web代理應用，使web代理監聽原有的weblogic監聽埠，並將HTTP請求轉發給本機的weblogic，可以修復JAVA反序列化漏洞。web代理的監聽IP需設定為“0.0.0.0”，否則其他伺服器無法訪問。

需要將weblogic停止指令碼中的ADMIN_URL引數中的IP修改為“127.0.0.1”或“localhost”，否則停止指令碼將不可用。

優點	缺點
對系統影響小，不需測試對現有系統功能的影響；不需要購買裝置；能夠防護從內網發起的JAVA反序列化漏洞攻擊	需要對SSL證照進行格式轉換；會增加伺服器的效能開銷

修改weblogic的程式碼

weblogic處理T3S協議的類為“weblogic.rjvm.t3.MuxableSocketT3S”，繼承自“weblogic.rjvm.t3.MuxableSocketT3”類，且MuxableSocketT3S類中沒有對dispatch方法進行重寫，因此可以採用與修復weblogic的JAVA反序列化漏洞的多種方法中“修改weblogic的程式碼”部分相同的修復方法。具體步驟略。

優點	缺點
不需要對SSL證照進行格式轉換；對系統影響小，不需測試對現有系統功能的影響；不需要購買裝置；能夠防護從內網發起的JAVA反序列化漏洞攻擊；不會增加伺服器的效能開銷	存在商業風險，可能給oracle的維保帶來影響

0x05 結束

---

無論weblogic伺服器開放HTTP服務還是HTTPS服務，都是有可能利用JAVA反序列化漏洞控制伺服器的。JAVA反序列化漏洞的影響，應該會持續很長的時間。