13470

0x00 前言

目前oracle還沒有在公開途徑發布weblogic的JAVA反序列化漏洞的官方補丁，目前看到的修復方法無非兩條：

使用SerialKiller替換進行序列化操作的ObjectInputStream類;
在不影響業務的情況下，臨時刪除掉項目里的 "org/apache/commons/collections/functors/InvokerTransformer.class"文件。

ObjectInputStream類為JRE的原生類，InvokerTransformer.class為weblogic基礎包中的類，對上述兩個類進行修改或刪除，實在無法保證對業務沒有影響。如果使用上述的修復方式，需要大量的測試工作。且僅僅刪除InvokerTransformer.class文件，無法保證以后不會發現其他的類存在反序列化漏洞。

因此本文針對weblogic的JAVA序列化漏洞進行了分析，對多個版本的weblogic進行了測試，并提出了更加切實可行的修復方法。

0x01 為什么選擇weblogic的JAVA反序列化漏洞進行分析

weblogic與websphere為金融行業使用較多的企業級JAVA中間件；
weblogic比websphere市場占有率高；
利用websphere的JAVA反序列化漏洞時需要訪問8880端口，該端口為websphere的wsadmin服務端口，該端口不應該暴露在公網。如果有websphere服務器的8880端口在公網可訪問，說明該服務器的安全價值相對較低；
利用weblogic的JAVA反序列化漏洞能夠直接控制服務器，危害較大，且weblogic通常只有一個服務端口，無法通過禁用公網訪問特定端口的方式修復漏洞。

0x02 已知條件

breenmachine的“What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability.”文章中對weblogic的JAVA序列化漏洞進行了分析，讀完這篇文章關于weblogic相關的描述部分后，我們知道了以下情況。

可通過搜索代碼查找weblogic的jar包中是否包含特定的JAVA類；
在調用weblogic的停止腳本時，會向weblogic發送JAVA序列化數據；
可通過ObjectInputStream.readObject方法解析JAVA序列化數據；
weblogic發送的T3數據的前幾個字節為數據長度；
替換weblogic發送的T3數據中的某個序列化數據為惡意序列化數據，可以使weblogic執行指定的代碼。

0x03 漏洞分析

weblogic發送的JAVA序列化數據抓包分析

根據breenmachine的文章我們知道了，在調用weblogic的停止腳本時，會向weblogic發送JAVA序列化數據，我們來重復這個過程。

數據包分析工具還是Windows環境的Wireshark比較好用，但Windows環境默認無法在訪問本機監聽的端口時進行抓包。上述問題是可以解決的，也可在Windows機器調用其他機器的weblogic停止腳本并使用Wireshark進行抓包；或者在Linux環境使用tcpdump進行抓包，使用Wireshark分析生成的數據包。

Windows環境如何在訪問本機監聽的端口時進行抓包

該問題可通過以下方法解決：

增加路由策略，route add 【本機IP，不能使用127.0.0.1】 mask 255.255.255.255 【默認網關IP】 metric 1，之后可以使用Wireshark抓包分析。XP測試成功，win7失敗。
使用RawCap工具，可對127.0.0.1進行抓包，產生的抓包文件可以使用Wireshark分析。win7測試成功，XP失敗。下載地址為http://www.netresec.com/?page=RawCap。

如何在Windows機器調用其他機器的weblogic停止腳本

編輯domain的bin目錄中的stopWebLogic.cmd文件，找到“ADMIN_URL=t3://[IP]:[端口]”部分，[IP]一般為本機的主機名，[端口]一般為7001。將[IP]與[端口]分別修改為其他weblogic所在機器的IP與weblogic監聽端口。執行修改后的stopWebLogic.cmd腳本并抓包。

使用Wireshark對數據包進行分析

在完成了針對weblogic停止腳本調用過程的抓包后，使用Wireshark對數據包進行分析。可使用IP或端口等條件進行過濾，只顯示與調用weblogic停止腳本相關的數據包。

已知JAVA序列化數據的前4個字節為“AC ED 00 05”，使用“tcp contains ac:ed:00:05”條件過濾出包含JAVA序列化數據的數據包，并在第一條數據包點擊右鍵選擇“Follow TCP Stream”，如下圖。

使用十六進制形式查看數據包，查找“ac ed 00 05”，可以找到對應的數據，可以確認抓包數據中包含JAVA序列化數據。

取消對"ac ed 00 05"的過濾條件，使用ASCII形式查看第一個數據包，內容如下。

可以看到當weblogic客戶端向weblogic服務器發送序列化數據時，發送的第一個包為T3協議頭，本文測試時發送的T3協議頭為“t3 9.2.0\nAS:255\nHL:19\n\n”，第一行為“t3”加weblogic客戶端的版本號。weblogic服務器的返回數據為“HELO:10.0.2.0.false\nAS:2048\nHL:19\n\n”，第一行為“HELO:”加weblogic服務器的版本號。weblogic客戶端與服務器發送的數據均以“\n\n”結尾。

將Wireshark顯示的數據包轉換為JAVA代碼

從上文的截圖可以看到數據包中JAVA序列化數據非常長，且包含不可打印字符，無法直接導出到JAVA代碼中。

在Wireshark中，客戶端向服務器發送的數據顯示為紅色，服務器向客戶端返回的數據顯示為藍色。

使用C數組形式查看第一個數據包，peer0_x數組為Packet 1，將peer0_x數組復制為一個C語言形式的數組，格式如“char peer0_0[] = { 0x01, 0x02 ...};”，將上述數據的“char”修改為“byte”，“0x”替換為“(byte)0x”，可以轉換為能直接在JAVA代碼中使用的形式，格式如“byte peer0_0[] = {(byte)0x00, (byte)0x02 ...}”。

對JAVA序列化數據進行解析

根據breenmachine的文章我們知道了，可以使用ObjectInputStream.readObject方法解析JAVA序列化數據。

使用ObjectInputStream.readObject方法解析weblogic調用停止腳本時發送的JAVA序列化數據的結構，代碼如下。執行下面的代碼時需要將weblogic.jar添加至JAVA執行的classpath中，否則會拋出ClassNotFoundException異常。

上述代碼的執行結果如下。

#!bash
Data Length-Compute: 1711  
Data Length: 1711  
Object found: weblogic.rjvm.ClassTableEntry  
Object found: weblogic.rjvm.ClassTableEntry  
Object found: weblogic.rjvm.ClassTableEntry  
Object found: weblogic.rjvm.ClassTableEntry  
Object found: weblogic.rjvm.JVMID  
Object found: weblogic.rjvm.JVMID  
size: 0 start: 0 end: 234  
size: 1 start: 234 end: 348  
size: 2 start: 348 end: 591  
size: 3 start: 591 end: 986  
size: 4 start: 986 end: 1510  
size: 5 start: 1510 end: 1634  
size: 6 start: 1634 end: 1711

可以看到weblogic發送的JAVA序列化數據分為7個部分，第一部分的前四個字節為整個數據包的長度(1711=0x6AF)，第二至七部分均為JAVA序列化數據。

weblogic發送的JAVA序列化數據格式如下圖。

利用weblogic的JAVA反序列化漏洞

在利用weblogic的JAVA反序列化漏洞時，需要向weblogic發送兩個數據包。

第一個數據包為T3的協議頭。經測試，使用“t3 9.2.0\nAS:255\nHL:19\n\n”字符串作為T3的協議頭發送給weblogic9、weblogic10g、weblogic11g、weblogic12c均合法。向weblogic發送了T3協議頭后，weblogic也會返回相應的數據，以“\n\n”結束，具體格式見前文。

第二個數據包為JAVA序列化數據，可采用兩種方式產生。

第一種生成方式為，將前文所述的weblogic發送的JAVA序列化數據的第二到七部分的JAVA序列化數據的任意一個替換為惡意的序列化數據。

采用第一種方式生成JAVA序列化數據時，數據格式如下圖。

第二種生成方式為，將前文所述的weblogic發送的JAVA序列化數據的第一部分與惡意的序列化數據進行拼接。

采用第二種方式生成JAVA序列化數據時，數據格式如下圖。

惡意序列化數據的生成過程可參考http://drops.wooyun.org/papers/13244。

當向weblogic發送上述第一種方式生成的JAVA序列化數據時，weblogic會拋出如下異常。

#!bash
java.io.EOFException  
at weblogic.utils.io.DataIO.readUnsignedByte(DataIO.java:435)  
at weblogic.utils.io.DataIO.readLength(DataIO.java:828)  
at weblogic.utils.io.ChunkedDataInputStream.readLength(ChunkedDataInputStream.java:150)  
at weblogic.utils.io.ChunkedObjectInputStream.readLength(ChunkedObjectInputStream.java:196)  
at weblogic.rjvm.InboundMsgAbbrev.read(InboundMsgAbbrev.java:37)  
at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:287)  
at weblogic.rjvm.MsgAbbrevInputStream.init(MsgAbbrevInputStream.java:212)  
at weblogic.rjvm.MsgAbbrevJVMConnection.dispatch(MsgAbbrevJVMConnection.java:507)  
at weblogic.rjvm.t3.MuxableSocketT3.dispatch(MuxableSocketT3.java:489)  
at weblogic.socket.BaseAbstractMuxableSocket.dispatch(BaseAbstractMuxableSocket.java:359)  
at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:970)  
at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:907)  
at weblogic.socket.NIOSocketMuxer.process(NIOSocketMuxer.java:495)  
at weblogic.socket.NIOSocketMuxer.processSockets(NIOSocketMuxer.java:461)  
at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:30)  
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:43)  
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:147)  
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:119)

當向weblogic發送上述第二種方式生成的JAVA序列化數據時，weblogic會拋出如下異常。

#!bash
weblogic.rjvm.BubblingAbbrever$BadAbbreviationException: Bad abbreviation value: 'xxx'  
at weblogic.rjvm.BubblingAbbrever.getValue(BubblingAbbrever.java:153)  
at weblogic.rjvm.InboundMsgAbbrev.read(InboundMsgAbbrev.java:48)  
at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:287)  
at weblogic.rjvm.MsgAbbrevInputStream.init(MsgAbbrevInputStream.java:212)  
at weblogic.rjvm.MsgAbbrevJVMConnection.dispatch(MsgAbbrevJVMConnection.java:507)  
at weblogic.rjvm.t3.MuxableSocketT3.dispatch(MuxableSocketT3.java:489)  
at weblogic.socket.BaseAbstractMuxableSocket.dispatch(BaseAbstractMuxableSocket.java:359)  
at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:970)  
at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:907)  
at weblogic.socket.NIOSocketMuxer.process(NIOSocketMuxer.java:495)  
at weblogic.socket.NIOSocketMuxer.processSockets(NIOSocketMuxer.java:461)  
at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:30)  
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:43)  
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:147)  
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:119)

雖然在利用weblogic的JAVA反序列化漏洞時，weblogic會拋出上述的異常，但是weblogic已經對惡意的序列化數據執行了readObject方法，漏洞仍然會觸發。

經測試，必須先發送T3協議頭數據包，再發送JAVA序列化數據包，才能使weblogic進行JAVA反序列化，進而觸發漏洞。如果只發送JAVA序列化數據包，不先發送T3協議頭數據包，無法觸發漏洞。

weblogic的JAVA反序列化漏洞觸發時的調用過程

將使用FileOutputStream對一個非法的文件進行寫操作的代碼構造為惡意序列化數據，并發送給weblogic，當weblogic對該序列化數據執行反充列化時，會在漏洞觸發時拋出異常，通過堆棧信息可以查看漏洞觸發時的調用過程，如下所示。

#!bash
org.apache.commons.collections.FunctorException: InvokerTransformer: The method 'newInstance' on 'class java.lang.reflect.Constructor' threw an exception  
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:356)  
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)  
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)  
at java.lang.reflect.Method.invoke(Method.java:606)  
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017)  
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1893)  
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)  
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)  
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)  
at weblogic.rjvm.InboundMsgAbbrev.readObject(InboundMsgAbbrev.java:67)  
at weblogic.rjvm.InboundMsgAbbrev.read(InboundMsgAbbrev.java:39)  
at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:287)  
at weblogic.rjvm.MsgAbbrevInputStream.init(MsgAbbrevInputStream.java:212)  
at weblogic.rjvm.MsgAbbrevJVMConnection.dispatch(MsgAbbrevJVMConnection.java:507)  
at weblogic.rjvm.t3.MuxableSocketT3.dispatch(MuxableSocketT3.java:489)  
at weblogic.socket.BaseAbstractMuxableSocket.dispatch(BaseAbstractMuxableSocket.java:359)  
at weblogic.socket.SocketMuxer.readReadySocketOnce(SocketMuxer.java:970)  
at weblogic.socket.SocketMuxer.readReadySocket(SocketMuxer.java:907)  
at weblogic.socket.NIOSocketMuxer.process(NIOSocketMuxer.java:495)  
at weblogic.socket.NIOSocketMuxer.processSockets(NIOSocketMuxer.java:461)  
at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:30)  
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:43)  
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:147)  
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:119)

確定weblogic是否使用了Apache Commons Collections組件

breenmachine在文章中寫到可以通過搜索代碼的方式查找weblogic的jar包中是否包含特定的JAVA類。由于特定的JAVA類可能在很多個不同的jar包中均存在，因此該方法無法準確判斷weblogic是否使用了Apache Commons Collections組件特定的JAVA類。

可通過以下方法準確判斷weblogic是否使用了Apache Commons Collections組件特定的JAVA類。

在weblogic中任意安裝一個j2ee應用，在某個jsp中寫入以下代碼。

#!js
<%
String path = [需要查找的類的完整類名].class.getResource("").getPath();  
out.println(path);
%>

或以下代碼。

#!js
<%
String path = [需要查找的類的完整類名].class.getProtectionDomain().getCodeSource().getLocation().getFile();  
out.println(path);
%>

使用瀏覽器訪問上述jsp文件，可以看到對應的類所在的jar包的完整路徑。

通過上述方法查找“org.apache.commons.collections.map.TransformedMap”所在的jar包，示例如下。

不同版本的weblogic對Apache Commons Collections組件的使用

“org.apache.commons.collections.map.TransformedMap”所在的weblogic的jar包信息如下。

weblogic版本	TransformedMap類所在jar包路徑
9.2	無
10.2.1(weblogic 10g)、10.3.4(weblogic 11g)	weblogic安裝目錄的modules/com.bea.core.apache.commons.collections_3.2.0.jar
12.1.3(weblogic 12c)	weblogic安裝目錄的wlserver/modules/features/weblogic.server.merged.jar

由于weblogic 9.2未包含TransformedMap類，因此無法觸發反序列化漏洞，weblogic 10g、weblogic 11g、weblogic 12c均包含TransformedMap類，因此會觸發反序列化漏洞。

0x04 漏洞修復

漏洞修復思路

weblogic的默認服務端口為7001，該端口提供了對HTTP(S)、SNMP、T3等協議的服務。由于weblogic的不同協議均使用一個端口，因此無法通過防火墻限制端口訪問的方式防護JAVA反序列化漏洞。

在絕大多數應用的使用場景中，用戶只需要在公網能夠使用HTTP(S)協議訪問web應用服務器即可。對于weblogic服務器，在絕大多數情況下，只需要能夠在公網訪問weblogic提供的HTTP(S)協議的服務即可，并不需要訪問T3協議。

少數情況下，運維人員需要使用weblogic的T3協議：

在weblogic服務器本機執行weblogic的停止腳本；
通過WLST對weblogic進行腳本化配置；
編寫使用T3協議通信的程序對weblogic進行狀態監控及其他管理功能。

T3協議與HTTP協議均基于TCP協議，T3協議以"t3"開頭，HTTP協議以“GET”、“POST”等開頭，兩者有明顯的區別。

因此可以限定只允許特定服務器訪問weblogic服務器的T3協議，能夠修復weblogic的JAVA反序列化漏洞。即使今后發現了weblogic的其他類存在JAVA反序列化漏洞，也能夠防護。

若將weblogic修復為發送T3協議時要求發送weblogic的用戶名與密碼，也能夠修復weblogic的反序列化問題，但會帶來密碼如何在weblogic客戶端存儲的問題。

無效的漏洞修復方法

首先嘗試將應用部署到非管理Server中，判斷其服務端口是否也提供T3協議的服務。

AdminServer是weblogic默認的管理Server，添加一個名為“Server-test”的非管理Server后，weblogic的服務器信息如下。管理Server與非管理Server使用不同的監聽端口，可將j2ee應用部署在非管理Server中，這樣可以使weblogic控制臺與應用使用不同的端口提供服務。

經測試，新增的非管理Server的監聽端口也提供了T3協議的服務，也存在JAVA反序列化漏洞。因此這種修復方式對于JAVA反序列化漏洞無效，但可將weblogic控制臺端口與應用端口分離，可以使用防火墻禁止通過公網訪問weblogic的控制臺。

websphere的服務端口

我們來看另一款使用廣泛的企業級JAVA中間件：websphere的服務端口情況。從下圖可以看到，websphere的應用默認HTTP服務端口為9080，應用默認HTTPS服務端口為9443，控制臺默認HTTP服務端口為9060，控制臺默認HTTPS服務端口為9043，接收JAVA序列化數據的端口為8880。因此只要通過防火墻使公網無法訪問websphere服務器的8880端口，就可以防止通過公網利用websphere的JAVA反序列化漏洞。

網絡設備對數據包的影響

對安全有一定要求的公司，在部署需要向公網用戶提供服務的weblogic服務器時，可能選擇下圖的部署架構(內網中不同網絡區域間的防火墻已省略)。

上述網絡設備對數據包的影響如下。

IPS

IPS可以更新防護規則，可能有廠家的IPS已經設置了對JAVA反序列化漏洞的防護規則，會阻斷惡意的JAVA序列化數據包。
防火墻

這里的防火墻指傳統防火墻，不是指下一代防火墻，僅關心IP與端口，不關心數據包內容，無法阻斷惡意的JAVA序列化數據包。
WAF

與IPS一樣，能否阻斷惡意的JAVA序列化數據包決定于防護規則。
web代理

僅對HTTP協議進行代理轉發，不會對T3協議進行代理轉發。
負載均衡

可以指定需要進行負載均衡的協議類型，安全起見應選擇HTTP協議而不是TCP協議，只對HTTP協議進行轉發，不對T3協議進行轉發。

根據以上分析可以看出，web代理和負載均衡能夠穩定保證只轉發HTTP協議的數據，不會轉發T3協議的數據，因此能夠防護JAVA反序列化漏洞。

如果在公網訪問weblogic服務器的路徑中原本就部署了web代理或負載均衡，就能夠防護從公網發起的JAVA反序列化漏洞攻擊。這也是為什么較少發現大型公司的weblogic反序列化漏洞的原因，其網絡架構決定了weblogic的JAVA反序列化漏洞無法在公網利用。

可行的漏洞修復方法

部署負載均衡設備

在weblogic服務器外層部署負載均衡設備，可以修復JAVA反序列化漏洞。

優點	缺點
對系統影響小，不需測試對現有系統功能的影響	需要購買設備；無法防護從內網發起的JAVA反序列化漏洞攻擊

部署單獨的web代理

在weblogic服務器外層部署單獨的web代理，可以修復JAVA反序列化漏洞。

優點	缺點
同上	同上

在weblogic服務器部署web代理

在weblogic控制臺中修改weblogic的監聽端口，如下圖。

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

優點	缺點
對系統影響小，不需測試對現有系統功能的影響；不需要購買設備	無法防護從內網發起的JAVA反序列化漏洞攻擊；會增加服務器的性能開銷

在weblogic服務器部署web代理并修改weblogic服務器的監聽IP

在weblogic控制臺中修改weblogic的監聽端口，并將監聽地址修改為“127.0.0.1”或“localhost”，如下圖。經過上述修改后，只有weblogic服務器本機才能訪問weblogic服務。

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

需要將weblogic停止腳本中的ADMIN_URL參數中的IP修改為“127.0.0.1”或“localhost”，否則停止腳本將不可用。

優點	缺點
對系統影響小，不需測試對現有系統功能的影響；不需要購買設備；能夠防護從內網發起的JAVA反序列化漏洞攻擊	會增加服務器的性能開銷

修改weblogic的代碼

weblogic處理T3協議的類為“weblogic.rjvm.t3.MuxableSocketT3”，不同版本的weblogic的該類在不同的jar包中，查找某個類所在的jar包的方法見前文“確定weblogic是否使用了Apache Commons Collections組件”部分。

使用eclipse或其他IDE創建java工程，創建weblogic.rjvm.t3包，并在其中創建MuxableSocketT3.java文件。在定位到“weblogic.rjvm.t3.MuxableSocketT3”類所在的weblogic的jar包后，對其進行反編譯，將對應的jar包加入到創建的java工程的classpath中。將原始MuxableSocketT3類的反編譯代碼復制到創建的java工程的MuxableSocketT3.java中，若其中引入了其他jar包中的類，需要將對應的jar包也加入到java工程的classpath中。

weblogic處理T3協議時會調用MuxableSocketT3類的dispatch方法，weblogic 12.1.3的dispatch方法原始代碼如下。

#!java
public final void dispatch(Chunk list) {
    if (!(this.bootstrapped)) {
        try {
            readBootstrapMessage(list);
            this.bootstrapped = true;
        } catch (IOException ioe) {
            SocketMuxer.getMuxer().deliverHasException(getSocketFilter(),
                    ioe);
        }
    } else
        this.connection.dispatch(list);
}

在該方法中增加限制客戶端IP的處理，若發送T3協議數據的客戶端IP不是允許的IP，則拒絕連接。增加限制后的dispatch方法代碼如下。

#!java
public final void dispatch(Chunk list) {
    if (!(this.bootstrapped)) {
        try {

            //add
            String ip = getSocket().getInetAddress().getHostAddress();
            System.out.println("MuxableSocketT3-dispatch-ip: " + ip);
            if(!ip.equals("127.0.0.1") && !ip.equals("0:0:0:0:0:0:0:1"))
                rejectConnection(1, "Illegal IP");
            //add-end

            readBootstrapMessage(list);
            this.bootstrapped = true;
        } catch (IOException ioe) {
            SocketMuxer.getMuxer().deliverHasException(getSocketFilter(),
                    ioe);
        }
    } else
        this.connection.dispatch(list);
}

停止weblogic，將編譯生成的MuxableSocketT3*.class文件替換至MuxableSocketT3所在的jar包中，啟動weblogic，再次向weblogic發送T3協議數據包，可以看到如下輸出。

上圖說明上文增加的代碼已正確運行，對weblogic的正常功能沒有影響，且能夠限制發送T3數據的客戶端IP，能夠修復反序列化漏洞。

當weblogic處理HTTP協議時，不會調用MuxableSocketT3類，因此上述修改不會影響正常的業務功能。

可通過環境變量或配置文件指定允許發送T3協議的客戶端IP，在修改后的dispatch方法中讀取，本文的示例僅允許本機發送T3協議。需要將weblogic停止腳本中的ADMIN_URL參數中的IP修改為“127.0.0.1”或“localhost”，否則停止腳本將不可用。

優點	缺點
對系統影響小，不需測試對現有系統功能的影響；不需要購買設備；能夠防護從內網發起的JAVA反序列化漏洞攻擊；不會增加服務器的性能開銷	存在商業風險，可能給oracle的維保帶來影響

上述修復方法的最大問題在于可能給oracle維保帶來影響，不過相信沒有與oracle簽訂維保合同的公司也是很多的，如果不擔心相關的問題，倒是可以使用這種修復方法。如果能夠要求oracle提供官方補丁，當然是最好不過了。

亚洲欧美在线