AI挖洞日记：三个月从Google薅走50万美元
导语：用AI来挖漏洞，听起来是不是有点科幻？三个月前我尝试了这件事，没想到一路开挂，直接从Google薅走了50万美元的漏洞奖金。这不是吹牛，是真实发生的事情。
日记前言
2025年的某天，我盯着屏幕发呆，脑子里冒出一个疯狂的想法：能不能训练一个AI，让它来帮我挖掘Google的漏洞？
我知道你在想什么——Google？那可是Google啊，安全团队上百人，漏洞奖励计划（VRP）运行了十几年，哪还有漏洞可挖？
但实际情况恰恰相反。
Google拥有数千个API，其中大量是内部使用的，管理相对松散。这些”隐秘的角落”往往是最容易被忽略的地方，也是漏洞的温床。
于是，我开始行动了。
第一天：收集”钥匙,
挖漏洞的第一步，是找到进入的门。
Google的API就像一扇扇上了锁的门，而API密钥就是那些钥匙。我需要收集尽可能多的钥匙。
我的收集方式：
第一，从Google的公开文档里扒。Google API Explorer会暴露大量API密钥，我写了个爬虫自动提取。
第二，从公开的YouTube视频和博客文章里挖。Google员工有时候会不小心在视频或文章中露出内部域名和路径的线索。
第三，从GitHub的代码样本里翻。开发者经常把示例代码分享到GitHub，里面经常含有真实的API密钥。
忙活了好几个月，我手头攒了一大堆钥匙，涵盖了各种内部API和服务。
第一周：绘制”地图,
光有钥匙不够，我还需要知道每扇门后面是什么。
Google使用”Discovery文档”来描述API的结构。这些文档是JSON格式，包含端点、参数、认证要求等信息。
我写了一个扫描器，对Google的各个域名进行探测，寻找这些Discovery文档。过程很繁琐——每个文档都有不同的主机名、路径和认证要求。
最终，我成功收集了大量未公开的API文档。
这时，一个清晰的事实摆在我面前：这些API的安全措施，远比我想象的薄弱得多。
第一个月：搞定认证
接下来的障碍是认证。
Google API使用一种叫做FPA v2的认证机制。简单理解就是：
- API密钥用来标识项目
- FPA令牌用来标识用户身份
但问题是，不同API对认证的要求各不相同。有的需要API密钥加FPA令牌，有的只需要API密钥，还有的需要特殊的头部信息。
我花了大量时间测试这些边界情况，找到了许多绕过来源验证的方法。
比如，某些API只检查域名是否包含”google.com”——那我用一个google.com.evil.com就能绕过。
某些API对测试环境的检查过于宽松——那测试环境和生产环境就成了我的后门。
第二个月：造一把”万能钥匙,
手动测试的效率太低了。一个API可能有上百个端点，纯靠人工根本测不过来。
我决定开发一套自动化工具。
这个工具能够：
- 自动探测 — 根据Discovery文档自动生成测试请求
- 多维度测试 — 测试不同的认证状态、不同的参数组合
- 结果对比 — 对比不同API密钥的响应差异
- 漏洞识别 — 自动识别潜在的安全问题
工具开发得很顺利。但我很快意识到，工具能做的仍然有限——它能发现异常，但无法判断这异常是不是真的漏洞。
我需要AI。
AI上岗
让AI来理解API的响应，判断是否存在安全问题，并生成有效的漏洞利用方式——这个想法让我兴奋不已。
我先从一个小实验开始：让AI代理访问一个API，尝试找出IDOR（越权访问）漏洞。
初始方案很简单：
- 给AI两个工具：
probe_api（测试端点）和report_vulnerability（报告漏洞） - 让AI对每个API进行”渗透测试,
- AI完成测试后调用
confirm_testing_complete确认完成
但问题来了：AI测试得不够彻底。它总是浅尝辄止，探几个点就退出了。
我用了Ralph Wiggum循环来逼迫AI完成测试——只有当每个端点都至少被探测一次时，才允许AI结束。
即便如此，AI的准确率仍然不高。它会报告大量”潜在”漏洞，但其中绝大部分根本无法利用。
转折点在于分组策略。
我重新设计了方法：首先让AI把端点按功能分组，然后每个”渗透测试”只聚焦一个分组。这样AI的注意力更集中，测试更深入。
同时，我简化了probe_api的调用方式，把冗长的前缀去掉（比如autopush_cloudcrmcards_pa_sandbox.updateDataFetcherConfiguration直接变成updateDataFetcherConfiguration），减少AI出错的可能。
这是TranslationHub SA的提示词：
还有一个关键优化：让AI用多个密钥探测同一个端点。
在Google的API中，不同密钥访问同一个端点，可能返回完全不同的结果。这是因为某些端点有”可见性标签”限制。
我让probe_api自动用所有已知密钥发送相同的请求。结果立竿见影——AI很快发现了那些”只对特定密钥可见”的隐藏端点。
关于错误解析，也是门学问。
Google API的错误响应往往是加密的。比如这个：
{
"error": {
"code": 404,
"message": "Method not found.",
"status": "NOT_FOUND,
}
}这并不意味着方法不存在——如果真的不存在，响应会是HTML而不是JSON。实际上，这表示你的API密钥缺少某个必需的”可见性标签”。
我将这些错误解析成标准类型，比如MISSING_REQUIRED_VISIBILITY_LABEL，让AI能够理解这些错误的真实含义。
最后，也是最关键的——调整系统提示词。
这花了整整一个多月。我不断告诉AI：什么该报，什么不该报。
比如，能探测某个用户是否存在，这本身不算漏洞。但如果能进一步获取用户的邮箱或姓名，那就是漏洞了。
又比如，500错误不报，401/403/404错误不报，400参数错误也不报——除非它们泄露了额外信息。
这是最终的Vertex AI Assistant配置界面：
调整完成后，AI的准确率突破了50%。也就是说，每两个报告里，至少有一个是真实漏洞。
这时我意识到：唯一的限制因素，变成了API密钥数量。
挖洞进行时
三个月时间，AI帮我发现了大量漏洞。让我挑几个有意思的讲讲。
Google Voice账户接管：一个电话号引发的血案
在测试gfibervoice-pa.googleapis.com这个域名时，我发现了一个让人震惊的事实：它上面完全没有访问控制。
只需要一行curl命令，不需要任何认证：
curl 'https://gfibervoice-pa.googleapis.com/v1/BssGetVoiceSettings?gaiaId=786575234861'
-H 'X-Goog-Api-Key: AIzaSyBFEIaAndFpMDyNGq2g54RJYt_GFZdcRHE'只要目标用户有绑定Google Voice号码，我就能拿到他所有的个人信息——包括：
- Google Voice号码
- 账户恢复手机号码
- 语音邮箱设置
- 来电转接号码
这还没完。API还提供了一个分配号码的端点——我可以向任何Google账户添加Google Voice号码，即使该账户从未使用过Voice。
更绝的是，这个号码会直接出现在受害者的”我的手机”页面上，来源显示为”系统添加”。
想象一下这个攻击链：用这个漏洞拿到目标的手机号，然后通过语音邮箱重置密码，或者直接截获验证码……
这个漏洞被评为P0/S0级别。Google几小时后就修复了，奖金是20,000美元。
AdExchange：测试环境连接着生产数据
AdExchange是Google的广告管理平台。
AI发现了一个可以列出所有AdExchange账户的端点。但当我试图进一步利用时，所有敏感操作都被拒绝了。
转折点在于测试环境。
在test-adexchangebuyer-googleapis.sandbox.google.com这个测试域名上，AI发现了一个新的攻击面——而且这个测试环境的API，连接的是生产数据！
我可以直接查看任何AdExchange账户的详细信息，包括账户名称、联系人邮箱、货币类型、时区设置等。
甚至可以把自己添加为任意账户的管理员：
{
"emailAddress": "gvrptest2@gmail.com",
"accountId": "6558940734",
"status": "PENDING",
"role": "ADMIN,
}这个漏洞拿下了30,000美元奖金。
Eldar：Google员工的隐私系统被我”越权”访问
Eldar是Google员工专用的内部系统，用于管理隐私请求和评估。前端受ÜberProxy保护，本来应该是安全的。
但我发现了问题：API本身暴露在eldar-pa.clients6.google.com上，任何人都能访问。
这意味着什么？
Google员工在Eldar上申请访问各类内部日志和数据的记录，都对我透明公开了。包括谁在什么时间申请了什么数据、审批状态如何等信息。
漏洞修复后，我收到了一封Eldar发来的邮件——这说明我可以创建和分享自己的评估，Google那边完全不知情。
这个漏洞拿到了26,674美元奖金。
YouTube未公开视频：预测市场的”财富密码,
这是我觉得最有趣的一个漏洞。
我发现，每当YouTube创作者上传视频（即使设为未公开），系统都会自动创建一个资产记录。而这些资产的名称，格式是Auto generated asset - 。
这意味着，通过搜索”Auto generated asset – “，我可以枚举YouTube合作伙伴的所有未公开视频ID。
这在现实中有多可怕？
想象一下：某公司准备发布一款重磅产品，提前拍摄了宣传视频设为未公开进行内部测试。有人利用这个漏洞提前观看了视频，然后用内幕信息去预测市场下单……
预测市场Polymarket允许人们对未来事件下注，包括Google下一代Gemini模型的发布。你说，这漏洞是不是”财富密码”？
这个漏洞被评为12,000美元。
Widevine DRM：迪士尼、Netflix的密钥管理门户被我”越权,
Widevine是Google收购的DRM技术，被迪士尼、Netflix等公司用于保护视频内容。
Google为这些合作伙伴提供了一个密钥管理门户。通常这类门户是完全锁死的，但这个却奇怪地可以用Google账户登录——虽然你实际上无法管理任何配置文件。
但AI发现了真相。
通过API，我可以：
- 列出所有使用Widevine的组织
- 查看任何组织的AES密钥
- 解密这些密钥
- 把自己添加为任何组织的管理员
这是成功添加后的界面截图：
想象一下：如果有人利用这个漏洞窃取了Netflix的Widevine密钥，然后制作盗版版本……
这个漏洞拿到了16,004.40美元奖金。
日记尾声
三个月，总计超过50万美元漏洞奖金。
这个数字让我自己都有些恍惚。
但更让我感慨的是AI在其中的作用。它不是万能的，但确实大幅提升了效率——我不再需要手动处理大量重复性测试，AI帮我做了这些苦活累活。
而我需要做的，只是判断AI的发现是否真实，然后写一份清晰的报告。
回过头来看，Google的漏洞主要藏在几个地方：
- 内部API是座金矿 — 与公开API相比，内部API的安全措施往往更薄弱
- 边界情况是突破口 — 来源验证、密钥限制、可见性标签……这些边界条件往往是漏洞的藏身之所
- 系统化方法至关重要 — 建立完善的工具链、测试框架和报告流程，才能持续高效地输出
这是我的工具界面：
现在，如果你问我接下来要挖哪个目标？
答案是：还没有确定。但有一点是肯定的——AI辅助渗透测试的时代，才刚刚开始。
出处：Brutecat – https://brutecat.com/articles/hacking-google-with-ai/
版权声明：本文由华盟网原创发布，保留所有权利。
暂无评论内容