API启用后，数千个可通过Gemini Access访问的Google Cloud公共API密钥遭到泄露
当用户在 Google Cloud 项目（即生成语言 API）上启用 Gemini API 时，就会出现此问题，导致该项目中现有的 API 密钥（包括可通过网站 JavaScript 代码访问的密钥）在没有任何警告或通知的情况下，偷偷访问 Gemini 端点。
最新研究发现，通常被指定为计费项目标识符的 Google Cloud API 密钥可能会被滥用，用于对敏感的 Gemini 端点进行身份验证并访问私人数据。
这项发现来自 Truffle Security，该公司在客户端代码中发现了近 3000 个 Google API 密钥（以“AIza”为前缀），用于提供 Google 相关服务，例如在网站上嵌入地图。
安全研究员乔·莱昂表示： “有了有效的密钥，攻击者就可以访问上传的文件、缓存的数据，并将 LLM 使用量计入您的帐户。”他还补充说，这些密钥“现在还可以对 Gemini 进行身份验证，尽管它们原本并非为此而设计的。”
当用户在 Google Cloud 项目（即生成语言 API）上启用 Gemini API 时，就会出现此问题，导致该项目中现有的 API 密钥（包括可通过网站 JavaScript 代码访问的密钥）在没有任何警告或通知的情况下，偷偷访问 Gemini 端点。
这实际上允许任何抓取网站的攻击者获取此类 API 密钥，并将其用于不法目的和配额窃取，包括通过 /files 和 /cachedContents 端点访问敏感文件，以及发出 Gemini API 调用，从而给受害者带来巨额账单。
此外，Truffle Security 发现，在 Google Cloud 中创建新的 API 密钥默认设置为“不受限制”，这意味着它适用于项目中所有已启用的 API，包括 Gemini。
“结果是：数千个原本作为无害计费令牌部署的 API 密钥，现在变成了活跃的 Gemini 凭证，暴露在公共互联网上，”Leon 表示。该公司称，总共发现了 2863 个可在公共互联网上访问的活跃密钥，其中包括一个与谷歌相关的网站。
就在 Quokka 发布类似报告之际，此次披露也随之而来。该报告在其对 25 万个 Android 应用的扫描中发现了超过 3.5 万个独特的 Google API 密钥。
这家移动安全公司表示：“除了通过自动化 LLM 请求可能造成的成本滥用之外，组织还必须考虑启用 AI 的终端如何与提示、生成的内容或连接的云服务进行交互，从而扩大泄露密钥的影响范围。”
“即使无法直接访问客户数据，推断访问、配额消耗以及可能与更广泛的 Google Cloud 资源集成等因素，也造成了与开发者最初依赖的计费标识符模型截然不同的风险状况。”
虽然这种行为最初被认为是故意的，但谷歌后来介入解决了这个问题。
谷歌发言人通过电子邮件告诉The Hacker News：“我们已经注意到这份报告，并已与研究人员合作解决这个问题。保护用户数据和基础设施是我们的首要任务。我们已经采取积极措施，检测并阻止试图访问Gemini API的泄露API密钥。”
目前尚不清楚该漏洞是否已被实际利用。然而，两天前，一位Reddit用户发帖称，一个被“盗取”的Google Cloud API密钥导致其在2026年2月11日至12日期间产生了82,314.44美元的费用，而通常每月的支出仅为180美元。
我们已联系谷歌寻求进一步评论，如有回复，我们将更新报道。
已设置 Google Cloud 项目的用户应检查其 API 和服务，并确认是否已启用人工智能 (AI) 相关 API。如果已启用且可公开访问（无论是在客户端 JavaScript 中还是已提交到公共代码库中），请确保已轮换密钥。
Truffle Security建议：“先从最早的密钥开始排查。这些密钥很可能是在旧的API密钥共享安全准则下公开部署的，然后在团队中有人启用API时，才追溯性地获得了Gemini权限。”
Wallarm的安全策略师蒂姆·厄林在一份声明中表示：“这很好地说明了风险的动态性，以及API权限在事后可能被过度授予的情况。安全测试、漏洞扫描和其他评估必须持续进行。”
“API尤其棘手，因为其操作或可访问数据的变更未必构成漏洞，但却会直接增加风险。在这些API上运行和使用人工智能只会加剧这个问题。仅仅发现API漏洞是不够的。组织必须分析行为和数据访问情况，识别异常并主动阻止恶意活动。”
关于作者
评论1次
### 结论 Google Cloud API密钥因默认权限及API启用流程缺陷，导致未授权访问Gemini端点的风险被放大。攻击者可利用暴露于客户端代码中的密钥（如JS中硬编码的AIza开头密钥），触发敏感文件读取、配额消耗及LLM调用成本欺诈。核心问题在于API密钥权限动态扩展缺乏透明度，且默认配置未限制API作用域。 --- ### 分析路径（T00ls方法论） #### **L1 攻击面识别** 1. **暴露源（Source）**： - 客户端代码（如网页JS、Android应用）中硬编码的Google API密钥（AIza开头）。 - 默认未限制的API密钥（覆盖所有启用的API，含Gemini）。 2. **攻击面（Sink）**： - Gemini端点（如`/files`、`/cachedContents`）被未授权调用，允许文件下载或LLM API滥用。 - 计费关联：攻击者调用产生的费用计入受害者的Google Cloud账户。 #### **L2 假设与验证** - **假设**：启用Gemini API后，项目中现有API密钥自动获得访问权限，且无变更通知。 - **验证步骤**： 1. 检查Google Cloud项目中已启用的API列表，确认Gemini是否被意外启用。 2. 使用暴露的密钥尝试调用Gemini端点（如`GET https://generativelanguage.googleapis.com/v1beta/models/gemini-pro:generateContent`），观察是否返回敏感数据或成功调用。 3. 审计API密钥的`API restrictions`设置，默认是否为“无限制”（允许所有API）。 #### **L3 边界/异常场景** - **边界条件**： - 仅启用Gemini API的项目，其密钥是否仍能被外部调用？ - 未启用Gemini的项目，密钥是否因其他API关联间接暴露？ - **异常场景**： - 攻击者通过`/files`端点下载非公开训练数据或用户上传文件。 - 恶意调用Gemini API生成钓鱼内容，结合云函数触发链式攻击。 #### **L4 防御反推与修复** - **防御机制失效点**： - Google未在启用Gemini API时提示密钥权限变更，导致用户未及时限制。 - 默认API密钥权限过大，未遵循“最小权限原则”。 - **修复路径**： 1. **权限收敛**：为密钥显式绑定仅必要的API（如`maps`而非全局权限）。 2. **IP/域限制**：设置API密钥的IP白名单或HTTP Referer限制（仅允许可信来源调用）。 3. **监控异常流量**：在Cloud Logging中监控Gemini API调用频率（如突增的`generateContent`请求）。 --- ### 验证步骤 1. **密钥暴露检查**： - 使用爬虫扫描自身域名JS代码，搜索`AIza`开头的字符串。 - 检查GitHub/GitLab仓库是否提交过包含`AIza`的代码文件。 2. **权限验证**： - 登录Google Cloud Console，进入`APIs & Services > Credentials`，检查每个密钥的`Application restrictions`和`API restrictions`配置。 3. **模拟攻击测试**： - 使用暴露的密钥调用`https://generativelanguage.googleapis.com/v1beta/models/text-bison:generateContent`，若返回200且含生成文本，则证明权限滥用可能。 --- ### 修复建议 1. **紧急操作**： - 立即轮换所有暴露或权限过大的密钥，优先替换早期部署的密钥（如Truffle Security提到的历史密钥风险更高）。 2. **配置最小权限**： - 为密钥绑定唯一API（如仅`https://www.googleapis.com/auth/maps`），禁用“无限制”模式。 3. **启用监控告警**： - 在Cloud Monitoring中设置告警规则，当Gemini API调用频率超过阈值（如100次/小时）时触发通知。 4. **长期防御**： - 部署Secrets Manager托管密钥，并通过服务账户动态授权（避免硬编码）。 - 使用API Key Restriction工具链（如Cloud Endpoints）强制请求来源验证。 **附录参考**： - Google官方密钥安全指南：[https://cloud.google.com/docs/security/fundamentals/api-keys](https://cloud.google.com/docs/security/fundamentals/api-keys) - Truffle Security的API漏洞扫描工具：[https://trufflesecurity.com/](https://trufflesecurity.com/)