次は、ウルグアイの 17 歳の高校生についてです。彼は情報セキュリティに興味があったため、勉強や研究を通じて独自に Google Cloud Platform の脆弱性を発見し、7,500 ドルを受け取りました。(以前、彼は 10,000 ドル相当の Google Cloud Platform の脆弱性 (ホスト ヘッダー リークの脆弱性) を発見していました。この脆弱性の詳細を説明する前に、読者は Google Cloud サービスと API メカニズムの概念をよく理解しておくことをお勧めします。
Google は、Google サービス マネジメントと呼ばれる管理サービスを運営しており、これを通じて、ユーザーが作成したさまざまなアプリケーション Google システムやクラウドの内部および外部インターフェイスを管理します。 Google サービス管理では、ユーザーはクラウド プラットフォーム プロジェクトで Maps API、Gmail API、プライベート API などのパーソナル インターフェース サービスを個別に有効または無効にすることができ、インターフェース設定ファイルを通じてさまざまなサービスをリアルタイムで管理できます。
一般的に、開発者として Google サービス マネジメント サービスを直接使用することはほとんどありません。ほとんどの対話型操作は、クラウド コンソール Google Cloud Console またはコマンド ライン (サービスの有効化/終了など) を介して行われます。 API 管理インターフェイスは Google Cloud Endpoints ですが、Google Service Management サービスの興味深い API インターフェイスがあることにも言及する価値があります。
この API インターフェイスは、上記のサービス管理機能を実現できるだけでなく、この API インターフェイスを使用して Google サービスのいくつかの隠された機能にアクセスできることを Google の公式ドキュメントに記録しています。
これらの隠れた機能はさまざまな方法で見つけることができますが、最もシンプルで簡単な方法は、ユーザーの Google Cloud Platform プロジェクトでサービス管理の API インターフェースを有効にし、プロジェクトのトラフィック フィルタリングにコンボ ボックスの使用を有効にすることです。手順は次のとおりです。
ヒント: Google 独自の API の隠された部分は、さまざまな方法で発見できます。ほとんどの場合、隠されたドキュメントもあります。さらに、Google はそのような隠された API 機能を考慮していません漏洩または隠蔽された API ドキュメントの存在はセキュリティ上の脆弱性です。 (私はこれらのことを Google に報告したことがあります)。ただし、いくつかの隠し機能もあります。これらが悪用されると、セキュリティ上の脆弱性とみなされます。たとえば、1 年前に発見した隠しパラメータはバグを形成しました。 , Googleから5,000ドルの報酬が得られました。この脆弱性はまだ修復期間中であるため、現時点で公開することは困難です。 予備分析上記の知識を理解した上で、Google Cloud ConsoleにアクセスするだけでGoogleの隠れた機能にアクセスできる方法を試してみました。そのため、生成された HTTP リクエストを注意深く分析してください。 Google Cloud Console は、複数のパブリックおよびプライベート Google API、独自のクライアント プログラム、API キー AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g を使用して、クラウド プロジェクトへの情報アクセスを実現します。 Google Cloud Console クライアントからの一般的なリクエストは次のとおりです:
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>
" client6.google .com": は、"googleapis.com" をリクエストする別の表現方法です。Cookie は google.com のサブドメイン名にのみアクセスできるため、このメソッドが必要です。 "SAPISIDHASH": StackOverflow フォーラムによると、これは「TIMESTAMP_HASH」(タイムスタンプ_ハッシュ) の値です。フォーラムには SAPISIDHASH を生成する他の多くの方法がありますが、これらはこの脆弱性とは何の関係もありません; 「X-Origin」: とも呼ばれます。 Origin」は、SAPISIDHASH 部分とクライアントが Web サイトへのアクセスを認証するために不可欠なヘッダー情報です。Cookie: SID、HSID、SSID、APISID、SAPISID などが含まれます。Google ユーザーはログインする必要があります。これらのCookie情報を取得します。
由此看来，要伪造谷歌云端控制台（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 漏洞报告分类
2018-01-30 serviceName/serviceConfig.name に一致しないすべてのサービスは Google システムから削除され、この脆弱性を悪用することはできなくなりました
2018-01-30 Google セキュリティ チームは悪用できなくなりました修復 3 番目の脅威が発見されましたが、テスト エンジニアは依然として 401 エラーを受け取る可能性がありました
2018-01-30 Google セキュリティ チームは、この脆弱性に関連すると思われる侵入を発見し、緊急に修復パッチをリリースしました
2018-01-31 Google は、私の脆弱性報告から 1 時間後に開発チームが独自に脆弱性を発見したと私に通知しましたが、私の脆弱性報告は依然として報奨金評価のために Google セキュリティ チームに送信されました
2018-02 -14 Google は私に 7,500 ドルのバグ報奨金を発行してくれました
以上がGoogle Cloud Platformの脆弱性を発見して報奨金を受け取る分析例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
