發(fā)現(xiàn)Google云平臺漏洞并獲得賞金的示例分析

發(fā)現(xiàn)Google云平臺漏洞并獲得賞金的示例分析，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

下面講述了一名烏拉圭17歲高中生，因?qū)π畔踩信d趣，通過學習研究，獨立發(fā)現(xiàn)谷歌云平臺漏洞并獲得$7500美金（此前，他曾發(fā)現(xiàn)了價值$10000美金的谷歌主機頭泄露漏洞）。在談論該漏洞的具體細節(jié)之前，希望讀者對谷歌云服務和API機制相關能有所了解，可以先來熟悉幾個相關概念。

先導概念

谷歌運行有一個名為Google Service Management的管理服務，谷歌通過它來管理各種應用谷歌系統(tǒng)的內(nèi)外部接口和用戶自行創(chuàng)建的云端服務。在Google Service Management下，用戶可以在自己的云平臺項目中對使用到的Maps API、Gmail API、private APIs等個人接口服務進行個性化啟用關閉，并且能通過接口配置文件對各種服務進行實時管理控制。

通常來說，作為開發(fā)人員的我們一般不會直接使用Google Service Management服務，大多交互操作都是通過云端控制臺Google Cloud Console或命令行（如啟用/關閉服務），或通過API管理接口Google Cloud Endpoints來完成，但值得一提的是，Google Service Management服務的一個有意思的API接口。

該API接口不僅能實現(xiàn)上述服務管理功能，在谷歌官方說明文檔中還記載說，可以使用該API接口去訪問一些谷歌服務的隱藏功能。

這些隱藏功能可以用多種方式來發(fā)現(xiàn)，但最簡單最容易的一種就是，在用戶的谷歌云平臺項目Google Cloud Platform project中，啟用Service Management的API接口，并開啟用于項目流量過濾的組合框。步驟如下：

在以上最后一張圖中，可以看到各種通過API來實現(xiàn)的功能方法，其中就包含了一些紅框標注的隱藏方法。所謂隱藏方法就是，不允許非谷歌客戶端對其進行訪問，當非谷歌客戶端嘗試對其進行訪問時，就會返回404錯誤。非常有意思的是，這種404錯誤不是以HTML頁面一般那種‘這里出錯’的提示出現(xiàn)，而是以JSON方式被給出的，它會提示該方法不存在。

同樣，在API本身中也存在一些隱藏方法，它們是一些公開方法中接收的隱藏參數(shù)，但相對來說，這些隱藏更難發(fā)現(xiàn)。

對隱藏方法和隱藏參數(shù)來說，它們都使用了一種叫做“Visibility”的谷歌服務功能，該功能記錄可從公開文檔中查詢，但只作為谷歌內(nèi)部使用。

提示：谷歌自身API的隱藏部分可以通過多種方式來發(fā)現(xiàn)，大多數(shù)時候它們也有一些隱藏的文檔記錄，而且，谷歌不認為這種隱藏的API功能泄露，或隱藏的API記錄文檔存在是一種安全漏洞。（我曾經(jīng)報告過這些給谷歌）。

但是，也有一些隱藏功能，如果可成功利用，就會被認為是一種安全漏洞，比如我在一年前發(fā)現(xiàn)的某隱藏參數(shù)，成功利用后形成漏洞，谷歌獎勵了我$5000美金。由于目前該漏洞還處于修復期，現(xiàn)暫不方便透露。

前期分析

了解了上述知識后，我嘗試用一種方法去訪問這些谷歌的隱藏功能，說來也不難，只是在訪問谷歌云端控制臺Google Cloud Console時，去仔細分析其中產(chǎn)生的HTTP請求。

谷歌云端控制臺（Google Cloud Console）使用多個公開和私有的Google API，和自己的客戶端程序，以及API密鑰AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g，來實現(xiàn)云端項目的信息訪問。

谷歌云端控制臺（Google Cloud Console）客戶端的常見請求如下所示：

GET /v1/services?key=AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g HTTP/1.1
Host: servicemanagement.clients6.google.com
Authorization: SAPISIDHASH <SAPISIDHASH>
X-Origin: https://console.cloud.google.com
Cookie: <GOOGLE COOKIES>

我們來看看其中的名部分含義：

"clients6.google.com"：是請求"googleapis.com"的另外一種表示方法，由于其中的cookie只能訪問到google.com的子域名，所以這種方式是必須的；

"SAPISIDHASH" ：據(jù)StackOverflow論壇解釋，是"TIMESTAMP_HASH"（時間戳_哈希）的值，論壇中其它多種生成SAPISIDHASH的方式，與本漏洞無關；

"X-Origin"：也稱 "Origin", 是這里SAPISIDHASH部分和客戶端對訪問網(wǎng)站進行受信驗證不可缺少的頭信息；

Cookie：包括SID、HSID、SSID、APISID和SAPISID等，谷歌用戶需要登錄才能獲取到這些Cookie信息。

由此看來，要偽造谷歌云端控制臺（Google Cloud Console）的請求非常簡單，而且由于它是谷歌自身的客戶端程序，因此它可以訪問到多個Google API，甚至是一些私有Google API的某些內(nèi)部功能，其中就包括Service Management的API。

谷歌云端控制臺（Google Cloud Console）客戶端的多個功能之一就是，創(chuàng)建一個從一開始就附加了配置項的服務（一般的客戶端通常會忽略 "serviceConfig"參數(shù)，因為該參數(shù)是隱藏的，而且在創(chuàng)建服務時不產(chǎn)生初始配置操作），其簡單的配置請求如下：

POST /v1/services?key=AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g HTTP/1.1
Host: servicemanagement.clients6.google.com
Authorization: SAPISIDHASH <SAPISIDHASH>
X-Origin: https://console.cloud.google.com
Cookie: <GOOGLE COOKIES>
Content-Length: <CONTENT-LENGTH>
{
  "serviceName": "<SERVICE NAME>",
  "producerProjectId": "<PROJECT>",
  "serviceConfig": {
    "name": "<SERVICE NAME>",
    "producerProjectId": "<PROJECT>",
    "configVersion": 3
}

漏洞分析

通常來說，參數(shù)"serviceName"和"serviceConfig.name"必須與指定了兩者的請求發(fā)生匹配，但在實際的服務創(chuàng)建過程中，當 "configVersion" 變量值被設置為1或2，或者是2147483648至4294967295之間的值時（相當于后端發(fā)生了一個整型溢出），這種匹配的受限條件并不會被檢查實行，因此，任意用戶都可以使用真實的名稱（如“the-expanse.appspot.com”）來創(chuàng)建服務，只需在其配置文件中聲明它其中還存在另一個不同的服務，如"my-private-secure-api.appspot.com"。Note：出于兼容性的某個特殊設置，該漏洞不會對一些舊版本的谷歌服務造成影響。

該漏洞的出現(xiàn)會對谷歌服務產(chǎn)生重要影響，一些重要的流程使用服務配置中的服務名稱來執(zhí)行除權限檢查之外的任意操作，所以，如果配置中加入了不同的服務名稱后，攻擊者就可以在不同的服務中執(zhí)行一些重要的操作。這些操作包括：

1#啟用其它服務

如果我擁有服務"the-expanse.appspot.com" ，和其在配置項中對應的"very-important-api.example.com" ，當啟用 "the-expanse.appspot.com"運行某項谷歌的云端項目時，谷歌服務會繼續(xù)運行，因為我擁有啟用"the-expanse.appspot.com" 的權限，但是，最終操作會實現(xiàn)在"very-important-api.example.com"的執(zhí)行上，因此，最終可以啟用"very-important-api.example.com"。

如果用戶設置了具備Google API 密鑰或Google認證令牌的API，來對合法客戶進行認證，那么，攻擊者可以繞過這種身份驗證機制。

由于谷歌本身使用了這種方法來認證合法客戶端，因此，攻擊者可以使用一些用于開發(fā)的私有Google API，獲取到一些僅供白名單用戶（可信測試人員、Google My Business API等）才能訪問的內(nèi)部信息。

2#訪問隱藏功能

Service Management API中的一個隱藏方法是“PatchProjectSettings”，這允許服務的所有者配置針對特定服務項目的某些隱藏設置，在這些設置中，可以選擇配置可見性標簽來對隱藏功能的訪問進行管理。

例如，如果我有服務“the-expanse.appspot.com”，和其配置項中的“cloudresourcemanager.googleapis.com”，我可以發(fā)送以下請求訪問我的云端項目(the-expanse)中，由少數(shù)可信測試人員測試的功能。

PATCH /v1/services/the-expanse.appspot.com/projectSettings/the-expanse?updateMask=visibilitySettings&key=AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g HTTP/1.1
<..SAME HEADERS AS BEFORE...>
{
  "visibilitySettings": {
    "visibilityLabels": [
      "TRUSTED_TESTER"
    ]
  }}

3#關閉他人云端項目的服務功能

利用上述同樣的方法，我們可以對某云端項目是否啟用或關閉某項服務進行控制，但是，要注意的是，這種方法只能禁用其他人項目中的服務，不能執(zhí)行服務啟用操作。

比如，如果我有服務"the-expanse.appspot.com" ，以及配置項中的"cloudresourcemanager.googleapis.com" ，我可以發(fā)送以下請求去禁用位于Cloud SDK中的谷歌云端資源管理API：

PATCH /v1/services/the-expanse.appspot.com/projectSettings/google.com:cloudsdktool?updateMask=usageSettings&key=AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g HTTP/1.1
<..SAME HEADERS AS BEFORE...>
{
  "usageSettings": {
    "consumerEnableStatus": "DISABLED"
  }
}

漏洞影響

該漏洞可導致很多問題，如啟用私有API、訪問隱藏功能、禁用其他人項目中的服務，進而導致客戶對谷歌云端服務的使用問題。我沒一一進行過驗證，但我可以肯定的是，該漏洞可以實現(xiàn)以下操作，對客戶服務造成影響：

訪問各種處于開發(fā)階段尚未公開的Google API和其中的內(nèi)置功能；

免費使用一些收費的Google API功能；

訪問那些使用谷歌云端服務來進行開發(fā)的私有API；

訪問一些谷歌自身未向公眾開放的API隱藏功能；

繞過一些特殊限制條件；

在該漏洞基礎上，對其它潛在漏洞形成威脅利用；

對關鍵API的禁用導致的重要服務中斷（如Cloud SDK無法訪問項目，Android的YouTube應用無法檢索視頻的元數(shù)據(jù)等等）

漏洞上報進程

2018-01-27   發(fā)現(xiàn)漏洞

2018-01-27   漏洞初報

2018-01-29   谷歌開發(fā)團隊修復了服務創(chuàng)建過程的漏洞

2018-01-29   漏洞報告分類

2018-01-30  與serviceName/serviceConfig.name不匹配的所有服務都被從谷歌系統(tǒng)中清除，該漏洞也不能再被利用

2018-01-30   谷歌安全團隊不能復現(xiàn)第3#種威脅，但其測試工程師還能收到401 錯誤

2018-01-30   谷歌安全團隊發(fā)現(xiàn)了疑似與該漏洞相關的入侵事件，并緊急發(fā)布了修復補丁

2018-01-31   谷歌方面告知我其開發(fā)團隊在我的漏洞報告之后一小時，也獨立發(fā)現(xiàn)了該漏洞, 但我的漏洞報告還是被發(fā)往谷歌安全團隊以評估賞金

2018-02-14   谷歌方面向我發(fā)放了$7500的漏洞賞金

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業(yè)資訊頻道，感謝您對億速云的支持。