從Blind XXE漏洞到讀取Root文件的系統提權案例分析

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

*本文中涉及到的相關漏洞已報送廠商并得到修復，本文僅限技術研究與討論，嚴禁用于非法用途，否則產生的一切后果自行承擔。

在最近的漏洞眾測過程中，作者測試XXE漏洞時，遇到了一個有意思的XML服務端。該服務端在網上基本沒什么記錄和參考，唯一能找到相關的，只是一篇2016年初，某開發人員應用該服務端遇到困難時，尋求幫助的發貼。在以下文章中，作者分享了測試該服務端時的一些思路，最終，作者利用了一個中危漏洞的Blind XXE，發現了可讀取root級別文件的高危漏洞，成功實現了系統提權。

文中刻意著重描述了測試過程中遇到的各種錯誤消息，希望對讀者有所啟發和幫助。另外，由于是邀請測試，出于保密，其中所有涉及服務端的可識別信息都已了作了隱匿處理。

一開始的發現

起初，引起我注意的是一個響應XML格式消息和404狀態的服務端，如下：

但當我把請求方法更改為POST，且在其中添加了一個 Content-Type: application/xml 這樣的頭，和一個無效的XML內容體，之后，響應消息多了一些有意思的變化，看似有點XXE的意思：

然而，當添加進入的是一個正常結構的XML文檔之后，響應消息有了更進一步的變化：

請注意，服務端顯然希望提供密碼或憑據信息才能與其進行正常交互，遺憾的是，當前項目沒有任何文檔提及憑據的具體形式，而且我也沒找到任何有效的憑據信息。確實，之前我做過的一些XXE利用方式需要與目標服務端進行某些形式的“有效”交互，才能成功起效。所以，現在看來，沒有憑據，想要深入利用XXE漏洞就非常難了。

但是，雖然如此，我們也不必灰心。由于XML文檔結構包括XML聲明、DTD文檔類型定義和文檔元素信息，所以這里我們可以來測試一下 DOCTYPE 定義，看看服務端是否完全禁用了外部實體的應用，或者試試其它有什么響應。所以，我又接著構造了以下包含DOCTYPE，且利用了Collaborator模塊進行帶外測試的請求，并有了相應響應：

服務器無法對您的請求做出及時響應。！？之后，我又仔細在Burp Collaborator中的檢查了相關交互，迫切希望其中能發現一個傳入的HTTP請求，但是只看到了以下畫面：

非常不幸，服務端貌似可以解析我的burpcollaborator.net代理域名，但卻沒有出現HTTP請求，而且服務端在幾秒之后出現了500的超時響應狀態。

這看似是服務端防火墻的作用了，我繼續針對其它端口進行出站HTTP請求測試，但都無功而返。所有端口都會顯示超時，也就是說目標服務端部署的防火墻能成功阻斷所有非正常出站流量，安全防護做的還不錯嘛！

實現 Blind XXE

基于以上發現，我搗鼓一通，測試發現了一個問題，但還不太確定，我只有通過嘗試訪問一些本地文件、內部網絡或相關服務，來證明它可能會是一個中危漏洞。

該漏洞問題的影響是，我可以用它來成功探測目標服務端上一些文件的存在性，如下：

響應消息說明了文件的存在可能，而且能被服務端的XML解析器正常打開讀取，但由于文件內容不是一個有效的XML文檔類型定義，所以解析器解析失敗并拋出了一個錯誤。換句話說，服務端未禁用外部實體的加載，但我們卻沒看到任何輸出信息，所以，從這個角度來說，這看似是一個Blind    XXE漏洞。

此外，我們可以假設服務端運行的解析器是 Java 的 SAX解析器，因為從響應報錯消息來看，它似乎和Java錯誤類  org.xml.sax.SAXParseExceptionpublicId 相關，這就有意思了，因為Java在XXE方面具備很多特性，之后我們會做講解。

當我們構造訪問的文件在服務端不存在時，其響應為：

OK，這看似是有用，但還不夠說明問題。我在想，能不能利用這個Blind XXE漏洞開展一些對目標服務端的原始端口探測掃描呢？如下：

這種方法不錯，可行的話證明我們可以枚舉出目標服務端的內部服務，這雖然能反映些許問題，但還不是我想要的效果。這樣的Blind XXE漏洞看似和Blind SSRF漏洞有些相同：可以發起對內部服務的HTTP請求，但卻不能讀取響應。

所以，我就好奇能不能用其它SSRF相關技巧來間接利用這個Blind XXE漏洞呢。先可以做的就是查看服務端的其它協議使用情況了，如https、gopher、ftp、jar、scp等等，雖然最終對這些協議的測試沒有實質性的效果，但從服務端的錯誤響應消息中可以得到很多有用信息。如：

是不是很有意思，服務端能識別我們提供的使用協議，并做出錯誤響應。這個點可以先記下，以備后用。

因為和Blind SSRF漏洞的相似性，所以可以利用它來探測一些內部Web服務。由于這家公司和非常廣泛多樣的開發團隊都有合作，并且在其Github開發文檔中也涉及了大量形如x.company.internal樣式的內部主機說明，我發現目標公司部署了如下的一些內部服務資源：

wiki.company.internal

jira.company.internal

confluence.company.internal

由于之前的防火墻阻斷了我的出站流量，在這里，我想驗證它是否會對內部服務的流量進行阻斷，或是這些內部服務是否真的存在。

從以上響應結果來看很有意思，可以看到報錯消息說明，我們請求的內部資源被服務端讀取了，只被識別為錯誤格式。也就是說，內部資源的讀取是被允許的，而且我們的請求也是有效的。

這就是厲害所在了，利用Blind XXE漏洞可以發起對目標系統內部Web服務的請求、枚舉文件存在可能、枚舉所有可能的運行服務。基于這些危害，我上報了漏洞。但當我周末出外旅行時，我卻一直在思考這個漏洞，覺得應該還有其它深入發現的可能性。

盲人國里,獨眼稱王

經過一個周末的休整和思路調整，我決定對這個Blind XXE漏洞再繼續深挖。尤其是，我意識到如果我能在目標服務端內部找到類似代理作用的主機，就可以把未做安全過濾的內部服務流量路由到外部來。

常來說，要從無法讀取響應的Web應用中去發現漏洞相當之難，但好在，早前社區披露過一個針對Jira應用的SSRF漏洞，并已在多篇發文中提到過具體的利用方法。    

為此，我急切地想利用這個方法來映證我在Github上發現的目標公司的Jira應用：jira.company.internal，構造的請求和對應的響應如下：

從響應消息中可以看到，可能是SSL驗證方式出錯導致了HTTPS請求有問題，另外，通常的Jira實例都是運行在8080端口之上的，那么，我們就換成HTTP，加上8080端口試試：

然后，我查看了 Burp Collaborator 模塊的交互信息，并沒什么發現，可能是服務端的Jira實例打了補丁或是禁用了存在漏洞的插件。之后，我漫無目的地在wiki.company.internal上去找SSRF漏洞，最后，我決定在confluence.company.internal上嘗試一下和jira.company.internal相同的測試方法，只是我把測試端口換成了confluence應用的默認端口8090：

等等，這是什么？多了一個HTTP請求：

成功了！這樣就可以通過confluence實例，繞過防火墻限制，把內部流量間接轉向外部了。也就意味著，我們可以在上面進行一些經典的XXE攻擊了。首先，我們構造出一個如下內容的惡意文件evil.xml，并把其托管在攻擊者服務器上，希望最終能觸發出有用的信息來。

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

讓我們來仔細看看上面這個文件的具體定義：

1、把外部引用（這里是系統的/目錄）加載到變量%file中來；

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

3、嘗試在%file處訪問資源，并將該位置的內容加載到實體的data中。

注意，我們希望上述第3方面的定義執行失效，因為%file處的內容將不會指向一個有效的資源位置，而只是會包含完整的目錄內容。

現在，利用confluence.company.internal這個內部實例來指向我們的惡意文件evil.xml，并要保證其中的 %ent 和 &data 要能被訪問到，以觸發目錄訪問。太好了，響應最終列出了服務端的所有目錄信息：

有意思的是，這顯示了另一種從服務端獲取錯誤響應的方法，即指定一個“missing”丟失的協議，而不是我們前面看到的無效協議。這也可幫助我們解決在讀取包含冒號的文件時遇到的問題，例如用上述方法讀取/etc/passwd時會導致以下錯誤:

換句話說，第一次出現在冒號:之前，是可以讀取文件的，但冒號之后的東西就不能再被讀取了。如何來繞過這一點并在響應消息中顯示具體文件內容呢？那就是在文件內容之前加上一個冒號，這會導致出現“no protocol”錯誤，因為首個冒號之前的字段是空的，如未定義樣式。所以，我們在攻擊者服務器上的托管文件    evil.xml 可構造如下：

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

最終的結果如下：

讀取/root目錄文件的結果：

就這樣，針對目標公司系統，通過濫用不當的網絡隔離措施、未打補丁的內部應用服務、未作權限配置的Web服務器和存在信息泄露的錯誤響應，我們就能從Blind XXE的中危漏洞，提權至可讀取root級別文件的高危漏洞，實現了對目標系統的控制。

經驗總結

紅隊：

如果發現有意思的東西，就繼續深挖；

Java SAX解析器對URL模式的處理方式，存在一些提取有用信息的新方法。當前流行的Java版本都不允許將多行文件通過外部HTTP請求（如http://attacker.org/?&file）方式竊取導出，但卻可能從一些錯誤響應消息甚至URL協議中，獲得一些目標系統相關的多行響應信息。

藍隊：

積極修補內部服務系統存在的漏洞補丁；

不能簡單地把內部網絡認為是安全的，應該做不同信任級別的劃分；

錯誤消息應該傳入錯誤日志，而不是HTTP響應中；

身份驗證并不能有效緩解防護如XXE漏洞的安全問題。

漏洞上報進程

2018.11.26     發現有意思的XML服務端

2018.11.28    上報Blind XXE漏洞，風險在于可列舉文件、目錄、內部網絡位置和服務端口

2018.12.3      發現存在漏洞的內部Confluence應用服務器，上報測試PoC視頻，演示了讀取根目錄文件

2018.12.4      公司漏洞修復并發放漏洞賞金

2018.12.6      申請對該測試的文章披露

2018.12.12     獲得批準

感謝你能夠認真閱讀完這篇文章，希望小編分享的“從Blind XXE漏洞到讀取Root文件的系統提權案例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!