Exemple d'analyse de la découverte des vulnérabilités de Google Cloud Platform et de la réception d'une prime

Ce qui suit concerne un lycéen de 17 ans en Uruguay Parce qu'il s'intéressait à la sécurité des informations, grâce à ses études et ses recherches, il a découvert de manière indépendante une vulnérabilité dans Google Cloud Platform et a reçu 7 500 $. (auparavant, il avait découvert une vulnérabilité d'une valeur de 10 000 $). Avant d'expliquer les détails de cette vulnérabilité, nous recommandons aux lecteurs de se familiariser avec les concepts des services Google Cloud et des mécanismes API.

Pioneer Concept

Google gère un service de gestion appelé Google Service Management, à travers lequel Google gère les interfaces internes et externes de diverses applications et services Cloud des systèmes Google. créés par les utilisateurs eux-mêmes. Sous Google Service Management, les utilisateurs peuvent activer et désactiver individuellement des services d'interface personnelle tels que l'API Maps, l'API Gmail, les API privées, etc. dans leurs projets de plate-forme cloud, et peuvent gérer divers services en temps réel via le contrôle des fichiers de configuration d'interface.

De manière générale, en tant que développeurs, nous n'utilisons généralement pas directement les services de gestion des services Google. La plupart des opérations interactives se font via la console cloud Google Cloud Console ou la ligne de commande (telle que l'activation/la fermeture des services). . Ou cela peut être fait via l'interface de gestion des API Google Cloud Endpoints, mais il convient de mentionner qu'il existe une interface API intéressante du service Google Service Management.

Cette interface API peut non seulement réaliser les fonctions de gestion de services ci-dessus, mais également enregistrer dans la documentation officielle de Google que vous pouvez utiliser cette interface API pour accéder à certaines fonctions cachées des services Google.

Ces fonctions cachées peuvent être découvertes de plusieurs manières, mais la plus simple et la plus simple consiste à activer l'interface API de gestion des services dans le projet Google Cloud Platform de l'utilisateur et à activer la zone de liste déroulante pour le filtrage du trafic du projet. . Les étapes sont les suivantes :

à la fin de ce qui précède, une image contient diverses méthodes d'utilisation de l'API pour implémenter des fonctions, y compris certaines méthodes cachées marquées par des cases rouges. La méthode dite cachée est que les clients non-Google ne sont pas autorisés à y accéder. Lorsque des clients non-Google tentent d'y accéder, une erreur 404 est renvoyée. Ce qui est très intéressant, c'est que cette erreur 404 n'apparaît pas comme une invite "erreur ici" comme la page HTML habituelle, mais est donnée en mode JSON, ce qui indiquera que la méthode n'existe pas.

De même, il existe également des méthodes cachées dans l'API elle-même. Ce sont des paramètres cachés reçus dans certaines méthodes publiques, mais relativement parlant, ces méthodes cachées sont plus difficiles à découvrir.

Pour les méthodes cachées et les paramètres cachés, ils utilisent tous une fonctionnalité du service Google appelée "Visibilité". Cet enregistrement de fonctionnalité peut être interrogé à partir de documents publics, mais n'est utilisé qu'en interne par Google.

Astuce : Les parties cachées de la propre API de Google peuvent être découvertes de plusieurs manières. La plupart du temps, elles contiennent également de la documentation cachée, et Google ne considère pas cela comme la valeur. la fuite de fonctions API cachées ou l’existence de documents d’enregistrement API cachés constituent une vulnérabilité de sécurité. (Je les ai signalés une fois à Google).

Cependant, il existe également certaines fonctions cachées qui, si elles sont exploitées avec succès, seront considérées comme une faille de sécurité, comme un paramètre caché que j'ai découvert il y a un an avec succès. en exploitant cette vulnérabilité, Google m'a récompensé de 5 000 $. Étant donné que la vulnérabilité est encore en période de réparation, il n’est pas opportun de la divulguer pour le moment.

Analyse préliminaire

Après avoir compris les connaissances ci-dessus, j'ai essayé d'utiliser une méthode pour accéder à ces fonctions cachées de Google. Ce n'est pas difficile à dire, il suffit d'accéder à Google Cloud Control. Lorsque vous utilisez Google Cloud Console, analysez attentivement les requêtes HTTP générées.

Google Cloud Console utilise plusieurs API Google publiques et privées, son propre programme client et la clé API AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g pour accéder aux informations sur les projets cloud.

Les requêtes courantes pour le client Google Cloud Console sont les suivantes :

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>

Jetons un coup d'œil à la signification de la première partie :

#🎜 🎜## 🎜🎜#"clients6.google.com": C'est une autre méthode de représentation pour demander "googleapis.com". Puisque le cookie qu'il contient ne peut accéder qu'au nom de sous-domaine de google.com, cette méthode est nécessaire ;

# 🎜🎜#"SAPISIDHASH" : D'après le forum StackOverflow, il s'agit de la valeur de "TIMESTAMP_HASH" (timestamp_hash). Il existe de nombreuses autres façons de générer SAPISIDHASH dans le forum, qui n'ont rien à voir avec cette vulnérabilité ;#🎜🎜 #.

"X-Origin" : Aussi connu sous le nom de "Origin", ce sont les informations d'entête indispensables à la partie SAPISIDHASH et au client pour authentifier l'accès au site internet

Cookie : incluant le SID ; , HSID , SSID, APISID, SAPISID, etc. Les utilisateurs de Google doivent se connecter pour obtenir ces informations sur les cookies.

由此看来，要伪造谷歌云端控制台（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 Tous les services qui ne correspondent pas à serviceName/serviceConfig.name ont été supprimés des systèmes Google et la vulnérabilité ne peut plus être exploitée

2018-01-30 L'équipe de sécurité de Google ne peut pas reproduire la troisième menace, mais son les ingénieurs de test peuvent toujours recevoir des erreurs 401

2018-01-30 L'équipe de sécurité de Google a découvert une intrusion soupçonnée d'être liée à cette vulnérabilité et a publié en urgence un correctif de réparation

2018-01-31 Google m'a informé que cela L'équipe de développement J'ai découvert la vulnérabilité de manière indépendante une heure après mon rapport de vulnérabilité, mais mon rapport de vulnérabilité a quand même été envoyé à l'équipe de sécurité de Google pour évaluation de la prime

2018-02-14 Google m'a versé 7 500 $ pour la vulnérabilité Bounty

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!