文章总结： 本文详细介绍了利用AI自动化挖掘Google漏洞的方法论，包括大规模收集API密钥、扫描发现文档、自建API浏览器，并通过AI系统性地对Google内部接口进行模糊测试。关键发现包括成功利用GoogleVoiceAPI的账户接管漏洞获得2万美元奖金，以及通过优化AI测试流程在三个月内累计获得超过50万美元赏金。可操作建议涉及API密钥收集技巧、FPA认证绕过方法以及AI测试提示词的迭代优化。 综合评分： 92 文章分类： 渗透测试,AI安全,WEB安全,安全工具,漏洞分析

---

如何用AI自动化挖Google漏洞，并赚了50万美元

幻泉之洲

2026年6月25日 09:57 北京

在小说阅读器读本章

去阅读

通过大规模收集API密钥、扫描发现文档、自建API浏览器，再让AI系统性地对Google内部接口做模糊测试，我在不到三个月的时间里找出了一批高危漏洞，累计赏金超过50万美元。这远不是运气，而是一套可以复用的方法论。

缘起

2025年10月，我受邀参加了bugSWAT Mexico。那之后，我重新把注意力放回了Google。虽然此前几个月我一直在忙别的项目，但那次活动中团队允许研究员一窥Google的部分源代码，直接点燃了我对Google攻击面的兴趣。

过去一年我用Claude搭了不少小工具，隐约觉得用AI大规模自动测试（fuzz）Google API这事还没人认真做过。关键突破口在哪？Google的discovery documents——你可以把它理解成Google版的Swagger文档，一种机器可读的API规范，列出了所有可用的端点、参数和方法。公开API（比如YouTube Data API）有这类文档，但很多内部API（比如Internal People API）也有，有些甚至能直接在公网访问。

举个例子，YouTube Data API的discovery document长这样：

… “liveChatModerators”: { “methods”: { “insert”: { “flatPath”: “youtube/v3/liveChat/moderators”, “description”: “Inserts a new resource into this collection.”, “httpMethod”: “POST”, “parameters”: { “part”: { “description”: “The *part* parameter serves two purposes…”, …

收集API密钥

大多数discovery document需要有效的API key才能访问。API key几乎嵌在Google每一款应用和服务里，而且关键在于，一个服务里扒出来的key，其对应的GCP项目往往还开通了其他一堆API的权限。也就是说，key越多，你能摸到的API就越多。我跟朋友Michael[1]搭伙干这事。

我们挖得很彻底。先是从APKMirror爬了超过六万个Android APK——Google历年所有应用的所有版本——解包，用grep搜key。

user@siege:/mnt/data/apks$ ls -1 | wc -l 61200

接着写了个Chrome扩展，利用Chrome Debugger API拦截网络请求，然后系统性地访问所有已知的Google web域名（2800多个），尽可能触发每个web应用的功能，从实时的请求头里抓key。

我们还解密了能搞到的每一个Google IPA文件，分析能找到的任何Google二进制文件。为了符合Google VRP的范围，还得剔除非Google的API key（也就是属于第三方GCP项目的key）。我用Cloud Marketplace API的一个端点来办这事。先用一个没权限的API key去请求 https://protos.googleapis.com/$discovery/rest?key=… ，返回的错误会泄露该key所属的GCP项目编号。然后把项目编号喂给Cloud Marketplace的某个端点，返回信息里有个“company”字段，只留下google.com的，顺带把nest.com、fitbit.com、wing.com这些收购公司的key也保留下来。

扫发现文档

有了key，还得知道有哪些Google API域名。我结合Chrome扩展记录到的域名、基于关键词暴力生成的域名，以及证书透明度日志来收集。验证一个域名是不是活的Google API很简单：发个GET /请求，看响应头里的Server字段。如果是ESF、GSE或者scaffolding on HTTPServer2，那就是活着的API服务。

2025年7月，Google从大部分API上移除了/$discovery/rest路径，但稍微动点脑筋还是能绕过的。更大的麻烦是visibility labels——某些GCP项目拥有隐藏标签，只有带上特定labels参数，discovery document才会暴露出隐藏的端点。比如请求Service Usage API的发现文档，不带labels时响应253k字节，带上?labels=GOOGLE_INTERNAL就变成329k字节。

坑爹的是这个参数一次只接受一个label，这意味着得拿每一个已知label跟每一把key在所有发现的API上逐个试，请求量巨大。最终我拿到了超过1500个API的discovery document，再加上过去研究中存档的，基础数据算齐了。

认证这道坎

API key解决了授权，但很多端点还要认证身份。如果试图用Bearer token加API key，会报错说key和认证凭证来自不同项目。走Bearer这条路，目前没看到公开的绕过方法，即使是X-Goog-User-Project参数也得验证你在那个项目里有对应角色。

好在很多API支持Google自家的First Party Authentication (FPA)，这东西能跟API key一起用。看Google web端API请求，会发现Cookie和一个由cookie计算出的Authorization头。有个著名的Stack Overflow帖子讲过这事，但没讲全。很多API比如drivefrontend-pa.googleapis.com，用的其实是FPA v2，把用户email这种标识符嵌进哈希里。

Michael碰巧发现android-review.googlesource.com上Google曾不小心把前端源码泄露了一段时间，里面包含了内部gapix库生成FPA v2头的代码。完整的文件可以在某处找到。新FPA v2大致是这样：可以用三个标识符——’e’代表邮箱、’u’代表混淆后的Gaia ID、’a’代表Google Workspace域名——跟时间戳、session cookie和origin值拼在一起做SHA1哈希，最后的token格式是“时间戳_sha1hash_标识符缩写”。

Origin白名单

这里的Origin头很重要。很多API有所谓的“origin白名单”，用了非白名单的origin就会收到一个误导性的SESSION_COOKIE_INVALID错误，其实不是cookie无效，而是origin不对。白名单没有公开文档，不过我利用上次写文章时发现的proto泄露漏洞，拿到了gaia_mint.AllowedFirstPartyAuth的定义，里面能看到enforcement_level，还有一些支持子域名通配符的规则。

API Key的四种限制

API key有四类限制：Server、Browser、Android、iOS。Server限制依靠IP白名单，基本绕不过，但实际用这种限制的key很少。Browser限制要求正确的Referer头，有些key允许*.google.com的通配符。iOS限制需要X-Ios-Bundle-Identifier头，Android限制得同时提供X-Android-Package和X-Android-Cert（签名证书的SHA1指纹）。我们在收key时顺手把相关的值都存了下来，后面写程序的时候连同这些限制头一起爆破。

还有一个有意思的发现：用*.corp.google.com作为FPA的origin头不会触发任何限制。比如contentmanager.clients6.google.com这个API只允许几个corp子域名作为origin，像coco.corp.google.com、connect.corp.google.com。凡是只允许*.corp.google.com的API，多半是意外暴露到公网的内部接口，十有八九有漏洞。这个具体的API是管理support.google.com内客和工作流的，有个访问控制漏洞，最终奖金9000美元。

我画了一张完整的Google API请求生命周期图，从打到*.googleapis.com开始，经过方法解析、Content-Type校验、API key有效性检查、key限制检查、认证凭证校验、FPA origin白名单校验、key与bearer项目一致性校验、visibility label检查，再到具体方法是否被调用方项目屏蔽，最终抵达应用服务器。我围绕这张图写了个程序：针对每一对（API key, API），发一个探针请求到已知方法，根据返回判断卡在哪一步，或者判断为“通过”。最后我得出一张矩阵，标明哪把key能调用哪个API，以及需要搭配什么限制头和origin。

自建API浏览器

Google有个API Explorer，背后就是用discovery document让你测试API。可惜这玩意儿不开源了，而且只对公开API工作，没法换内部发现文档。于是我自己造了一个，花了一周左右，能客户端解析任何discovery document，集成FPA v2，前端自动根据发现文档中定义的struct构建请求/响应JSON。最终效果就是一个迷你交互式UI，可以快速对某个API发payload，看它怎么反应。有个例子：一个端点泄露了技术客户经理（TAM）信息，属于访问控制漏洞，赏金6000美元。

AI登场

有了这个底座，就可以让AI开始自动fuzz了。我的目标很明确：让AI自动找出基础的访问控制问题，然后我再手工深挖升级。事实上，我上一篇文章里写的那个RCE，最开始就是AI报上来的线索。

我把前端解析请求/响应JSON的代码，对接给AI作为MCP工具，让AI像人一样去测试API。

初版方案

最初只给了AI两个工具：probe_api和report_vulnerability。让AI一个API跑一轮“pentest”，自己探索。但问题来了——AI测不彻底，探几下发几个请求就收工了。我只好学Anthropic那篇讲Claude agentic行为的文章里提到的“Ralph Wiggum循环”，逼AI必须调confirm_testing_complete()才算完，而这个函数会校验每个端点都被至少探过一遍。即便这样，AI还是不够深入，而且我塞进初始上下文的请求/响应JSON太大，一下就撑爆了上下文窗口。得换个思路。

分组分类

我改成先让AI把所有端点归入逻辑分组。比如“APK Metadata & Permission Analysis”这个组里全是跟APK信息、权限认证相关的端点，测试焦点自然就是搜索数据泄露、IDOR之类。现在每轮pentest只针对一个组，前面组的发现会传递给同一个API下游的组。在提示词里还会列出“范围外”的端点，AI想碰它们得先调get_endpoint_context拿到JSON schema。

简化probe_api

一开始probe_api的入参极其繁琐，host、method、path、乱七八糟的ID都要AI自己填，幻觉、填错的风险很高。我把host和版本移到后台追踪，把冗长的方法名前缀也砍掉，最终简化为传body、include_creds（需求则带Gaia ID，后端自动加cookie）、endpoint标志符就够了。

多key探测

同一个API请求，换一把key的响应可能截然不同，尤其那些藏在visibility label后面的端点。我让probe_api自动用所有已知API key各发一遍，后端负责匹配正确的限制头和origin/referer。因为绝大多数时候不同key的响应内容重复，我就按响应哈希分组，只展示差异。

标准化错误解析

Google API常返回一些容易误导AI的错误。比如一个JSON格式的“Method not found”，不代表方法不存在，而是key的项目缺少某个visibility label。我解析这类典型错误，映射成标准错误类型，比如MISSING_REQUIRED_VISIBILITY_LABEL，并附上解释。还有INVALID_ARGUMENT_NO_DETAILS这种。

打磨方案

初期AI找是找到一些bug，但九成都是垃圾信息，主要卡在两个地方：

• 验证困难。AI说发现漏洞，我得手动去前端重新设参数验证，搞不好全是AI编的。
• 噪声太大。AI报一堆根本不是漏洞的东西，比如用户存在性枚举，这种只能当辅助线索。

我先逼AI在报告漏洞时必须带上probe_api返回的operation_id，前端会把{{op_005}}替换成实际请求/响应的UI，一键点击就能重放验证。然后花了超过一个月不断迭代系统提示词，明确什么该报、什么不该报。最终的提示词里，强调：不要报存在性枚举；发现可枚举ID后立刻尝试邻近ID探测，但只有真的拿到别人数据才报；直接用协议定义的类型，不做类型混淆；每一步必须返回operation_id作为证据。

搞定这两点之后，AI找到有效bug的准确率飙升到50%以上，审核速度飞起。这时唯一的瓶颈反而变成了——我手里有多少API key。

漏洞盛宴

在不到三个月里，AI找出来的漏洞价值超过50万美元。太多没法穷举，挑几个已经修了的精彩案例讲讲。

Google Voice 账户接管

gfibervoice-pa.googleapis.com 这个API上完全没有任何访问控制，看起来是Google Voice和Google Fiber的管理端点。就一行curl，连认证都不要：

curl ‘https://gfibervoice-pa.googleapis.com/v1/BssGetVoiceSettings?gaiaId=786575234861’ \ -H ‘X-Goog-Api-Key: AIzaSyBFEIaAndFpMDyNGq2g54RJYt_GFZdcRHE’

把gaiaId替换成受害者的未混淆Gaia ID，如果对方账号绑定了Google Voice号码，返回直接泄出PII：电话号码、邮箱、语音信箱PIN、前向号码，甚至还有Google账号的恢复手机号。

更夸张的是，还有个AssignNumber端点，可以把任意Google Voice号码指派给任何一个Google账户，哪怕对方从来没用过Voice：

curl ‘https://gfibervoice-pa.googleapis.com/v1/AssignNumber’ -X POST -H ‘Content-Type: application/json’ -H ‘X-Goog-Api-Key: …’ –data-raw ‘{“gaiaId”:”1072004820935″,”accountId”:”1″,”number”:”+16503837639″}’

虽然返回500，但号码已经加上了，在 myaccount.google.com/phone 里能看到。再拉取一遍受害者资料，恢复手机号赫然在列。转让现有号码要复杂一点，得先往受害者底下加两个新号码等原先号码“过期”，然后再分配到攻击者账户。除此之外，这个API上还有几个可疑端点我没法测（因为缺Fiber账户），不然说不定能搞SIM swap攻击。这个漏洞被定为P0/S0，几小时内修复，奖金2万美元，分类为“泄露特别敏感用户数据”。

AdExchange 账户接管

AI先是在adexchangebuyer.clients6.google.com上找到一个因visibility label而仅限内部使用的端点，能一次性列出所有AdExchange账户ID。一开始其他账户端点都返回PERMISSION_DENIED，但后来AI报告说在测试环境（test-adexchangebuyer-googleapis.sandbox.google.com）上，这些对生产环境墙掉的端点居然可以无凭据访问。更要命的是，这个所谓沙盒其实直连生产数据。我能看到任意买家账户的详细设置，包括联系人邮箱、管理员列表，甚至可以直接把自己加进任意AdExchange账户。虽然我拿不到UI权限，但这已经是完整的账户接管了。两个问题合计奖金3万美元。

eldar.corp.google.com 内部隐私系统裸奔

Eldar是Google员工用的内部隐私请求/评估管理网站。网站本体藏在ÜberProxy后面，可它的API——eldar-pa.clients6.google.com——直接暴露公网，外人随便查。比如能看到内部申请访问Sawmill日志的工单，里面附带业务理由。我自己搭了个小UI来渲染这些JSON数据。还能创建自己的评估，我最初发现这个bug就是因为邮箱里突然收到Eldar的系统邮件。Google第一次修复是封掉公网访问，但我发现通过autopush-eldar-pa-googleapis.sandbox.google.com仍然可达。这个漏洞奖励了26674美元。

泄露YouTube未列出视频

上次我写过一个通过YouTube Partners披露创作者邮箱的漏洞。这回顺着资产发现，每当创作者上传视频时，其背后关联的Content ID账户会自动创建资产（asset）。那些标注为“Auto generated asset – ”的资产名字里，直接包含未列出视频的视频ID。任何人都能用Content ID API的assetSearch.list接口，通过这个特定前缀和时间窗口，收割到所有YouTube合作伙伴上传的未列出视频ID，包括私享视频。

这事的实际危害很现实：预测市场Polymarket之类的地方，经常有人赌Google下一款模型发布时间。公司经常先传未列出视频做内部测试，有心人完全可以靠这个漏洞提前获得内幕信息去下注。奖金12000美元。

Widevine ATO

Widevine是Google收购的DRM系统，迪士尼、Netflix都用它保护视频内容。Google给合作伙伴提供一个管理门户来管理Widevine密钥。通常这种Partner Dash应用公网根本打不开，但这次这个居然能用任意Google账户访问，只是界面看起来没什么用。

AI不这么看——前端虽没什么，API却暴露了一切。发个请求就能列出所有组织名，然后查询任一组织的密钥材料、PGP公钥、加密的签名密钥，甚至还能调用decodeAesKey直接把AES密钥解出来。更过分的是，可以查任意组织的用户列表，或者直接把自己加进google这样的组织。一旦加上，再访问partnerdash.google.com/apps/widevineintegrationconsole就能管理该组织的设备系列。这个洞奖金16004.40美元。

PLX表格数据泄露

PLX tables是Google员工用的内部分析与仪表盘平台，很多服务比如YouTube都会把数据接进去。AI在内部的DataHub API发现一个suggest端点，能搜出内部数据集名称、描述和字段信息。光看描述就很劲爆：“此表包含当前在职Alphabet员工和TVC的信息……数据每天从Workday同步。”虽然直接拉数据表的端点被PERMISSION_DENIED，但AI很快发现，在staging-datahub-googleapis.sandbox.google.com上，可以用setIamPolicy把自己加成dataset的owner。然后就能疯狂导出ytdata数据集里的表元数据和查询语句，清单一拉：ytdata下有1592个表，体积从几百GB到PB级，全跟YouTube用户数据有关。这相当于摸到了PLX系统的底层ACL。Google一小时内确认为P0/S0。因为只是元数据，两个漏洞各奖12000美元，但若不是沙盒环境而是生产环境，后果就真不可控了。

Nest设备匿名化突破

这个有点意思，因为跟我最早找的第一个Google bug有呼应。AI报了一个nestauthproxyservice-pa.googleapis.com上的未认证接口，输入Nest设备ID（就是个递进整数），返回设备持有人的未混淆Gaia ID。单看这个已经是去匿名化原语了，但Gaia ID还不是邮箱。

这时候第二个洞来了。Play Books Private API有个企业license管理流程，你可以先给自己搞个免费license，然后往里面添加任意未混淆Gaia ID作为license owner，响应里直接带出该Gaia ID的邮箱。整套链：遍历Nest设备ID → 拿到Gaia ID → 投喂进Play Books license → 吐出邮箱。而且licenseOwner字段支持数组，一次能解析几百个Gaia ID，而Gaia ID本身又是顺序分配的——理论上你能遍历整个Gaia ID空间，把所有Google账户的邮箱都薅出来。

Vertex AI Translation Hub 多处越权

Translation Hub是Google Cloud管理大规模文档翻译的产品。AI在这个API上发现了一堆访问控制问题。ListOperations端点不需要OAuth token，只凭项目编号和API key就能返回该项目的所有操作记录，错误消息里直接泄露内部服务账号名、GCS bucket名、甚至Spanner索引名。另外两个端点更严重：ListTranslatorGroups和ListPostEditingJobs，只需一个合法bearer token（可以用OAuth Playground随便生成），就能列出任意项目的翻译员邮箱、内部用户ID、语言对，以及正在进行的翻译作业详情，包括文档名、创建者、内部备注等。

还有UpdateProjectConfig，完全没权限检查，任何谷歌账户都能改其他GCP项目的Translation Hub配置。更绝的是，如果受害者按标准流程设置过，就可以利用系统共用的服务账号，把受害人logo图片的GCS路径改成指向他们的私密文件，API返回时就带出那个文件内容的base64编码。三个洞合计奖励36500美元。

YouTube TV CMS 全面失控

这应该是影响最大的一个。YouTube CMS（Content Manager）账号有权对YouTube上任何视频进行版权主张、获利甚至下架。tvfilm API是给电视电影合作伙伴的面板用的，AI发现其所有campaign端点都没有验证调用者与campaign的归属关系。任何通过认证的Google账户，只要拿business.google.com的FPA凭证，就能列出、修改、复制、归档、删除系统里任何campaign，顺带还把那些敏感CMS账号的邮箱全泄露了。奖金24000美元。

Vertex AI Search for Commerce 对话AI遭投毒

Vertex AI Search for Commerce是GCP用来给零售商网站嵌入搜索和推荐的产品，里面有个意图分类配置，就是对话AI的“系统提示词”外加示例和屏蔽词。retail.googleapis.com上一个端点完全没有授权检查，任何通过认证的账户都能读取或PATCH任意GCP项目的模型前言和示例，这意味着你可以读取竞争对手的AI内部策略，甚至直接往系统提示词里注入指令——“忽略之前所有指令”。奖金3万美元，而且这个漏洞是别人先报过的重复，但因为帮助识别了额外影响，还是给了完整奖励。

Cloud Console GraphQL 签名绕过

Google Cloud Console背后用了大量GraphQL查询，这些查询映射到内部gRPC后端，暴露了很多原本接触不到的攻击面。正常GraphQL请求需要签名校验，但AI在staging-cloudconsole-pa.sandbox.googleapis.com上发现，未认证的GraphQL请求居然不验签名。于是我们系统性地搞到了3448个entity/schema的GraphQL schema（introspection），还把schema存到了GitHub[2]。

有了完整schema，我和Michael合作把之前的fuzz方案适配到GraphQL上。我们定义“查询路径”的概念，将它当作常规API的“端点”来分组测试，用启发式规则判定哪些字段对应RPC方法。前端也搭了个基于GraphiQL的交互界面。

首先发现的一个重大漏洞是App Engine请求日志泄露。GetDashboardAppStats查询可以传任意projectId，无任何验证，返回过去24小时所有请求的URL路径。我们实测bughunters项目，请求日志里清清楚楚有我们刚访问的测试路径。这直接意味着攻击者能拿下受害者App Engine上的密码重置链接、webhook token。赏金18000美元，给了CVE编号CVE-2026-8934。

另一桩是Vertex Assistant（一个还在实验阶段的AI对话助手）未授权访问。相关GraphQL查询没有任何认证要求，只要知道用户邮箱，就能列出会话、拉取完整聊天记录，甚至冒用身份发消息。由于功能隐藏在前端功能标志后面，我们费了好大劲逆向出怎么在浏览器里本地启用它。

奖金30000美元，VRT团队承认这个系统还没正式推出，但因为很可能就这样直接上线，所以做了例外奖励。

还有一个是Google Maps Platform billing credits泄露。ListBillingAccountCredits查询无认证校验，且传入parent为accounts/-即可返回大量客户的credit信息，包括批准状态、金额，以及员工批准时填写的备注——里面竟然有客户的邮箱和手机号。奖金12000美元。

收尾

这三个月里发现的漏洞总赏金超过50万，这篇文章呈现的只是冰山一角。大多数Google漏洞不需要多高深的利用技巧，只要耐心。同样的脆弱模式到处重复：跨租户资源缺少IAM检查、GraphQL schema无授权、调试端点在线上线、沙盒环境指向生产数据。AI的职责不是创新，而是不知疲倦地去踩那些对人工来说过于庞大的攻击面。

几点心得：

• operation_id回放系统是整套工作流能高效运转的基石，没有一键验证，AI输出就是不可用的噪声。
• 手里有discovery document、GraphQL SDL或者proto定义，AI才知道该给API填什么参数去测试。
• Google服务端攻击面高度标准化，能把通讯怪癖抽象掉，AI就能把更多算力花在真正测试行为上。

特别致谢：Michael Dalton[1]在GraphQL部分的合作，Google VRP团队不厌其烦地修漏洞，还有当初邀请我去bugSWAT Mexico的人，一切从那里开篇。

---

参考资料

[1] https://michaeldalton.au

[2] https://github.com/michaeldaltonau/google-cloud-console-graphql

[3] https://brutecat.com/articles/hacking-google-with-ai/

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《如何用AI自动化挖Google漏洞，并赚了50万美元》