[[183606]]

近期，俄羅斯?jié)B透測試人員Vladimir Ivanov發(fā)現(xiàn)了反勒索數(shù)據備份服務商Code42的一個XXE 0day漏洞，利用該漏洞可以從使用Code42服務的公司竊取相關備份數(shù)據，這些公司包括Uber、Adobe、Lockheed Martin(洛克希德馬丁)等。作者在這篇文章中分享了該漏洞的發(fā)現(xiàn)過程。

Code 42，成立于2007年，最初以個人數(shù)據保護和備份軟件起家，隨后便逐漸拓展到了企業(yè)數(shù)據備份和反勒索服務領域。目前該公司在全球管理并保護著大量企業(yè)和組織機構數(shù)據，而且該公司所有的數(shù)據備份和存儲解決方案都是跨平臺的。

漏洞發(fā)現(xiàn)過程

2016年5月，我在參與HackerOne平臺的Uber漏洞賞金項目過程中，偶然通過測試發(fā)現(xiàn)了以下這個HTTP應用管理頁面，這是Uber與合作公司Code42的一個系統(tǒng)服務：

通過該頁面的API接口https://backup.uberinternal.com:4285/api/serverEnv 分析發(fā)現(xiàn)，其部署使用了Code42最新版本(5.2.0)的服務框架，而且Code42的相關產品在CVE漏洞庫中沒有任何披露漏洞，想要發(fā)現(xiàn)安全問題，密碼破解顯然不是一個可行方案，唯一可行的選擇就是，去發(fā)現(xiàn)該系統(tǒng)的未知漏洞。

接下來，我從Code42官網瀏覽了一些公開說明文檔，從中尋找涉及的API接口的方法描述，然后構造自動化的暴力猜解方式去請求這些接口，嘗試發(fā)現(xiàn)其中一些不需要身份驗證的API。幸運的是，最終發(fā)現(xiàn)其中一個API存在問題，任何外部用戶都可以對其作出有效的登錄訪問：https://www.crashplan.com/apidocviewer/#SsoAuthLoginResponse

在Code42公開文檔中對/api/SsoAuthLoginResponse的描述是這樣的：接收SAMLResponse的GET參數(shù)，其中SAMLResponse包含了base64編碼的XML用戶驗證數(shù)據：

由此，我構造了一個指向我個人VPS的XML外部實體對該API接口進行測試，盡管測試中使用的XXE漏洞利用代碼非常簡單，但出于保密，在此就不做公開。從以下測試的端口監(jiān)聽信息可以看出，該服務系統(tǒng)存在XXE外帶數(shù)據(Out-of-Band)攻擊漏洞：(XXE-OOB漏洞詳情參考Freebuf-《DTD/XXE 攻擊筆記分享》、BlackHat 2013 《XXE-Out of Band Attack》)

由于系該統(tǒng)使用了java框架，而俄羅斯的OnSec實驗室曾針對Java程序的XXE-OOB攻擊，作出了相關研究，并給出相應的payload，和一個通過ftp服務讀取系統(tǒng)目錄的漏洞利用腳本xxe-ftp.rb，因此，我直接用xxe-ftp程序進行了驗證。

xxe-ftp.rb原理是這樣的，攻擊者主機運行該腳本后，8088端口作為http服務端負責獲取OOB攻擊payload，而8077端口用于ftp連接服務：

經驗證，我成功獲取到了系統(tǒng)服務器/home/目錄下的列表，并向HackerOne平臺作了漏洞報告，獲取列表截圖如下：

經Uber安全團隊向Code42確認，這是一個0day漏洞，Uber安全團隊要求我給出更多漏洞詳細證明。在他們的許可下，我又作了進一步滲透測試，最終發(fā)現(xiàn)了備份日志的存儲目錄文件。以下是系統(tǒng)服務器本地最近的某一儲存日志文件，其中包含了操作用戶名和其它敏感信息：

測試結果已經很能說明問題：只要運行有Code42周邊服務或托管業(yè)務的公司，我都可以利用該漏洞獲取到其備份系統(tǒng)網站內的所有備份文件。為了解該漏洞的現(xiàn)實威脅，我利用Code42服務端口4285在shodan上進行識別，發(fā)現(xiàn)了一些使用Code42相關服務的IP，其中還包括了一家全球知名的安全公司*&^#$#!：

漏洞披露進程

• 2016.5.6 通過HackerOne向Uber提交最初漏洞報告;
• 2016.5.23 Code42更新了軟件，并釋出了最新安全的5.2.0.1版本軟件;
• 2016.6.28 Uber向我發(fā)放了9000美元漏洞賞金;
• 2016.8.24 Code42要求我待其所有客戶公司部署完最新版軟件后再發(fā)表該漏洞的分析文章;
• 2017.1.24 Code42告知我可以發(fā)表文章。