Example analysis of discovering Google Cloud Platform vulnerabilities and receiving bounty

The following is about a 17-year-old high school student in Uruguay. Because he was interested in information security, through study and research, he independently discovered a vulnerability in the Google Cloud Platform and received $7,500. (Previously, he had discovered a Google Cloud Platform vulnerability worth $10,000. Host header leak vulnerability). Before explaining the details about this vulnerability, we recommend that readers familiarize themselves with the concepts of Google Cloud services and API mechanisms.

Pioneer Concept

Google runs a management service called Google Service Management, through which Google manages the internal and external interfaces of various applications Google systems and clouds created by users. Serve. Under Google Service Management, users can individually enable and disable personal interface services such as Maps API, Gmail API, private APIs, etc. in their cloud platform projects, and can manage various services in real time through interface configuration files. control.

Generally speaking, as developers, we generally do not use Google Service Management services directly. Most of the interactive operations are through the cloud console Google Cloud Console or the command line (such as enabling/closing services), or through The API management interface is Google Cloud Endpoints, but it is worth mentioning that there is an interesting API interface of the Google Service Management service.

This API interface can not only realize the above service management functions, but also records in Google’s official documentation that you can use this API interface to access some hidden functions of Google services.

These hidden functions can be discovered in many ways, but the simplest and easiest one is to enable the API interface of Service Management in the user's Google Cloud Platform project and enable the use of Combo box for project traffic filtering. The steps are as follows:

##In the last picture above, various APIs are included Methods to implement functions, including some hidden methods marked with red boxes. The so-called hidden method is that non-Google clients are not allowed to access it. When non-Google clients try to access it, a 404 error will be returned. What is very interesting is that this 404 error does not appear as an "error here" prompt like the usual HTML page, but is given in JSON mode, which will prompt that the method does not exist.

Similarly, there are also some hidden methods in the API itself, which are hidden parameters received in some public methods, but relatively speaking, these hidden methods are more difficult to discover.

For hidden methods and hidden parameters, they all use a Google service feature called "Visibility". This feature record can be queried from public documents, but is only used internally by Google.

Tip: Hidden parts of Google's own APIs can be discovered in a variety of ways. Most of the time they also have some hidden documentation. Moreover, Google does not consider such hidden API functionality The existence of leaked, or hidden API documentation is a security vulnerability. (I once reported these to Google).

However, there are also some hidden functions. If they can be successfully exploited, they will be considered a security vulnerability. For example, a hidden parameter I discovered a year ago formed a Bug, Google rewarded me $5,000. Since the vulnerability is still in the repair period, it is not convenient to disclose it at the moment.

Preliminary analysis

After understanding the above knowledge, I tried to use a method to access these hidden functions of Google. It is not difficult to say, just access the Google Cloud Console. When doing so, carefully analyze the HTTP requests generated.

Google Cloud Console uses multiple public and private Google APIs, its own client program, and API key AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g to achieve information access to cloud projects.

Common requests from the Google Cloud Console client are as follows:

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>

Let’s take a look at the meaning of the first part:

" clients6.google.com": is another representation method of requesting "googleapis.com". Since the cookie can only access the subdomain name of google.com, this method is necessary;

"SAPISIDHASH": According to the StackOverflow forum, it is the value of "TIMESTAMP_HASH" (timestamp_hash). There are many other ways to generate SAPISIDHASH in the forum, which have nothing to do with this vulnerability;

"X-Origin": Also known as "Origin", it is the header information indispensable for the SAPISIDHASH part and the client to authenticate access to the website;

Cookie: including SID, HSID, SSID, APISID and SAPISID, etc. Google users need to log in to Obtain these cookie information.

由此看来，要伪造谷歌云端控制台（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 All services that do not match serviceName/serviceConfig.name have been purged from Google systems, and the vulnerability can no longer be exploited

2018-01-30 The Google security team cannot repair The third threat was discovered, but its test engineers could still receive 401 errors

2018-01-30 The Google security team discovered an intrusion suspected to be related to this vulnerability and urgently released a repair patch

2018-01-31 Google informed me that its development team independently discovered the vulnerability one hour after my vulnerability report, but my vulnerability report was still sent to the Google security team for bounty evaluation

2018-02-14 Google issued me a $7500 bug bounty

The above is the detailed content of Example analysis of discovering Google Cloud Platform vulnerabilities and receiving bounty. For more information, please follow other related articles on the PHP Chinese website!