這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)怎么實(shí)現(xiàn)WebLogic RCECVE-2019-2725漏洞分析，文章內(nèi)容豐富且以專(zhuān)業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
公司主營(yíng)業(yè)務(wù)：做網(wǎng)站、
成都網(wǎng)站設(shè)計(jì)、移動(dòng)網(wǎng)站開(kāi)發(fā)等業(yè)務(wù)。幫助企業(yè)客戶(hù)真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。
成都創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開(kāi)放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來(lái)的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶(hù)帶來(lái)驚喜。
成都創(chuàng)新互聯(lián)推出
桐廬免費(fèi)做網(wǎng)站回饋大家。
2019年4月17日，CNVD 發(fā)布
《關(guān)于Oracle WebLogic wls9-async組件存在反序列化遠(yuǎn)程命令執(zhí)行漏洞的安全公告》
，公告指出部分版本W(wǎng)ebLogic中默認(rèn)包含的wls9_async_response包，為WebLogic Server提供異步通訊服務(wù)。由于該WAR包在反序列化處理輸入信息時(shí)存在缺陷，攻擊者可以發(fā)送精心構(gòu)造的惡意 HTTP 請(qǐng)求，獲得目標(biāo)服務(wù)器的權(quán)限，在未授權(quán)的情況下遠(yuǎn)程執(zhí)行命令。
2019年4月18日，開(kāi)始應(yīng)急。因?yàn)檫@個(gè)漏洞當(dāng)時(shí)屬于0day，也沒(méi)有補(bǔ)丁可以參考，只能參考公告內(nèi)容一步一步來(lái)看了。首先看到公告里提到的wls9_async_response.war包，看下web.xml里的url。
看到/AsyncResponseService，嘗試訪問(wèn)一下，404。之后看到weblogic.xml和weblogic-webservices.xml
訪問(wèn)下_async/AsyncResponseService
可以正常訪問(wèn)，再結(jié)合公告中的漏洞處置建議，禁止 /_async/* 路徑的URL訪問(wèn)，可以大概率猜測(cè)，漏洞入口在這里。
在weblogic-webservices.xml中有一個(gè)類(lèi)，weblogic.wsee.async.AsyncResponseBean，跟進(jìn)去這個(gè)類(lèi)，發(fā)現(xiàn)在wseeclient.jar里面
而后我在這個(gè)類(lèi)里面的方法下斷點(diǎn)，然后構(gòu)造一個(gè)普通的SOAP消息，發(fā)送。
斷點(diǎn)沒(méi)有debug到。最后我把wsee/async所有類(lèi)的所有方法都下了斷點(diǎn)，重新發(fā)送消息，成功在AsyncResponseHandler類(lèi)中的handleRequest攔截到了。
繼續(xù)流程，String var2 = (String)var1.getProperty("weblogic.wsee.addressing.RelatesTo");這個(gè)步驟一直取不到值，導(dǎo)致流程結(jié)束。為了解決這個(gè)問(wèn)題，翻了不少資料，最后找到一個(gè)類(lèi)似的例子，可以使用test為weblogic.wsee.addressing.RelatesTo賦值。
demo
test
之后流程就能夠繼續(xù)下去了，我一直以為漏洞的關(guān)鍵點(diǎn)在這里，因?yàn)檫@個(gè)wsee.async下面的幾個(gè)類(lèi)中有readObject方法，我一直嘗試著通過(guò)AsyncResponseHandler跳到readObject方法，而后就卡在這里，后面的流程就不寫(xiě)了，對(duì)這個(gè)漏洞來(lái)說(shuō)是錯(cuò)的，上面寫(xiě)的這些猜測(cè)和流程都是正確的。
419
2019年4月19日，和我一起應(yīng)急的師傅給我發(fā)了一張截圖。
看到這截圖里面的RelatesTo，我還以為之前的推測(cè)沒(méi)有錯(cuò)，只是沒(méi)有構(gòu)造好。
全局搜索UnitOfWorkChangeSet這個(gè)類(lèi)，之后在這個(gè)類(lèi)中下斷點(diǎn)。
根據(jù)截圖，構(gòu)造一個(gè)類(lèi)似的，然后發(fā)送
在這個(gè)類(lèi)中debug到了。
看到了日思夜想的readObject，有了反序列的點(diǎn)，自然要找利用鏈了，目前 WebLogic 下面 commoncollections 相關(guān)的利用鏈已經(jīng)是無(wú)法使用了，WebLoigc 依賴(lài)的common-collections版本已經(jīng)升級(jí)了，先找個(gè)Jdk7u21測(cè)試一下，將生成的 payload 轉(zhuǎn)換成 byte，發(fā)送。
可以看到，成功地執(zhí)行了命令。但是這個(gè)利用鏈限制太大了，基本沒(méi)啥用。我想起去年應(yīng)急過(guò)的一個(gè)WebLogic 反序列漏洞，CVE-2018-3191，既然jdk7u21都不受黑名單限制，想來(lái)CVE-2018-3191也是一樣可以利用的。
猜測(cè)沒(méi)有錯(cuò)誤，CVE-2018-3191也是能夠利用的，這個(gè)漏洞也終于有點(diǎn)"危害"了。和 pyn3rd 師傅討論一下有沒(méi)有其他利用鏈，仔細(xì)翻下黑名單，除了CVE-2018-3191，就只有新的jython利用鏈(CVE-2019-2645)了，由 Matthias Kaiser大佬提交的，但是目前這個(gè)還有沒(méi)有公開(kāi)，所以這個(gè)利用鏈也沒(méi)法使用。
有了正確答案，就可以看下之前的猜測(cè)哪里出了問(wèn)題。
回到AsyncResponseHandler類(lèi)中的handleRequest，handleRequest的上一步，HandlerIterator類(lèi)中的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;
}會(huì)遍歷this.handlers，然后調(diào)用每個(gè)handler的handleRequest去處理用戶(hù)傳入的SOAP Message。
可以看到，AsyncResponseHandler僅僅只是21個(gè)handler之中的一個(gè)，而weblogic.wsee.addressing.RelatesTo的賦值就是在ServerAddressingHandler中完成的，有興趣的可以去跟一下。這里面有一個(gè)非常重要的handler--WorkAreaServerHandler，看名字可能覺(jué)得眼熟，看到里面的handleRequest方法可能就不淡定了。
之后的流程就和CVE-2017-10271是一樣的了，關(guān)于這個(gè)漏洞的分析可以參考廖師傅的
文章
。
跟到這里就可以看出來(lái)了，這個(gè)url只是CVE-2017-10271漏洞的另外一個(gè)入口而已。這也是后期導(dǎo)致假PoC泛濫的一個(gè)原因。整個(gè)流程大概如下：
那么問(wèn)題來(lái)了，這個(gè)PoC是如何繞過(guò)CVE-2017-10271的黑名單的呢？
首先來(lái)看一下CVE-2017-10271的補(bǔ)丁，會(huì)將傳入的數(shù)據(jù)先調(diào)用validate校驗(yàn)，通過(guò)之后才交給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這些標(biāo)簽都被攔截了，遇到直接拋出錯(cuò)誤。void標(biāo)簽后面只能跟index，array標(biāo)簽后面可以跟class屬性，但是類(lèi)型只能是byte類(lèi)型的。其中，過(guò)濾object標(biāo)簽是CVE-2017-3506的補(bǔ)丁，剩下的過(guò)濾是針對(duì)CVE-2017-10271的補(bǔ)丁。
如果仔細(xì)看了黑名單的，就不難發(fā)現(xiàn)，外面流傳的很多PoC都是假的，就是新url入口+老的payload，這樣的組合是沒(méi)有辦法繞過(guò)這個(gè)黑名單的。
繞過(guò)這個(gè)黑名單的關(guān)鍵是class標(biāo)簽，可以從官方的
文檔
來(lái)了解一下這個(gè)標(biāo)簽。
class標(biāo)簽可以表示一個(gè)類(lèi)的實(shí)例，也就是說(shuō)可以使用class標(biāo)簽來(lái)創(chuàng)建任意類(lèi)的實(shí)例。而class標(biāo)簽又不在WebLogic 的黑名單之內(nèi)，這才是這個(gè)漏洞最根本的原因。4月26日，Oracle 發(fā)布這個(gè)漏洞的補(bǔ)丁，過(guò)濾了class標(biāo)簽也證實(shí)了這點(diǎn)。
既然漏洞的原因是繞過(guò)了CVE-2017-10271的黑名單，那么wls-wsat.war也是應(yīng)該受影響的。
測(cè)試一下，沒(méi)有問(wèn)題。
這說(shuō)明，CNVD的公告寫(xiě)的影響組件不全，漏洞處置建議也寫(xiě)的不全面，要通過(guò)訪問(wèn)策略控制禁止 /_async/* 及 /wls-wsat/* 路徑的URL訪問(wèn)才行，之后我們也同步給了CNVD，CNVD發(fā)了
第二次通告
。
421
2019年4月21日，準(zhǔn)備構(gòu)造出這個(gè)漏洞的檢測(cè)PoC，能夠使用class標(biāo)簽來(lái)創(chuàng)建類(lèi)的實(shí)例，我首先考慮的是構(gòu)造java.net.Socket，這也引出了一個(gè)JDK版本的坑。我測(cè)試的是jdk6，參考之前的PoC，可以這么構(gòu)造
java.net.Socket
aaaaabbbbbbbbbbb.wfanwb.ceye.io
80
ceye成功接收到請(qǐng)求，也說(shuō)明Socket實(shí)例創(chuàng)建成功了。
我把上面的檢測(cè)PoC在 jdk 7上測(cè)試，竟然失敗了，一直爆找不到java.net.Socket這個(gè)類(lèi)錯(cuò)誤，讓我一度以為這個(gè)漏洞只能在 jdk 6 下面觸發(fā)，后來(lái)仔細(xì)對(duì)比，發(fā)現(xiàn)是換行符的問(wèn)題，也就是這樣寫(xiě)才對(duì)。
java.net.Socketaaaaabbbbbbbbbbb.wfanwb.ceye.io80
不帶換行符的在6和7下面都能生成實(shí)例。其實(shí)這個(gè)問(wèn)題在最早測(cè)試 CVE-2018-3191 payload的時(shí)候就已經(jīng)發(fā)生過(guò)，pyn3rd師傅問(wèn)我xml payload是怎么生成的，我說(shuō)用的拼接，直接System.out.println輸出的，都帶了換行符，我因?yàn)楫?dāng)時(shí)跑weblogic的jdk是jdk6，所以沒(méi)有問(wèn)題，但是 pyn3rd 師傅的環(huán)境是 jdk7 的，沒(méi)測(cè)試成功，只覺(jué)得是PoC寫(xiě)法不同造成的問(wèn)題，后來(lái)師傅自己解決了，這里也沒(méi)溝通，埋下了一個(gè)大坑，導(dǎo)致我后面踩進(jìn)去了。
422
2019年4月22日，pyn3rd 師傅測(cè)試 WebLogic 12.1.3沒(méi)成功，發(fā)現(xiàn)是12的版本沒(méi)有oracle.toplink.internal.sessions.UnitOfWorkChangeSet這個(gè)類(lèi)，所以沒(méi)辦法利用。嘗試著構(gòu)造新的exp，目前的情況是，能夠創(chuàng)建類(lèi)的實(shí)例，但是調(diào)用不了方法。自然想起com.sun.rowset.JdbcRowSetImpl這個(gè)類(lèi)。
rmi://localhost:1099/Exploit
true
這個(gè)是CVE-2017-10271的一種觸發(fā)方法。之前的黑名單提過(guò)，void標(biāo)簽后面只能跟index，所以上面這個(gè)payload肯定會(huì)被黑名單攔截。嘗試使用class標(biāo)簽重寫(xiě)上面的payload。
構(gòu)造的過(guò)程中，在跟底層代碼的時(shí)候，發(fā)現(xiàn) jdk 6和 jdk 7處理標(biāo)簽的方式不同。
jdk 6使用的是com.sun.beans.ObjectHandler
能用的有string，class，null，void，array，java，object和一些基本類(lèi)型標(biāo)簽(如int)。
jdk7 使用的是com.sun.beans.decoder.DocumentHandler
可以看到，和jdk6差異不小，例如，jdk 6不支持new，property等標(biāo)簽。
我在用jdk 6 的標(biāo)簽構(gòu)造的時(shí)候，一直沒(méi)構(gòu)造成功，直到我看到j(luò)dk 7 的源碼里面的property，這不就是我想要的么，而且這個(gè)標(biāo)簽還不在 WebLogic 的黑名單內(nèi)。所以重寫(xiě)上面的payload如下
可以看到，沒(méi)有觸發(fā)黑名單，成功的執(zhí)行了命令，而且沒(méi)有依賴(lài) WebLogic 內(nèi)部的包，10.3.6和12.1.3都可以通用。遺憾的是，這個(gè)payload的打不了 jdk 6的，因?yàn)?jdk 6 不支持 property標(biāo)簽。期望有大佬能寫(xiě)出6也能用的。
423
2019年4月23日，在CNVD發(fā)出通告，各大安全公司發(fā)出漏洞預(yù)警之后，之前提過(guò)的新url+老payload的這種模式的PoC和exp紛紛出爐。不僅是國(guó)內(nèi)，國(guó)外也很熱鬧，很多人表示測(cè)試成功，但是都是在無(wú)補(bǔ)丁的情況下測(cè)試的。Oracle 官網(wǎng)下載的 WebLogic 都是沒(méi)有安裝補(bǔ)丁的，Oracle的補(bǔ)丁是單獨(dú)收費(fèi)的，如果安裝了 CVE-2017-10271 的補(bǔ)丁，這些PoC和exp都是沒(méi)有辦法觸發(fā)的，繞過(guò)不了黑名單。
426
2019年4月26日，Oracle 官方發(fā)布緊急補(bǔ)丁，并為該漏洞分配編號(hào)CVE-2019-2725。
427
2019年4月27日，pyn3rd 師傅說(shuō)12.1.3版本的exp也有人弄出來(lái)了，用的是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);
}
}看下這個(gè)類(lèi)的構(gòu)造方法，直接將傳入的xml交給XMLdecoder處理，太粗暴了...
相當(dāng)于經(jīng)過(guò)了兩次XMLdecode，所以外層用
這種exp也是最完美的，沒(méi)有jdk版本限制，不需要外連，可惜的是只能打12.1.3版本。
430
2019年4月30日，在其他大佬手中看到了這個(gè)漏洞的其他利用方式，沒(méi)有 weblogic和 jdk的版本限制，比上面的幾種利用方式都更完善。這種利用方式我之前也看到過(guò)，就是Tenable 發(fā)的
演示視頻
，當(dāng)時(shí)沒(méi)想明白，看了大佬的利用方式之后，才明白自己忽略了什么。構(gòu)造方式可以參考CVE-2017-17485，我之前構(gòu)造exp的時(shí)候也沒(méi)有往這方面想，這或許就是黑哥說(shuō)的積累不夠吧。
上述就是小編為大家分享的怎么實(shí)現(xiàn)WebLogic RCECVE-2019-2725漏洞分析了，如果剛好有類(lèi)似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道。
本文標(biāo)題：怎么實(shí)現(xiàn)WebLogicRCECVE-2019-2725漏洞分析-創(chuàng)新互聯(lián)
文章URL：
http://weahome.cn/article/digoch.html
重慶分公司
重慶分公司
