我是怎么通過生產網SSRF漏洞進入谷歌Borg的
責編：gltian ｜2018-07-31 11:17:08簡介 – 測試谷歌網站和谷歌Caja
Caja是Google的一個能對html和javascript做XSS過濾的工具，2018年3月筆者發現并向谷歌提交了一個Caja的XSS漏洞。到5月份的時候，這個XSS問題已經被修復，不過我發現谷歌某站點用的是沒有打補丁的Caja，所以馬上看了下能不能XSS，然而并沒有成功。
Caja在解析html和JavaScript文件時會過濾掉敏感的js內容，比如iframe標簽、object標簽以及像document.cookie這種的敏感的js屬性。正常情況是在客戶端操作和過濾這些html標簽，但如果涉及到遠程js標簽(比如<script src=”xxx”>這種)，那這些遠程資源會在服務端進行獲取、解析和過濾。
我在自己的服務器上上傳了一個js文件https://[attacker].com/script.js，用來檢查谷歌某網站在服務端解析js時有沒有XSS漏洞，可惜服務器響應是訪問不到這個遠程js。
測了半天，結論是Caja只能獲取到https://www.google.com和https://www.gstatic.com這些來自谷歌官方的遠程資源，而像https://www.facebook.com這種第三方的是訪問不了的。
谷歌的這個邏輯不太合乎常理，這么做風險會比較大，因為谷歌的業務線很廣泛，一般來說一個URL不太好判斷是不是谷歌官方的，會比較容易誤判。不過也許在某種情況下，能輕而易舉地讓谷歌認為是一個來自官方的資源……
那就是在谷歌發現的SSRF漏洞
一般當我發現谷歌的后端內容服務器的話，我都會先測一下SSRF問題，不幸的是我測試了百來次都沒有成功找到漏洞。不管怎么說我確定了Caja是在谷歌的內網中做的抓取，否則不會只加載內部資源，而不能獲取第三方資源，這應該是個bug，但是不是安全漏洞還得進行進一步的確認。
因為谷歌云服務的存在，在谷歌自家服務器上托管和運行代碼就是一件順理成章的事情了，我創建了一個云App服務實例，上傳了之前放在第三方的js文件，然后在谷歌某站點上引用這個遠程js，神奇地發現谷歌Caja獲取并且解析了這個js！之后我查看了云App上的記錄的遠程IP，居然是10.x.x.201這樣的一個內網地址，看起來勝利就在眼前了。
我用這個內網IP替換了本來谷歌某站點訪問外部js資源的URL，等著服務器響應，花了30秒還沒加載出來，又想到谷歌的SSRF可不是那么好挖的，在我要放棄的最后一刻，居然加載出來了，而且不是普通的錯誤響應碼，響應內容大概有1M那么大……難怪加載這么久，打開確認了下全都是內網的數據，我驚呆了！
從谷歌內部來看
我并沒有掃描谷歌的內網，只是發了以下幾個請求證明漏洞存在，并立即向谷歌漏洞賞金計劃報告了該漏洞，我是在周六提交的，谷歌響應迅速，在48小時內就修復了，期間我還嘗試了能不能引起RCE漏洞，然而并沒有成功。下圖是Borg的架構圖：
第一個請求是發給http://10.x.201/這個地址的，服務器返回的是Borg的管理頁面(文章開頭的圖)，Borg是谷歌內部的大規模集群管理系統，經過搜索查證后，我確認直接訪問到了內部Borg系統。雖然谷歌在2014年開源了Borg的下一代產品Kubernetes，開源的Kubernetes日益流行，但是在內部生產環境仍然是依賴Borg的，當然這并不是因為Borg的界面設計(開個玩笑）。
第二個請求是發給 http://10.x.x.1/這個地址的，響應是另外一個Borg的管理頁面，第三個請求是發到http://10.x.x.1/getstatus，響應的Borg管理頁面比前兩個有更多的細節，有詳細的權限和參數信息。這兩個Borglet都是一個實體的后端服務器。
硬件方面，這兩臺服務器都用了Haswell的CPU，主頻2.3G赫茲，72核，相當于一組兩臺或者三臺的Xeon E5 v3的CPU，兩臺服務器的CPU利用率都在77%，有250G的內存，已經使用了70%，硬盤的容量是2T，基本沒有使用，大概只用掉了15G的空間，沒有固態硬盤，所以數據應該不是存在這兩臺服務器上的。
機器上的任務非常多，是整合優化過的，有一些任務用消耗的是內存，有的消耗CPU或者網絡資源，還有一些任務是高優先級的，有一些視頻編碼、郵箱和廣告的服務比較頻繁，這些看起來都是正常的，視頻處理起來本來就比較耗資源，Gmail是谷歌的主要服務，廣告也是谷歌的核心業務。
我沒有找到谷歌站點或者Caja的任務，要不就是走了代理，要不就是Borg的10.x.x.201和我在谷歌云App上收集到的IP是不同的內網。
參考谷歌的架構，我基本上找到了和谷歌Stack的幾乎所有的組件相關的任務，特別是 MapReduce, BitTable, Flume, GFS…等等這些。
技術方面，大部分用的語言都是java，沒有發現部署過Python、C++、NodeJs或者Go語言，當然結論也不能下的太早了，說不定是我沒有發現呢。
Borg和Kubernetes一樣，都是依賴Docker和VM這樣的容器，但視頻處理好像使用的是谷歌的開源工具Gvisor，大概是為了在容器的性能和VM安全之間做的一個平衡吧。
不同參數會展示如何到達端口的應用信息的，在Borg系統里，好像所有的應用都是用的同一個IP地址，用不同的服務端口區分。
應用中的對象是最有意思的，因為這些基本就是源代碼了，我發現了一些谷歌沒有公開的有趣小算法：
MSCR(M(Customer.AdGroupCriterion+Customer.AdGroupCriterion-marshal+FilterDurianAdGroupCriterion+FilterNeedReviewAdGroupCriterion+GroupAdGroupCriterionByAdGroupKey+JoinAdGroupData/MakeUnionTable:3)+M(JoinAdGroupData/MakeUnionTable:2)+M(Customer.AdGroup+Customer.AdGroup-marshal+FilterDurianAdGroup+ParDo(AdGroupDataStripFieldsFn)+JoinAdGroupData/MakeUnionTable)+R(JoinAdGroupData/GroupUnionTables+JoinAdGroupData/ConstructJoinResults+JoinAdGroupData/ExtractTuples+ExtractCreativeAndKeywordReviewables))
還有Gmail的系統管理用戶是gmail@prod.google.com
gmail@prod.google.com
還有一個用戶“legal-discovery@prod.google.com”在數據庫記錄mdb:all-person-users 中有“auth.impersonation.impersonateNormalUser”的權限(澄清一下，只是在一個大數組中看到的信息，按照字面意思理解，不一定準確)。
也有一些歷史信息證明有很多的項目在實現之前就被中斷了。
/getFile?FileName=/sys/borglet/borglet.INFO
大量的URL是去訪問其他的服務器或者終端，我覺得比較有戲的一個http://wiki/地址也訪問不到，詳細的路徑是
/getFileFileName=/sys/borglet/borglet.INFO
谷歌漏洞賞金計劃的響應
我是在2018年5月12日(周六)提交的漏洞，系統自動判定為P3，大概是個中危的等級，周天我又給谷歌安全團隊發了一封郵件，希望有人能跟進下，周一上午風險等級被修改成了P0，也就是嚴重級別，再后來改為P1高危，周一晚上漏洞修復，有風險的后端就下線了。
要確定SSRF的影響范圍不太容易，要看在內網里能訪問到多少信息，谷歌一般是在內部使用大量的web站點來維持基礎架構，也就是說，一旦發生SSRF，就意味著可以訪問到大量的內部web應用，不過好在很多系統都做了鑒權和身份認證，降低了SSRF的危害。
我提的這個漏洞里，正好Borglet系統的管理頁面沒有做身份認證，所以泄漏了大量的基礎信息，或許在繼任產品Kubernetes中是做了授權的，所以沒有泄漏。
谷歌VRP獎勵我$13337，相當于任意文件訪問的等級，對方解釋說雖然大部分資源都需要權限校驗，但很多開發人員在調試程序時都有很大的權限，可能造成的問題不僅僅是信息泄漏，因此按照最高的風險等級來獎勵。也感謝谷歌的獎金、負責任的態度和迅速的響應，當然也希望谷歌不會因為我這篇文章追責(開個玩笑，文中所有敏感信息都處理掉了)。
這就是我發現谷歌SSRF的全過程，希望大家能有所收獲，歡迎大家踴躍交流。