Synth Daily

Vercel泄露事件：OAuth攻击暴露平台环境变量风险

由于第三方 OAuth 应用被攻破，攻击者得以长期访问 Vercel 的内部系统，并窃取了大量未被明确标记为“敏感”的客户环境变量，导致敏感凭证大规模泄露。此次事件暴露了 OAuth 信任关系中固有的安全风险，以及 Vercel 平台默认将环境变量视为非敏感的设计缺陷。长达 22 个月的攻击潜伏期和长达 9 天的披露延迟，也凸显了平台在安全监控和响应方面的不足。最终结论是，企业必须从架构上改变防御策略，将 OAuth 应用视为第三方供应商，消除长期凭证，并假设平台本身可能被攻破来设计安全体系。

事件揭示的核心问题

此次事件的严重性不在于攻击手法的复杂，而在于它揭示了三个普遍存在的深层问题：

  • OAuth 的放大效应: 一个单一的 OAuth 信任关系，演变成了一场波及全平台的安全事件，影响了许多与被黑供应商没有直接关系的下游客户。
  • AI 加速的攻击: Vercel 的 CEO 公开表示，攻击者的行动速度异常之快，很可能是得到了 AI 的辅助。这是关于 AI 增强网络攻击能力的一个早期且引人注目的实例。
  • 从发现到披露的延迟: 有公开报告显示，在 Vercel 正式披露事件的九天前，已有客户凭证在野外被标记为泄露。这引发了对平台在发现漏洞后通知用户速度的质疑。

攻击时间线

攻击从最初的 OAuth 应用被黑到 Vercel 公开披露，持续了大约 22 个月。如此长的潜伏时间在利用合法应用权限的 OAuth 攻击中并不少见，因为这类行为很难触发传统的安全警报。

  • 约 2024 年 6 月: 第三方应用 Context.ai 的 Google Workspace OAuth 应用被攻破。
  • 2024 年 6 月 - 2025 年: 攻击者通过被盗的 OAuth 令牌维持持久访问。
  • 2024 年末 - 2025 年初: 攻击者从 Context.ai 的访问权限横向移动到一名 Vercel 员工的 Google Workspace 账户。
  • 2025 年初 - 中期: 攻击者访问 Vercel 内部系统，开始窃取客户的环境变量。
  • 2026 年 4 月 10 日: OpenAI 通知一名 Vercel 客户其 API 密钥发生泄露（根据客户在社交媒体上的说法）。
  • 2026 年 4 月 19 日: Vercel 发布安全公告，其 CEO 确认攻击并点名 Context.ai。

一个关键问题是，许多 Google Workspace 订阅套餐的 OAuth 审计日志默认只保留六个月，这意味着在调查开始时，关于最初入侵的取证数据可能已经丢失。

攻击链分析

攻击利用了现代软件服务环境中普遍存在的信任链：公司员工授权第三方 OAuth 应用访问其企业账户。

  1. 第三方 OAuth 应用被黑: 攻击者首先攻破了 Context.ai 的 Google Workspace OAuth 应用。这些应用一旦被授权，其令牌通常拥有长期有效的访问权限，并且即使用户更改密码也依然有效。
  2. 企业账户被接管: 利用被盗的 OAuth 令牌，攻击者侵入了一名 Vercel 员工的 Google Workspace 账户，从而获得了访问邮件、内部文档和日历的权限。
  3. 访问内部系统: 从被攻破的员工账户出发，攻击者进一步渗透到 Vercel 的内部系统。
  4. 窃取环境变量: 攻击者在内部系统中获得了足够的权限，可以读取客户项目的环境变量。
  5. 下游服务的潜在利用: 泄露的环境变量中包含了访问数据库、支付网关和云服务提供商的凭证。有公开报告称，在 Vercel 披露事件前，已有客户的 OpenAI API 密钥被发现泄露，这表明攻击者已经开始利用这些凭证。

Vercel 的环境变量设计问题

这次攻击造成巨大影响的根本原因，是 Vercel 在环境变量处理上的设计缺陷。

任何需要用户为每一个秘密信息都进行“手动选择加入”才能获得保护的安全控制，在实践中的采用率必然很低。

Vercel 的环境变量有一个“敏感”标志，但这个标志 默认是关闭的。这意味着，开发者添加的任何数据库连接字符串、API 密钥或其他凭证，如果没有被手动标记为“敏感”，就会以非加密的方式存储，并且可以被拥有内部访问权限的攻击者读取。

  • 默认（非敏感）变量:
    • 在仪表盘中可见。
    • 可通过内部 API 访问。
    • 在此次攻击中被攻击者获取。
  • 敏感变量:
    • 必须手动开启。
    • 创建后被隐藏。
    • 访问受限，在此次攻击中似乎未被泄露。

虽然 Vercel 在事后改进了界面，但并未改变“默认不安全”的设定。行业最佳实践是使用专门的密钥管理服务（如 Vault 或 AWS Secrets Manager），而不是依赖于环境变量的敏感标记。

凭证泄露的连锁反应

一个平台的漏洞会像多米诺骨牌一样，波及所有依赖该平台存储凭证的下游服务。这种现象被称为“凭证扇出”（Credential Fan-Out）。

Vercel 项目中常见的环境变量及其潜在影响包括：

  • 数据库 (DATABASE_URL): 导致完整数据访问权限。
  • 云服务 (AWS_SECRET_ACCESS_KEY): 导致云账户被接管。
  • 支付 (STRIPE_SECRET_KEY): 导致金融数据泄露和欺诈风险。
  • 认证 (NEXTAUTH_SECRET): 导致会话伪造和账户接管。
  • AI 服务 (OPENAI_API_KEY): 导致 API 滥用和产生高额费用。

一个拥有 50 个项目的中型组织，可能在 Vercel 上存储了 500 到 1500 个凭证。每一个凭证都是通往另一个系统的入口。

防御建议

立即采取的行动

  • 轮换所有凭证: 立即轮换所有存储在 Vercel 中且未标记为“敏感”的环境变量。
  • 重新部署: 凭证轮换后，必须重新部署所有使用这些变量的应用。旧的部署版本仍然会使用旧的凭证。
  • 启用敏感标记: 审计所有项目，为所有包含凭证的环境变量启用“敏感”标志。
  • 审计 OAuth 应用: 在你的 Google Workspace 或 Microsoft Entra 管理后台，审查所有已授权的 OAuth 应用，撤销不再使用的应用。

短期加固措施

  • 迁移到专用密钥管理器: 将所有密钥迁移到如 HashiCorp Vault、AWS Secrets Manager 或 Doppler 等专用服务中，在运行时注入密钥，而不是将其存储为环境变量。
  • 消除长期凭证: 尽可能使用 OIDC 等短生命周期的认证机制。
  • 监控 OAuth 应用: 部署专门的工具来监控 OAuth 应用的授权和使用情况。

长期架构变革

  • 采纳零信任姿态: 假设任何存储在部署平台上的秘密信息都可能被泄露。设计系统时要确保单个凭证的泄露不会引发连锁反应。
  • 实施最小权限原则: 确保所有凭证的权限都被限制在绝对必要的范围内。
  • 将 PaaS 平台视为供应链依赖: 将 Vercel 这类部署平台纳入你的软件物料清单（SBOM）和供应商风险管理中，将其视为一级供应链依赖。

结论

Vercel 的泄露事件并非孤例，它是一系列针对软件供应链攻击的最新一例，与近期的 LiteLLM 和 Axios 事件共同揭示了一个趋势：攻击者的目标高度统一，即开发者存储在各种工具链中的凭证。

防御的关键不再是仅仅加固边界，而是要从根本上改变架构和思维模式：

  • 停止 在平台环境变量中存储长期有效的凭证。
  • 停止 盲目信任 OAuth 应用。
  • 停止 假设你的平台供应商是绝对安全的。
  • 开始 将凭证轮换和重新部署作为常态。
  • 开始 将来自第三方的凭证泄露警告视为高优先级的早期预警信号。

最终，能够在下一次平台级漏洞中幸存下来的组织，将是那些早已预料到这种情况并为此做好了架构准备的组织。

攻击指标 (IoC)

  • 类型: OAuth 客户端 ID
  • 值: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
  • 描述: 已确认被攻破的 Context.ai OAuth 应用程序的 ID。