北京
安全研究员阿尔温·希夫拉姆（Arvin Shivram）使用自动化模糊测试工具对谷歌云内部接口进行探测时，注意到一个名为 cloudcrmipfrontend-pa.googleapis.com 的内部 API，对可疑的调试类端点竟然返回 HTTP 200 响应。这个异常起点，最终让他从谷歌漏洞奖励计划中获得了 148,337 美元赏金，核心漏洞被编号为 CVE‑2026‑2031，CVSS 风险评分直达满分 10.0。
根据希夫拉姆在 BruteCat 博客上的记录，进一步测试后，他发现其中有一个端点 v1/integrationPlatform/getProtoDefinition，可以返回任意内部消息和服务的 protobuf 描述符，甚至包括 YouTube 和谷歌内部 CRM 栈的结构定义。由于谷歌内部服务重度依赖 protobuf，这种“请求即 proto 描述”式的信息泄露，相当于给了攻击者一套近乎完整的内部 API 模式图，让原本黑盒的研究变得透明。
同一套 API 还暴露了另一个端点 listQuotaQueue。希夫拉姆通过构造特定的查询参数，并加上请求头 X‑Goog‑Encode‑Response‑If‑Executable: base64，成功拿到了内部工作流执行队列的数据，连同关键的 clientId 值（缺省值）。凭借泄露的 clientId，他随后通过内部应用集成后端的 createDraftWorkflow 接口创建了草稿工作流，并开始逐一研究发现文档中可见的任务类型。
真正的转折出现在一个名为 GenericStubbyTypedTaskV2 的内部任务类型。BruteCat 文章指出，这是谷歌 Stubby RPC 框架在应用集成工作流中的泛型封装。通过为这个任务配置 serverSpec、serviceName、serviceMethod 等参数，希夫拉姆能够让谷歌生产环境以集成平台的高权限服务身份，向任意内部服务发起 Stubby RPC 调用。谷歌云漏洞奖励计划文档明确规定，能够发起 Stubby 级别的访问，就相当于在生产环境中实现远程代码执行，因为它可以根据目标服务的 RpcSecurityPolicy 获得广泛的内部数据和操作权限。
草稿工作流最初无法发布，因为谷歌设置了双人审批机制：同一个人不能同时编辑和发布工作流。希夫拉姆在 BruteCat.com 上解释，他通过滥用内部 ACL 端点 integrationPlatform/auth/setAcl，成功添加了两个由攻击者控制的谷歌账户到工作流访问控制列表中，从而绕过了这一限制。谷歌随后修复了该漏洞，措施包括限制内部端点访问、解决不安全的直接对象引用（IDOR）问题，并强化了 RPC 安全控制。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
