Google API 密钥在删除后仍持续工作，存在被利用风险

# Google API 密钥在删除后仍能继续使用 来源：https://www.aikido.dev/blog/google-api-keys-deletion **太长不看版**当你删除一个 Google API 密钥时，界面提示它会立即删除。我们的测试发现实际上需要约 23 分钟。在这段时间窗口内，持有泄露密钥的攻击者仍能访问你的数据和已启用的 API（包括 Gemini）。你无法更快地撤销它，也无法确认它何时完全失效。Google 已将我们的报告标记为“不会修复”。 当你删除一个 API 密钥时，你期望访问权限立即终止。 Google API 密钥的工作原理并非如此。撤销操作在 Google 的基础设施中逐步传播。有些服务器在数秒内拒绝该密钥，而另一些服务器则会继续接受它长达 23 分钟。 持有你已删除密钥的攻击者可以持续发送请求，直到某个请求到达尚未同步的服务器。如果项目中启用了 Gemini，他们可以转储你上传的文件并窃取缓存的对话记录。 GCP 控制台不会显示该密钥，也不会告知你密钥仍在工作。你只能信任 Google 的基础设施最终会完成同步。 ## 身份验证不应是最终一致性的 Google Cloud 的许多服务在设计上是**最终一致性**的（https://en.wikipedia.org/wiki/Eventual_consistency）。在这种模型下，更新会逐步传播到各服务器，而不是一次性完成。这种权衡让 Google 能够实现全球扩展并保持快速响应，对于大多数服务来说，这种延迟是不可见的。但对于身份验证而言，这种权衡很难站住脚。 凭据撤销延迟是可被利用的。几个月前，Eduard Agavriloae 披露了一个**4 秒的延迟**（https://www.offensai.com/blog/aws-iam-eventual-consistency-persistence），使得已删除的 AWS 访问密钥可以创建新凭据。在 AWS 上，4 秒已经足以造成问题。 鉴于最近关于**使用 Google API 密钥访问 Gemini**（https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules）的关注，我们着手测量 Google API 密钥的撤销窗口持续多久。 ### 什么是撤销窗口？ 撤销窗口是指从你删除密钥到最后一次成功身份验证之间的时间。 撤销窗口是密钥删除时间和最后一次被接受的请求之间的时间。如果这个窗口只有几微秒，行为就符合用户的预期。如果时间更长，那么每多一秒钟，攻击者就有更多时间滥用被盗的密钥。 ## 测量撤销窗口 为了测量 Google API 密钥的撤销窗口，我们在两天内进行了 10 次试验。 每次试验中，我们创建一个 API 密钥，将其删除，然后以每秒 3-5 次经过身份验证的请求频率发送请求，直到连续几分钟没有收到有效响应为止。 我们选择这个速率是因为我们无法控制 Google 如何将我们的请求路由到全球不同的身份验证服务器。这个请求量旨在尽可能多地遍历这些服务器（在每个试验中），同时仍尊重 Google 的基础设施。我们无法确定更高的请求速率是否会延长观测到的窗口。攻击者没有理由像我们一样限制速率，因此值得注意，我们的数字可能不代表最坏情况。 为了完整性，几周后我们又进行了一次抽查，以确保我们观察到的行为不是由瞬态网络问题引起的。 ### 23 分钟 在十次试验中，**最长的窗口接近 23 分钟**！对于已删除的密钥仍然能够成功进行身份验证来说，这简直长得不可思议。 最短的窗口约为 8 分钟，中位数约为 16 分钟。在每次试验中，成功率高度不可预测：删除后一分钟，一次试验中 79% 的请求成功，而另一次试验中只有 5%。 该图表绘制了每次试验中每分钟成功通过身份验证的请求百分比。持有被盗密钥的攻击者看不到清晰的截止点或可预测的衰减。访问权限会不均匀地持续工作，直到最终突然停止。 ### 在 GCP 控制台中追踪单次试验 为了说明 Google 基础设施的不一致性，我们使用 GCP 中的“按凭据的流量”图表监控了其中一次试验。下方的（蓝色）线显示成功的身份验证，并反映了撤销窗口的长度。 该图表绘制了测试窗口期间每秒的请求数。上方的线显示无效的 API 请求，下方的线显示有效的请求。我们原本以为不会看到其他数据，但出现了第二条线。上方的（绿色）线显示被拒绝的请求，并标记为 `apikey:UNKNOWN`。我们（错误地）假设无效请求只会被丢弃而不附带任何项目归属信息。相反，GCP 将它们包含在该图表中。 为了更好地理解神秘的 `apikey:UNKNOWN` 值，我们尝试使用一个已删除数天的 API 密钥进行身份验证。令人惊讶的是，这些请求也出现在同一个图表中，并被归入相同的 `apikey:UNKNOWN` 组。 我们最好的猜测是，Google 会在密钥删除后保留项目归属信息，以防用户决定恢复该凭据。 GCP 中“恢复已删除凭据”按钮的截图 对于调查泄露凭据的 IR 团队来说，`apikey:UNKNOWN` 值可能会造成混淆。任何使用任何已删除的 Google API 密钥发出的请求都会被归入同一个 UNKNOWN 类别，这使得很难判断哪些请求与特定凭据相关。该存储桶中的请求可能意味着攻击者仍在尝试使用已删除的密钥进行身份验证，也可能是一个合法的服务正在使用一个不相关的过期密钥。 如果你处于 23 分钟的撤销窗口内，请查找使用泄露密钥的有效身份验证。如果你在该窗口之外，风险似乎极低。 ### 区域间的一致性问题 我们的第一次实验是从美国东海岸的一个住宅 IP 地址进行的。我们假设在不同 GCP 区域的虚拟机上运行类似的实验可能会暴露更多的不一致性。 我们在三个区域启动了虚拟机：`us-east1`、`europe-west1` 和 `asia-southeast1`。然后我们进行了 5 次试验。每次试验，我们删除一个 API 密钥，并从三个虚拟机并行发送请求。 有两件事很突出。首先，在密钥被删除后立即，不同区域的虚拟机看到的身份验证成功率差异很大。下表按区域列出了第一次测试分钟内有效请求的百分比。 该表格显示了所有 5 次试验中第一分钟内按区域划分的有效身份验证请求百分比。 看看第一次试验：`us-east1` 82%，`europe-west1` 60%，`asia-southeast1` 32%。距离美国更远的虚拟机更快地感知到删除，这与你的预期相反。我们无法从外部确切说明原因。Google 的请求路由比“虚拟机区域等于服务器区域”更复杂，新加坡的虚拟机不一定与新加坡的服务器通信。但该模式在多次试验中是一致的，这指向区域基础设施、缓存或路由亲和性的某种差异。 其次，区域差距不仅仅是第一分钟的事情。在整个窗口期间，`asia-southeast1` 的请求身份验证成功率的单位数为 22%，而 `us-east1` 和 `europe-west1` 均在 49% 左右。亚洲区域逐分钟都保持较低水平，而不仅仅是开始时。 无论是什么导致了这些差异，服务器的位置显然影响了已删除密钥在删除后的行为。 ### 其他 Google 凭据 我们的所有试验都使用了可访问 Gemini 的密钥，但我们观察到，对于范围限定为其他 GCP API（如 BigQuery 和 Maps）的密钥，行为相同。延迟是凭据类型的属性，而不是项目中启用的 API 的属性。 为了完整性，我们测试了另外两种 Google 凭据类型： - 新的 Gemini API 密钥（AQ. 前缀）。撤销传播大约需要 1 分钟。 - Google 服务账号密钥。撤销传播大约需要 5 秒。 两者都在 Google 规模下运行，并且撤销速度都比我们为 Google API 密钥测量的 23 分钟快得多。 ## 向 Google 披露 我们向 Google 报告了此问题。Google 关闭了该报告，标记为“不会修复”。据我们理解，团队的观点是传播延迟是系统的一个已知属性，而不是安全问题。 虽然 Google 公开记录其 **IAM API 是最终一致性**的（https://docs.cloud.google.com/iam/docs/overview#consistency），但他们并未特别针对 Google API 密钥记录此行为。 \[说明：Google IAM API 文档页面的截图。\] ## 用户期望的偏差 在 Google 规模下的分布式系统很难，这不是对 GCP IAM 团队的批评。但 23 分钟的撤销窗口与用户对删除按钮的期望严重不符。这种期望与 Google 行为之间的差距凸显了四个问题： 1. **用户界面极具误导性。** 当你删除密钥时，Google 将其从视图中移除，并告诉你“一旦删除，就不能再用于发出 API 请求。”这种说法显然不实。用户无法知道密钥是否仍然有效，无法加快撤销速度，也无法确认密钥何时完全失效。 Google 当前 API 密钥删除对话框的截图。它说一旦删除，密钥就不能再用于发出 API 请求。但你可以从已删除凭据页面恢复你的凭据。 2. **Google 为其他凭据类型构建了更快的撤销机制。** 服务账号凭据撤销传播大约需要 5 秒。Gemini 较新的 API 密钥格式传播大约需要 1 分钟。两者都在 Google 规模下运行。两者都表明，对于 Google API 密钥，这个问题在技术上也是可以解决的。 3. **长时间的一致性窗口与身份验证不兼容。** 当你删除一个凭据时，预期是该凭据死亡。即使是几秒钟的延迟也很重要，正如 Eduard 去年对 AWS 的研究所示。 4. **长撤销窗口破坏了即时（JIT）凭据的生成。** 想要动态生成 Google API 密钥的服务提供商必须在撤销后构建 23 分钟的缓冲时间，才能保证密钥完全失效。这与 JIT 应有的工作方式不兼容。 ## 应对窗口期 在 Google 提供更快的撤销之前，弥合这一差距的责任落在用户身上。以下两点有所帮助。 1. **将密钥删除视为一个 30 分钟的操作，而不是瞬间操作。** 如果你正在响应泄露的 Google API 密钥，请假设密钥在点击删除后的 30 分钟内仍然有效。这比我们观察到的最大 23 分钟多提供了一点缓冲。围绕这个窗口规划你的其余事件响应。 2. **在窗口期间监控使用情况。** 在 GCP 控制台的“已启用的 API 和服务”下，按凭据查看 API 请求。如果你在删除后发现该凭据有意外使用，可能有人正在积极利用它。 长时间的一致性窗口对于凭据撤销来说是一个错误的设计选择。在 Google 改变这一点之前，请将每次密钥删除视为一个 30 分钟的操作，并监控窗口期内的滥用行为。