你聽說過谷歌的漏洞跟蹤管理平臺( Google Issue Tracker)嗎? 我想大多數人可能沒有,除非你是谷歌內部雇員或是最近上報過谷歌相關產品漏洞的開發者。我也不知道這個東西,直到最近我通過上報給谷歌的漏洞才發現,谷歌除了通常的郵件通知外,還采取了這個新的漏洞跟蹤反饋處理機制(如下圖所示),所以,我決定想辦法來搞搞它。
根據相關文檔介紹,該漏洞跟蹤反饋平臺在谷歌內部稱為Buganizer,是谷歌內部用于產品開發周期內對漏洞和需求問題進行跟蹤反饋的系統。為滿足多方和特定項目合作需求,它同樣提供了外部訪問接口。
也就是說,如果谷歌產品存在被人上報的漏洞問題,這些問題就會顯示在該平臺中,有點道理,對吧?作為外部用戶的我們,只能看到其中的冰山一角:顯示給我們的僅只是預先審核分類過的信息,或一些內部用戶添加外部賬戶的問題,包括白帽們上報的一些漏洞報告。而在這些表面信息之下又存在著多少不為人知的深層漏洞信息呢?我們來一探究竟。
看看漏洞和問題的最近排序ID,我們能估計出該平臺的大概處理工作量,峰值時最多第小時能接收2000至30000個問題報告,而谷歌選擇公開的,僅只是這些問題或漏洞的0.1%,如果該平臺存在信息泄露漏洞,那就好玩了,好吧,我們一起來看看!
第一個漏洞:通過更改Buganizer平臺關聯郵箱地址繞過谷歌身份認證
經研究發現,Buganizer平臺在對問題和漏洞的跟蹤處理過程中,會以以下特殊郵箱格式向漏洞上報人發送一些漏洞相關的交流信息:
其中,componentID代表分類,issueID代表特定的漏洞問題編號。
這讓我想起了最近有研究人員披露的helpdesk服務控制臺欺騙技巧,利用該技術可以結合以上郵箱模式對某些公司的內部聊天系統進行成功滲透。考慮到該郵箱地址是以@google.com結尾的,所以我用以上谷歌的一個郵箱地址為賬戶去嘗試登錄谷歌的Slack服務,雖然出現了一個登錄確認頁面,但卻沒有任何Slack的返回信息,有可能是谷歌內部團隊沒有開啟或利用Slack服務。
接下來我能想到的就是,想辦法獲取一個谷歌內部雇員郵箱@google.com了,這樣或許能對這樣或許能對Buganizer平臺的訪問提供特殊權限,這種內部雇員郵箱一般通過外網是注冊不了的,只有內部員工或外包商才能擁有。
于是我嘗試利用一種方法來繞過這種機制:在使用谷歌Buganizer平臺過程中,Buganizer平臺的Google賬戶關聯郵箱可以任意更改,所以我把其更改為了[email protected],之后,Buganizer平臺會向我之前舊的關聯郵箱發送來一封
關于當前Buganizer平臺Google賬戶關聯郵箱地址變更的確認郵件,其中包含了一個確認鏈接:
這一改,Buganizer平臺就已經默認我是谷歌內部員工了!點擊返回的確認鏈接之后,就直接轉到了谷歌的內部登錄系統了:
答案是肯定的,在此,這個新注冊郵箱[email protected]當然是不能成功登錄進入的。但已經能夠說明問題了:利用這種漏洞,我能對其它谷歌服務的安全性作出測試,或許能享受其車輛定位服務系統的免費搭車。這依然是一個存在安全隱患的漏洞。最終我上報了該漏洞,谷歌安全團隊在11個小時之后進行了采納修復,我也獲得了$3,133.7的賞金,該漏洞嚴重程度為危急。
第二個漏洞:獲取谷歌內部相關憑據的通知提示信息
Buganizer平臺的另外一個讓我覺得有意思的地方就是其星標條目,標記為星標的條目表示你個人對該漏洞問題比較關注,并希望接收Buganizer平臺上其他人對該漏洞的一些實時評論。
該功能比較有意思的是,當我用它標記一些不具備訪問權限的漏洞條目時,竟然缺少一些錯誤提示。這貌似說明Buganizer平臺未采用某些訪問控制規則,于是,我用我的另外一個賬戶登錄進入Buganizer平臺,并嘗試通過替換請求中的issueID來對上個主賬戶中的某個漏洞報告進行星標標記,于是,我看到了以下這條信息,表示標記行為成功:
1 person has starred this issue.
這樣就能側面監控一些谷歌漏洞的最新狀態了嗎?于是,我很快對該星標漏洞條目進行了評論,看看我的虛構賬戶是否能收到其狀態提示通知。但可惜,還是沒有任何郵件反饋。
由于某種原因,我決定對此問題繼續進行一些深入測試。所以,我選擇了一個近期的漏洞條目issueID,并推斷出了Buganizer平臺上最近數千個漏洞條目的ID范圍,然后把它們全部標記為星標條目。幾分鐘之后,我的收件箱出現了這些情況:
我想,這應該中獎了吧!但是,仔細查看后發現,這些提示郵件中并沒有太多有價值的信息,更多的是一些不同語言的評論和對話內容。
我希望后期對此漏洞進行一些深入研究,想辦法找出更嚴重的問題,所以,它一直在我手上耽擱了幾個小時。但之后,我想谷歌安全團隊應該會對該漏洞感興趣吧,于是,我就上報了該漏洞。最終,谷歌安全團隊以高優先級方式在5小時之后確認了該漏洞,我也因此獲得了$5000賞金。
第三個漏洞:Buganizer平臺存在無訪問權限驗證機制導致可以查看任意上報漏洞
當你作為外部用戶訪問Buganizer平臺(Issue Tracker)時,其實大部分功能是被剝離的,給你的權限非常有限, 而根據JavaScript文檔中API服務端點可以發現,谷歌內部員工可以進行很多酷炫操作。這些操作功能對外部用戶來說,很多都被完全禁用了,也有一些被簡單地隱藏在接口之中。
在設計這個對外部用戶有功能限制的系統時,開發者預留了郵件抄送列表的刪除功能,也就是說,如果我們對某個漏洞問題不感興趣而不需要對其狀態進行關注時,那么該漏洞的狀態信息將不會發送到我們的郵箱中。該抄送列表功能可以通過以下POST方式來實現:
POST /action/issues/bulk_edit HTTP/1.1
{
"issueIds":[
67111111,
67111112
],
"actions":[
{
"fieldName":"ccs",
"value":"[email protected]",
"actionType":"REMOVE"
}
]
}
但是,這種功能的實現卻導致了嚴重的問題:
不當的訪問控制規則:在嘗試執行給定操作之前,對當前用戶是否具備訪問issueID中特定漏洞的權限無任何明確檢查行為;
不報錯機制:如果你提供的郵箱地址不在當前漏洞問題狀態的郵件抄送列表中,客戶端就會返回一條消息稱該郵箱地址被成功刪除;
返回消息中包含了完整的漏洞信息:如果在操作期間沒有發生錯誤,系統的另一部分服務就會假設當前用戶具備適當的操作管理權限,因此,那些特定ID的漏洞細節信息都會出現在返回的HTTP響應內容中。
根據以上存在的三個問題,我現在可以通過在請求中替換掉issueid來查看Buganizer平臺數據庫中每個漏洞的詳細信息,超贊!
我只嘗試性地查看了幾個連續的漏洞ID,然后用一個無關帳戶進行了驗證,確認這個問題的嚴重性。是的,我可以看到漏洞報告的所有詳細信息,包括Buganizer平臺上托管的其他內容。更嚴重的是,我可以在單個請求中竊取到多個用戶憑據的相關數據內容,因此,這樣甚至可以無限制地實時監控Buganizer平臺的所有內部活動!
我把該漏洞及時上報給了谷歌安全團隊,他們在一小時之內緊急進行了修復,并禁用了相關存在漏洞的服務終端,好快的響應速度!我也因此獲得了 $7500的賞金。
后記
當我第一次挖掘Buganizer平臺的信息泄露漏洞時,我就認為這將會是“谷歌漏洞的圣杯”(Holy Grail of Google bugs),因為Buganizer平臺本身就是谷歌的漏洞跟蹤管理系統,其一旦存在漏洞,攻擊者就能訪問谷歌產品中那些尚未修復的漏洞信息,進一步深入利用這些漏洞,會對谷歌自身和全球用戶造成嚴重的安全影響。但幸運的是,谷歌安全團隊第一時間就修復了Buganizer平臺的漏洞,及時堵塞了漏洞,化解了風險。