内容简介:This was a very big deal, a few important processes use the name found in the configuration of a service for performing any action, except for checking permissions, in that case they use the service name itself. So, with a different name in the configurati
Before getting to the bug itself, I need to explain a few concepts. You can jump directly to it if you want .
Key concepts
This service allows users to enable/disable services on their Google Cloud Platfomprojects, list available services (Such as Maps API, Gmail API, private APIs you have access to, etc.), and manage the settings of their own services through service configurations .
Developers will rarely have to use this service directly, mostly interacting with it through theGoogle Cloud Console orcommand line (For enabling/disabling services), or through Google Cloud Endpoints (For managing settings), but it also has a very interesting API.
These hidden capabilities can be found in several ways, but the simplest and easiest one is by enabling the Service Management API on a Google Cloud Platform project and opening the combo box used for filtering the traffic your project produces:
Both, hidden methods and hidden parameters, are use a feature of Google services called "Visibility" (Documented externally, though only used internally by Google).
Note: Hidden parts of a Google-owned API can be found using several ways, and most of the time they have hidden documentation as well, Google does not consider finding hidden API capabilities or hidden API documentation a security vulnerability (I already tried reporting those to them).
But, there are some hidden capabilities that, if used successfully, are considered a security vulnerability (Like the "usage.dependsOnServices" field inthis bug).
An usual request with this client looks like this:
Let's see what each part is:
- "clients6.google.com" is just another way of saying "googleapis.com", which is needed since the cookies can only reach google.com subdomains.
One of several capabilities this client has iscreating a service with a configuration attached since the beginning (Normal clients will just ignore the "serviceConfig" parameter, since it is hidden,and create a service with no initial configuration), a simple request like this:
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
}
The bug
Note: This bug did not work for a few old Google services due to a special setting they have for compatibility reasons.
This was a very big deal, a few important processes use the name found in the configuration of a service for performing any action, except for checking permissions, in that case they use the service name itself. So, with a different name in the configuration, an attacker could be permitted to perform important actions on a different service.
Among this actions were:
- Enabling the other service :
If I have my service "the-expanse.appspot.com" with "very-important-api.example.com" in its configuration, when enabling "the-expanse.appspot.com" for a project, Google will proceed because I have permission to enable "the-expanse.appspot.com", but the action will really be performed on "very-important-api.example.com", so I end up having enabled "very-important-api.example.com".
If a customer sets up an API to use Google API keys and/or Google Auth tokens to authenticate legitimate clients, this could be bypassed by an attacker.
Google itself uses this method for authenticating legitimate clients, so an attacker could be able to use private Google APIs that are in development, are meant to be used only internally, or that are accessible for a few white-listed users (Trusted Testers, Google My Business API , etc.).
- Getting access to hidden capabilities :
A hidden method in the Service Management API is "PatchProjectSettings", this allows a service owner to set some hidden settings of a specific service consumer (Project). Among this settings is the option for setting visibility labels (Which manage access to hidden capabilities).
For instance, if I have my service "the-expanse.appspot.com" with "cloudresourcemanager.googleapis.com" in its configuration, I can send the following request and get access to capabilities being tested by a select few (Trusted Testers) in the Cloud Resource Manager API on my project (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"
]
}
}
- Disabling the service on someone else's project :
Using the same method as before, we can set another setting that controls whether a project has enabled or not the service. Note that you cannot enable your service on a project you do not own, only disable it.
For instance, if I have my service "the-expanse.appspot.com" with "cloudresourcemanager.googleapis.com" in its configuration, I can send the following request and disable the Cloud Resource Manager API onCloud SDK (Which uses the project "google.com:cloudsdktool"):
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"
}
}
This bug could lead to lots of issues, enabling private APIs, getting access to hidden capabilities and disabling services for others could probably lead to several issues arising for lots of people very easily. I have not tested most of these scenarios and maybe they were never possible, but I am very confident they could be done:
- Accessing several Google APIs in development to use features not yet released to the general public
- Accessing billed Google APIs for free by enabling them using this bug (The billing constraint is enforced using the real service name)
- Accessing private APIs developed by Google users using Google Cloud Endpoints
- Accessing hidden features not yet released for the general public in public Google APIs
- Bypassing quota limits (They are stored in the project settings too)
- Exploiting bugs not available without the use of this one
- Disabling key APIs for some projects that lead to service outages (Such as the Cloud SDK not being able to access projects, Android's YouTube app not being able to retrieve videos' metadata, etc.).
Timeline (UTC-3)
- 2018-01-27 afternoon - Bug found
- 2018-01-27, 06:45 PM - Initial submission
- 2018-01-27, around 7:45 PM - Google Service Management API development team discovered the bug independently (Note it was a Saturday !)
- 2018-01-29 - Bug during creation fixed by the development team
- 2018-01-29, 12:53 PM - Bug report triaged
- 2018-01-30 - All services with mismatched serviceName/serviceConfig.name pairs were completely purged from Google's systems, thus this bug could no longer be exploited
- 2018-01-30, 06:46 PM - Security team cannot reproduce scenario #3, the security engineer keeps getting 401 errors
- 2018-01-30, 08:21 PM - It is confirmed that the development team discovered the "hack" and patched an emergency fix during the weekend
- 2018-01-31, 12:42 PM - I am told the development team independently discovered the bug an hour after my report, nevertheless my report is sent to the security panel to check if a reward can be issued
- 2018-02-14, 06:12 AM - A reward of 7500 dollars is issued
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Web2.0策划指南
艾美 / 2009-11 / 32.00元
《Web2.0策划指南(影印版)》是讲述战略的。书中的示例关注的是Web 20的效率,而不聚焦于技术。你将了解到这样一个事实:创建Web 20业务或将Web 20战略整合到业务中,意味着创建一个吸引人们前来访问的在线站点,让人们愿意到这里来共享他们的思想、见闻和行动。当人们通过Web走到一起时,可能得到总体远远大于各部分和的结果。随着传统的“口碑传诵”助推站点高速成长,客户本身就能够帮助建立站点。......一起来看看 《Web2.0策划指南》 这本书的介绍吧!