Im Folgenden geht es um einen 17-jährigen Gymnasiasten in Uruguay, der sich für Informationssicherheit interessierte. Durch Studium und Forschung entdeckte er unabhängig eine Sicherheitslücke in der Google Cloud Platform und erhielt 7.500 US-Dollar (zuvor hatte er eine Sicherheitslücke bei Google entdeckt). Sicherheitslücke im Host-Header im Wert von 10.000 US-Dollar). Bevor wir die Details dieser Sicherheitslücke erläutern, empfehlen wir den Lesern, sich mit den Konzepten der Google Cloud-Dienste und API-Mechanismen vertraut zu machen.
Google betreibt einen Verwaltungsdienst namens Google Service Management, über den Google die internen und externen Schnittstellen verschiedener von Benutzern erstellter Anwendungs-Google-Systeme und Cloud-Dienste verwaltet. Unter Google Service Management können Benutzer persönliche Schnittstellendienste wie Maps API, Gmail API, private APIs usw. in ihren Cloud-Plattformprojekten individuell aktivieren und deaktivieren und verschiedene Dienste in Echtzeit über Schnittstellenkonfigurationsdateien verwalten.
Im Allgemeinen nutzen wir als Entwickler die Google Service Management-Dienste nicht direkt über die Google Cloud Console oder die Befehlszeile (z. B. das Aktivieren/Schließen von Diensten) oder über die API-Verwaltungsschnittstelle Um dies zu vervollständigen, können Google Cloud Endpoints verwendet werden. Erwähnenswert ist jedoch, dass es eine interessante API-Schnittstelle des Google Service Management-Dienstes gibt.
Diese API-Schnittstelle kann nicht nur die oben genannten Dienstverwaltungsfunktionen realisieren, es ist auch in der offiziellen Dokumentation von Google vermerkt, dass Sie diese API-Schnittstelle verwenden können, um auf einige versteckte Funktionen von Google-Diensten zuzugreifen.
Diese versteckten Funktionen können auf viele Arten entdeckt werden, aber die einfachste und einfachste Möglichkeit besteht darin, die Service Management API-Schnittstelle im Google Cloud Platform-Projekt des Benutzers zu aktivieren und das Kombinationsfeld für die Filterung des Projektdatenverkehrs zu aktivieren. Die Schritte sind wie folgt:
Im letzten Bild oben gibt es verschiedene Methoden zur Verwendung der API zum Implementieren von Funktionen, einschließlich einiger versteckter Methoden, die durch rote Kästchen markiert sind. Die sogenannte versteckte Methode besteht darin, dass Nicht-Google-Clients nicht darauf zugreifen dürfen. Wenn Nicht-Google-Clients versuchen, darauf zuzugreifen, wird ein 404-Fehler zurückgegeben. Sehr interessant ist, dass dieser 404-Fehler nicht wie die übliche HTML-Seite als „Fehler hier“-Eingabeaufforderung erscheint, sondern im JSON-Modus angegeben wird, was darauf hinweist, dass die Methode nicht existiert.
In ähnlicher Weise gibt es auch einige versteckte Methoden in der API selbst, bei denen es sich um versteckte Parameter handelt, die in einigen öffentlichen Methoden empfangen werden. Relativ gesehen sind diese versteckten Methoden jedoch schwieriger zu entdecken.
Für versteckte Methoden und versteckte Parameter verwenden sie alle eine Google-Dienstfunktion namens „Sichtbarkeit“. Dieser Funktionsdatensatz kann aus öffentlichen Dokumenten abgefragt werden, wird jedoch nur intern von Google verwendet.
Tipps: Versteckte Teile von Googles eigenen APIs können auf verschiedene Weise entdeckt werden, und in den meisten Fällen gibt es auch eine versteckte Dokumentation. Darüber hinaus betrachtet Google solche versteckten API-Funktionen nicht als durchgesickert oder als versteckte API Dokumentation Exist ist eine Sicherheitslücke. (Ich habe diese einmal an Google gemeldet).
Es gibt jedoch auch einige versteckte Funktionen, die als Sicherheitslücke angesehen werden können. Ein versteckter Parameter, den ich vor einem Jahr entdeckt habe, hat mich belohnt mit 5.000 $. Da sich die Schwachstelle noch in der Reparaturphase befindet, ist es derzeit nicht sinnvoll, sie offenzulegen.
Nachdem ich das oben genannte Wissen verstanden hatte, habe ich versucht, mit einer Methode auf diese versteckten Funktionen von Google zuzugreifen. Es ist nicht schwer zu sagen, aber beim Zugriff auf die Google Cloud Console habe ich die generierte HTTP-Anfrage sorgfältig analysiert.
Google Cloud Console nutzt mehrere öffentliche und private Google APIs, ein eigenes Client-Programm und den API-Schlüssel AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g, um den Informationszugriff auf Cloud-Projekte zu erreichen.
Häufige Anfragen von Google Cloud Console-Clients sind wie folgt:
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>
Werfen wir einen Blick auf die Bedeutung des ersten Teils:
„clients6.google.com“: ist eine Anfrage für „googleapis.com“. Eine weitere Darstellung Methode, da das Cookie nur auf den Subdomain-Namen von google.com zugreifen kann, daher ist diese Methode erforderlich; Möglichkeiten zur Generierung von SAPISIDHASH im Forum, die nichts mit dieser Schwachstelle zu tun haben;
„X-Origin“: auch bekannt als „Origin“, ist für den SAPISIDHASH-Teil hier und den Client unverzichtbar, um eine vertrauenswürdige Überprüfung für den Zugriff auf die Website durchzuführen Header-Informationen;
Cookie: einschließlich SID, HSID, SSID, APISID und SAPISID usw. Google-Benutzer müssen sich anmelden, um diese Cookie-Informationen zu erhalten.
由此看来，要伪造谷歌云端控制台（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.。
该漏洞的出现会对谷歌服务产生重要影响，一些重要的流程使用服务配置中的服务名称来执行除权限检查之外的任意操作，所以，如果配置中加入了不同的服务名称后，攻击者就可以在不同的服务中执行一些重要的操作。这些操作包括：
如果我拥有服务"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等）才能访问的内部信息。
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>利用上述同样的方法，我们可以对某云端项目是否启用或关闭某项服务进行控制，但是，要注意的是，这种方法只能禁用其他人项目中的服务，不能执行服务启用操作。
比如，如果我有服务"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 漏洞报告分类
30.01.2018 Alle Dienste, die nicht mit serviceName/serviceConfig.name übereinstimmen, wurden aus den Google-Systemen gelöscht und die Sicherheitslücke kann nicht mehr ausgenutzt werden.
30.01.2018 Das Sicherheitsteam von Google kann die dritte Bedrohung nicht reproduzieren, aber sie ist es Testingenieure können weiterhin 401-Fehler erhalten
30.01.2018 Das Google-Sicherheitsteam hat einen Einbruch entdeckt, der vermutlich mit dieser Schwachstelle zusammenhängt, und hat dringend einen Reparaturpatch veröffentlicht
31.01.2018 Google hat mich darüber informiert Das Entwicklungsteam Ich habe die Schwachstelle eine Stunde nach meinem Schwachstellenbericht unabhängig entdeckt, aber mein Schwachstellenbericht wurde trotzdem zur Bounty-Bewertung an das Google-Sicherheitsteam gesendet
Das obige ist der detaillierte Inhalt vonBeispielanalyse für die Entdeckung von Sicherheitslücken in der Google Cloud Platform und den Erhalt von Prämien. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
