看我如何發現Google生產網路SSRF漏洞獲取$13337賞金

今年3月份時，我曾上報過Google的任意html/javascript網頁在線嵌入工具Caja的一個XSS漏洞，到5月份時，這個漏洞才被修復。之後，我想看看谷歌協作平台（Google Sites）網站調用的Caja服務是否還存在這個未修復漏洞。於是，對Google Sites進行了一番測試，可惜這個Caja XSS漏洞是不存在的，但經過其它方向的深入測試，我發現了Google內部生產網路的SSRF漏洞。

背景介紹

Google Sites：谷歌協作平台是一款在線協作編輯工具，它可以幫助企業創建企業內網、項目管理跟蹤、外延網、以及其它類型的定製網站。用戶可以通過Google Sites將所有類型的文件包括文檔、視頻、圖片、日曆等與好友、團隊或整個網路分享。

Google Caja服務會解析html/javascript文件，並會消除掉其中像iframe、object對像標記和document.cookie等敏感javascript內容，起到安全過濾作用。通常，Caja服務主要針對客戶端的HTML標記進行解析和安全過濾，但是，對於一些類似的遠程調用javascript標記來說，遠程資源的獲取、解析和過濾是在服務端進行的。

端倪發現

我曾試圖在我的自架伺服器上託管了一個javascript文件，像這樣https://[attacker].com/script.js，之後把它嵌入到一個遠程調用標記中，以此來測試 Google Sites 服務端的XSS漏洞，但可惜Google Sites 服務端的響應顯示，https://[attacker].com/script.js無法訪問。

經過幾多測試，我才意識到Google Sites中的Caja服務只會調用谷歌自身的資源文件，就像https://www.google.com 或 https://www.gstatic.com 網站託管的文件才行，但像https://www.facebook.com 這樣的外部資源就不行啦。

這就有點奇怪了，因為Caja服務遠程調用功能本來就是可以獲取到任何外部資源的啊，這種設置看起來就像一個被破壞的功能。更有意思的是，由於谷歌的服務網站非常之多，要確定某個外調URL鏈接是否屬於谷歌，還是有些難度的。除非……

發現Google的SSRF漏洞

每當我能通過服務端應用獲取到任意內容時，我都會順便測試一下SSRF漏洞。針對Google的應用服務，我做過好多SSRF測試，但沒有一次是成功的。對Google Caja服務端怪異行為的解釋，唯一的可能就是，Caja的鏈接提取動作發生在Google內部網路的，而且Google只能調用提取自身的資源文件消息，而其它的外部資源文件就不行。這從邏輯上來說，可以算是一個bug，現在的問題是，它是否算得上一個安全漏洞！

在Google伺服器上託管和運行任意代碼非常容易，例如使用Google雲服務啊！於是，我創建了一個Google App Engine應用實例，並在上面託管了一個javascript文件。然後，我將這個javascript文件的URL鏈接，作為外部資源引用鏈接在我的Google Sites頁面上作了配置。之後，Google Caja服務端成功獲取並解析了該javascript文件。據此，我查看了我的Google App Engine實例日誌，看看這個外部資源鏈接到底是誰來請求它的，啊哈，出現了一個IP地址：10.x.x.201，這明顯是一個內部網路IP地址啊！有點希望了！

那麼，我用包含這個Google內部網路的IP地址作為Google Sites頁面的javascript調用外鏈會產生什麼效果呢？試試吧，一起來靜待真相。但在請求之後快半分鐘了，還是沒啥反應，我都覺得是不是請求被攔截了，就快要把頁面關閉了。但是，當我查看 Google Caja 服務的響應時，卻發現其響應數據並不象通常的1KB左右的典型錯誤消息，而是有1MB容量的內容！這些1MB的響應消息是來自Google內部網路的某IP地址 10.x.x.x，此時，我是相當的興奮！打開這個1MB文件，我發現其中包含了很多Google內部網路系統的敏感信息！

利用SSRF漏洞獲取到的Google內部信息

首先，我想說的是，我並沒有對Google內部網路進行過探測掃描，我只是對其內網測試了3個請求就確定了該SSRF漏洞，並馬上上報給了谷歌的漏洞團隊VRP，48小時之後，Google團隊修復了該漏洞。在此之前，我也好奇心強烈地創建了其它2到3個請求，想看看能否基於該SSRF漏洞，深入利用發現其它的未限制文件訪問或RCE漏洞，但可惜最後都沒有。

我創建的第一個請求是發向 http://10.x.x.201/ 的，它響應了一個 「Borglet」 的伺服器狀態監控頁面。我對此進行了一些Google查詢，發現這是Google內部的大規模集群管理系統Borg。經歷多種架構演變，Google曾在2014年開源了 Borg的繼任系統Kubernetes，雖然Kubernetes越來越受歡迎，但谷歌內部的生產網路架構仍然嚴重依賴Borg系統。Borg單元由一組機器，一個稱為Borgmaster的邏輯中央控制器和單元中每台機器上運行的稱之為Borglet的代理進程構成。

我創建的第二個請求是發向 http://10.x.x.1/ 的，它響應了另一個 「Borglet」 伺服器狀態監控頁面，我創建的第三個請求則是 http://10.x.x.1/getstatus，它的響應主體也是一個 「Borglet」 伺服器狀態監控頁面，但其中包含了很多進程任務的許可權和參數等詳細信息。

每個Borglet代表一台伺服器，從硬體方面來說，10.x.x.1 和 10.x.x.201 這兩台伺服器都使用了英特爾第四代架構的Haswell 2.30GHz 72內核CPU，相當於一組2到3個Xeon E5 v3 CPU處理器。這兩台伺服器都使用了 77%的CPU，它們具備250 GB內存，使用量達 70%。它們的硬碟容量都是2TB硬碟，且每台硬碟容量幾乎都是空的，只有15個G的使用佔有空間。所以，重要數據可能存儲在其它地方。

伺服器中的處理進程非常多樣化，我想這種方式可能是一種資源優化手段吧，有些進程在使用著內存，其它的可能在用CPU、網路等，有一些則具備高優先權，等等…。還有一些服務看似非常活躍：如視頻編碼、Gmail和廣告等。這也並不奇怪，因為視頻處理非常繁重，Gmail是谷歌的主要服務之一，而廣告是谷歌的核心業務。

我沒有在伺服器任務列表信息中看到Google Sites 或 Caja服務，所以要成功形成SSRF漏洞，要麼是通過一個代理，或是 10.x.x.201 伺服器上的，有別於我在Google App Engine實例日誌中的，其它網路環境下的一個Borglet來形成的。

在架構方面，我們可以發現很多Google系統棧相關的元素，特別是 MapReduce, BitTable, Flume, GFS…等。在技術方面，Java使用頻率較高，我沒發現任何關於Python、c++、NodeJS或Go語言的提及，但這也並不意味著Google沒使用這些編程語言，不能定論。

我想說的是， Borg 和 Kubernetes 一樣都依賴Docker 和 VM虛擬機這樣的容器技術。另外，在視頻處理方面，Google使用的是其開源工具Gvisor，Gvisor貌似能在容器運行和虛擬機安全方面表面不錯。

從SSRF漏洞獲取的參數中，有著網路埠到應用程序映射信息。在Borg系統中，貌似每個伺服器上的所有應用程序都共享相同的IP地址，且每個應用程序都有一些專用的埠。

對我來說，全是代碼的應用程序參數是最有意思的部份。我雖然沒能發現神秘的Google搜索排名演算法原理，但是我發現了如下一些有趣的查詢：

你可能會想，Gmail的系統用戶是什麼呢？它是：

在我的測試中，大部份任務還沒完成就被無故終止執行了。最後，還存在大量指向其它Google伺服器和應用服務端的URL鏈接，特別是，當我嘗試去訪問一個很有可能的 http://wiki/ 鏈接時，竟然沒成功。於是乎，我在該服務上測試了以下鏈接：

/getFile?FileName=/sys/borglet/borglet.INFO

Google VRP 安全團隊的響應

我於2018年5月12日星期六上報了這個漏洞，它被Google自動分類為P3中等優先順序問題。在星期天，我又向Google 安全團隊發送了一封漏洞郵件，希望對方能有所響應。星期一一大早，該漏洞就被提升為P0（高危）級，之後又被降為 P1 級，星期一晚上，漏洞就得到了修復，相關漏洞服務端被刪除。

確定SSRF漏洞的影響危害非常不易，因為這要看內部網路的實際情況而定。Google傾向於讓其大部分基礎架構在內部可用，與此同時，使用了大量web應用端，這就意味著，如果發生SSRF漏洞，攻擊者可能會間接訪問到數百甚至數千個內部web應用程序。但另一方面，Google嚴重依賴認證來實現資源訪問，這種手段某種程度上也限制了SSRF漏洞的威脅。

但在Google的認證手段下，Borglet狀態監控頁面未經身份驗證，就泄露了很多關於內部網路的基礎設施信息。但據我了解，Kubernetes系統的這種狀態監控頁而是要經身份驗證的。

最終，Google安全團隊獎勵了我 $13,337美金，這相當於未授權文件訪問級別的高危漏洞了。Google對該獎勵的解釋是，雖然其大多數內部資源需要身份驗證，但他們發現很多內部開發項目或調試處理程序，可以被攻擊者利用的不僅是信息泄露問題，因此他們決定獎勵這種存在嚴重潛在影響的漏洞。感謝Google的慷慨賞金和快速反應。

*參考來源：opensec，clouds 編譯，轉載請註明來自 FreeBuf.COM

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