發現Google雲端平台漏洞並獲得賞金的範例分析

下面講述了一名烏拉圭17歲高中生，因對資訊安全感興趣，透過學習研究，獨立發現谷歌雲端平台漏洞並獲得$7500美金（此前，他曾發現了價值$10000美金的谷歌主機頭外洩漏洞）。在說明有關該漏洞的詳細情況之前，我們建議讀者先熟悉谷歌雲端服務和API機制的相關概念。

先導概念

Google運行有一個名為Google Service Management的管理服務，Google透過它來管理各種應用谷歌系統的內部和外部介面和用戶自行創建的雲端服務。在Google Service Management下，使用者可以在自己的雲端平台專案中對使用到的Maps API、Gmail API、private APIs等個人介面服務進行個人化啟用關閉，並且能透過介面設定檔對各種服務進行即時管理控制。

通常來說，身為開發人員的我們一般不會直接使用Google Service Management服務，大多互動操作都是透過雲端控制台Google Cloud Console或命令列（如啟用/關閉服務），或透過API管理介面Google Cloud Endpoints來完成，但值得一提的是，Google Service Management服務的一個有趣的API介面。

此API介面不僅能實現上述服務管理功能，在Google官方說明文件中也記載說，可以使用該API介面去存取一些Google服務的隱藏功能。

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

#在上述最後一張圖片中，包含了各種使用API實現功能的方法，其中包括一些被紅框標註的隱藏方法。所謂隱藏方法就是，不允許非谷歌客戶端對其進行訪問，當非谷歌客戶端嘗試對其進行訪問時，就會返回404錯誤。非常有趣的是，這種404錯誤不是以HTML頁面一般那種『這裡出錯』的提示出現，而是以JSON方式被給出的，它會提示該方法不存在。

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

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

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

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

前期分析

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

Google雲端控制台（Google Cloud Console）使用多個公開和私有的Google API，和自己的客戶端程序，以及API金鑰AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g，來實現雲端專案的資訊存取。

Google雲端控制台（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></google></sapisidhash>

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

" 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>
Content-Length: <content-length>
{
  "serviceName": "<service>",
  "producerProjectId": "<project>",
  "serviceConfig": {
    "name": "<service>",
    "producerProjectId": "<project>",
    "configVersion": 3
}</project></service></project></service></content-length></google></sapisidhash>

漏洞分析

通常来说，参数"serviceName"和"serviceConfig.name"必须与指定了两者的请求发生匹配，但在实际的服务创建过程中，当 "configVersion" 变量值被设置为1或2，或者是2147483648至4294967295之间的值时（相当于后端发生了一个整型溢出），这种匹配的受限条件并不会被检查实行，因此，任意用户都可以使用真实的名称（如“the-expanse.appspot.com”）来创建服务，只需在其配置文件中声明它其中还存在另一个不同的服务，如"my-private-secure-api.appspot.com"。Due to a certain compatibility setting, this vulnerability will not affect some older versions of Google services.。

该漏洞的出现会对谷歌服务产生重要影响，一些重要的流程使用服务配置中的服务名称来执行除权限检查之外的任意操作，所以，如果配置中加入了不同的服务名称后，攻击者就可以在不同的服务中执行一些重要的操作。这些操作包括：

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>
{
  "visibilitySettings": {
    "visibilityLabels": [
      "TRUSTED_TESTER"
    ]
  }}</..same>

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>
{
  "usageSettings": {
    "consumerEnableStatus": "DISABLED"
  }
}</..same>

漏洞影响

该漏洞可导致很多问题，如启用私有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不匹配的所有服務都被從Google系統中清除，該漏洞也不能再被利用

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

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

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

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

#

以上是發現Google雲端平台漏洞並獲得賞金的範例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！