Shulou(Shulou.com)05/31 Report--

Many novices are not very clear about the example analysis of finding loopholes in the Google cloud platform and getting a reward. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

The following is about a 17-year-old Uruguayan high school student who independently discovered vulnerabilities in Google's cloud platform and earned $7500 through study and research because he was interested in information sense of security (previously, he discovered a $10000 leak in Google's mainframe head). Before discussing the details of the vulnerability, I hope readers will have some understanding of Google's cloud services and API mechanism, and can familiarize themselves with a few related concepts.

Leading concept

Google runs a management service called Google Service Management, which manages the internal and external interfaces of Google's system and user-created cloud services. Under Google Service Management, users can individually enable and disable Maps API, Gmail API, private APIs and other personal interface services in their cloud platform projects, and can manage and control various services in real time through interface configuration files.

Generally speaking, as developers, we do not use Google Service Management services directly, most of the interactions are done through the cloud console Google Cloud Console or command line (such as enabling / shutting down services), or through the API management interface Google Cloud Endpoints, but it is worth mentioning that Google Service Management services have an interesting API interface.

The API interface not only implements the above service management functions, but also states in the Google official documentation that the API interface can be used to access some hidden functions of Google services.

These hidden features can be found in many ways, but one of the easiest and easiest is to enable Service Management's API interface and open a combo box for project traffic filtering in Google's cloud platform project Google Cloud Platform project. The steps are as follows:

In the last figure above, you can see a variety of functional methods implemented through API, including some hiding methods for red boxes. The so-called hiding method is that non-Google clients are not allowed to access it, and a 404 error is returned when a non-Google client tries to access it. Interestingly, this 404 error does not appear as the usual "error here" prompt on HTML pages, but is given in JSON, which indicates that the method does not exist.

Similarly, there are some hidden methods in API itself, which are hidden parameters received in some public methods, but these hides are relatively difficult to find.

For hidden methods and hidden parameters, they both use a Google service called "Visibility", whose records can be queried from public documents, but are used only internally by Google.

Tip: hidden parts of Google's own API can be found in a variety of ways, and most of the time they also have some hidden documentation, and Google does not consider the disclosure of this hidden API function or the existence of hidden API documents as a security vulnerability. (I once reported this to Google).

However, there are some hidden features that, if successfully exploited, will be considered a security loophole, such as a hidden parameter I discovered a year ago, which was successfully exploited to create a vulnerability, and Google rewarded me $5000. As the loophole is still in the repair period, it is not convenient to disclose for the time being.

Prophase analysis

With the above knowledge, I tried to use a way to access these hidden functions of Google, which is not difficult, but to carefully analyze the HTTP requests generated when visiting Google's cloud console Google Cloud Console.

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

Common requests from Google Cloud console (Google Cloud Console) clients are as follows:

GET / v1/services?key=AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g HTTP/1.1Host: servicemanagement.clients6.google.comAuthorization: SAPISIDHASH X-Origin: https://console.cloud.google.comCookie:

Let's take a look at part of the meaning of the name:

"clients6.google.com": is another representation of the request "googleapis.com", which is necessary because the cookie in it can only access the subdomain name of google.com.

"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", is the indispensable header information for the SAPISIDHASH section and the client to verify the trust of visiting the website.

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

In view of this, it is easy to fake a request for Google's cloud console (Google Cloud Console), and because it is Google's own client program, it can access multiple Google API, or even some internal functions of some private Google API, including Service Management's API.

One of the functions of the Google Cloud console (Google Cloud Console) client is to create a service with a configuration item attached from the beginning (the "serviceConfig" parameter is usually ignored by ordinary clients because it is hidden and no initial configuration operation is generated when the service is created). The simple configuration request is as follows:

POST / v1/services?key=AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g HTTP/1.1Host: servicemanagement.clients6.google.comAuthorization: SAPISIDHASH X-Origin: https://console.cloud.google.comCookie: Content-Length: {"serviceName": "," producerProjectId ":", "serviceConfig": {"name": "," producerProjectId ":", "configVersion": 3} vulnerability analysis

In general, the parameters "serviceName" and "serviceConfig.name" must match requests that specify both, but in the actual service creation process, when the value of the "configVersion" variable is set to 1 or 2, or a value between 2147483648 and 4294967295 (equivalent to an integer overflow at the back end), this matching constraint is not checked, so Any user can create a service with a real name, such as "the-expanse.appspot.com", as long as it is declared in its configuration file that there is a different service, such as "my-private-secure-api.appspot.com". Note: due to a special setting of compatibility, this vulnerability will not affect some older versions of Google services.

The emergence of this vulnerability will have a significant impact on Google services, and some important processes use the service name in the service configuration to perform any operation other than permission checking, so if different service names are added to the configuration, attackers can perform some important operations in different services. These actions include:

"enable other services

If I have the service "the-expanse.appspot.com" and its corresponding "very-important-api.example.com" in the configuration item, when I enable "the-expanse.appspot.com" to run a Google cloud project, the Google service will continue to run because I have permission to enable "the-expanse.appspot.com", but the final operation will be implemented in the execution of "very-important-api.example.com", so Eventually, "very-important-api.example.com" can be enabled.

If the user sets API with a Google API key or Google authentication token to authenticate legitimate customers, an attacker can bypass this authentication mechanism.

Because Google itself uses this method to authenticate legitimate clients, attackers can use some private Google API for development to obtain some internal information that is only accessible to whitelist users (trusted testers, Google My Business API, etc.).

"access the hidden feature

One hidden method in Service Management API is "PatchProjectSettings", which allows the owner of the service to configure certain hidden settings for specific service items, in which you can choose to configure visibility tags to manage access to hidden functions.

For example, if I have the service "the-expanse.appspot.com" and its configuration item "cloudresourcemanager.googleapis.com", I can send the following request to access the functionality in my cloud project (the-expanse) that is tested by a small number of trusted testers.

PATCH / v1/services/the-expanse.appspot.com/projectSettings/the-expanse?updateMask=visibilitySettings&key=AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g HTTP/1.1 {"visibilitySettings": {"visibilityLabels": ["TRUSTED_TESTER"]}} "shut down the service capabilities of other people's cloud projects

Using the same method above, we can control whether a service is enabled or disabled for a cloud project, but it is important to note that this method can only disable services in other projects and cannot perform service enablement operations.

For example, if I have the service "the-expanse.appspot.com" and the "cloudresourcemanager.googleapis.com" in the configuration item, I can send the following request to disable Google Cloud Resource Management API located in Cloud SDK:

PATCH / v1/services/the-expanse.appspot.com/projectSettings/google.com:cloudsdktool?updateMask=usageSettings&key=AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g HTTP/1.1 {"usageSettings": {"consumerEnableStatus": "DISABLED"}} vulnerability impact

This vulnerability can lead to many problems, such as enabling private API, accessing hidden features, and disabling services in other people's projects, which in turn leads to problems with customers' use of Google's cloud services. I have not verified them one by one, but I am sure that this vulnerability can achieve the following actions that have an impact on customer service:

Access to various Google API and built-in features that have not yet been exposed in the development phase

Free use of some paid Google API features

Access to private API that use Google's cloud services for development

Visit some API hidden features that Google itself is not open to the public.

Bypass some special restrictions

On the basis of this vulnerability, threaten and exploit other potential vulnerabilities.

Disruption of important services caused by disabling critical API (for example, Cloud SDK cannot access items, Android's YouTube application cannot retrieve video metadata, etc.)

Vulnerability reporting process

2018-01-27 vulnerabilities found

Preliminary report on 2018-01-27 loophole

2018-01-29 the Google development team fixed a loophole in the service creation process

2018-01-29 vulnerability report classification

2018-01-30 all services that do not match serviceName/serviceConfig.name are removed from Google's system, and the vulnerability can no longer be exploited

2018-01-30 the Google security team cannot reproduce the third threat, but its test engineers can still receive 401 errors.

On 2018-01-30, the Google security team discovered a suspected breach related to the vulnerability and urgently released a fix.

2018-01-31 Google informed me that its development team independently discovered the vulnerability an hour after my vulnerability report, but my vulnerability report was sent to the Google security team to evaluate the reward.

2018-02-14 Google gave me a $7500 bug reward.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.