發現Google云平臺漏洞并獲得賞金的示例分析

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

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

先導概念

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

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

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

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

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

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

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

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

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

前期分析

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

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

谷歌云端控制臺（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" ：據StackOverflow論壇解釋，是"TIMESTAMP_HASH"（時間戳_哈希）的值，論壇中其它多種生成SAPISIDHASH的方式，與本漏洞無關；

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

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

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

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

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
}

漏洞分析

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

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

1#啟用其它服務

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

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

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

2#訪問隱藏功能

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

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

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#關閉他人云端項目的服務功能

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

比如，如果我有服務"the-expanse.appspot.com" ，以及配置項中的"cloudresourcemanager.googleapis.com" ，我可以發送以下請求去禁用位于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、訪問隱藏功能、禁用其他人項目中的服務，進而導致客戶對谷歌云端服務的使用問題。我沒一一進行過驗證，但我可以肯定的是，該漏洞可以實現以下操作，對客戶服務造成影響：

訪問各種處于開發階段尚未公開的Google API和其中的內置功能；

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

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

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

繞過一些特殊限制條件；

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

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

漏洞上報進程

2018-01-27   發現漏洞

2018-01-27   漏洞初報

2018-01-29   谷歌開發團隊修復了服務創建過程的漏洞

2018-01-29   漏洞報告分類

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

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

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

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

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

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