一个 Roblox 作弊器、一次 OAuth 授权,以及 Vercel 的 200 万美元泄漏
本周披露的 Vercel 入侵事件,始于 Context.ai 的一名员工在个人电脑上下载 Roblox 作弊器,终于攻击者读取到 Vercel 客户的环境变量。本周发布的 Bromure 企业版,正是为这种攻击链而生。
一名员工在自己的个人笔记本上搜索 Roblox 作弊器。两个月后,一名攻击者在 BreachForums 上以 200 万美元出售 Vercel 的客户数据库。在这两件事之间,是一连串再普通不过的决定——一台私人设备、一次 OAuth「全部允许」的点击、一个使用 support@ 账号的第三方 AI 工具——每一个企业 IT 团队本周都应该盯着这条链看。我们昨天发布的 Bromure 企业版,正是为这条链的中段而设计的。
4 月 20 日,Vercel 披露,一名「高度成熟」的攻击者通过一个名为 Context.ai 的被攻陷第三方 AI 工具入侵了其内部系统,并访问了部分客户项目中被标记为「非敏感」的环境变量。CEO Guillermo Rauch 表示,攻击者「因 AI 而显著加速」,并要求客户轮换所有被标记为非敏感的凭据。一个自称 ShinyHunters 的团伙目前正试图在 BreachForums 上以 $2M 的价格出售被盗数据。
赎金数字是头条,攻击链才是教训。Hudson Rock 把感染追溯到 2026 年 2 月——当时 Context.ai 的一名员工搜索 Roblox 的「自动刷分」脚本和游戏漏洞利用器,下载了其中一个,结果染上了 Lumma Stealer——一款大宗商品化的窃密木马,会收割浏览器 cookie、已保存凭据以及 OAuth 令牌。CyberScoop 和 SpecterOps 随后还原了故事的其余部分。Lumma 偷走的不只是一个 Context.ai 的密码;而是缓存在浏览器中的整套企业凭据——Google Workspace 会话、Supabase 密钥、Datadog 登录态、Authkit 令牌。
由此,攻击者横向进入了 Context.ai 的 AWS 环境,读取了 Context.ai 代其客户持有的 OAuth 令牌,找到一名曾经用企业 Google 账号注册 Context.ai 的「AI Office Suite」并勾选了「全部允许」的 Vercel 员工。几个月前这一次同意,就是攻击者所需的唯一原语。他们以该员工身份铸造了一个会话,走进了 Vercel 的 Google Workspace,再从那里进入 Vercel 的内部产品 API,在其中枚举并解密了每一个客户未明确标记为敏感的环境变量。
关于这条链,有四点值得单独拎出来,因为每一点都对应到我们本周在 Bromure 企业版中发布的一项具体控制。我们不会宣称这次发布能完全阻止此次入侵——它做不到。它能做的,是在四个不同的环节各自切断这条链,而任何一点上的切断都已经足够。
个人笔记本是承重梁
公开的事后复盘里最被低估的一个细节是:被感染的那台机器是一台私人设备。那位 Context.ai 员工在搜索 Roblox 漏洞利用——这显然不是典型的工作任务——而感染就落在一台可能同时用于工作和个人浏览的机器上。Lumma Stealer 才不管一个 cookie 属于哪个配置文件;它读取它能找到的每一个 Chrome 和 Edge 凭据文件,然后一股脑发走。
这就是 BYOD 时代的核心模式。宿主是不受控的。工作 cookie 和用户刚刚下载的 Roblox 作弊器躺在同一个 cookie 罐子里。EDR 代理可能装也可能没装;在一台个人机器上,几乎肯定没装。而即便装了,Lumma 也经常被观察到能绕过现成的杀毒软件。
Bromure 企业版的答案是:在不受控的宿主上运行一台受控的虚拟机。IT 下发一个 Bromure 工作配置文件。员工在自己的个人笔记本上安装 Bromure,用企业 IdP(Google Workspace、Okta、Entra、Authentik)登录,工作配置文件就作为一个独立的 Linux 虚拟机启动。那台虚拟机有它自己的内核、自己的文件系统、自己的 Chromium 配置目录。企业 cookie、企业保存的密码以及企业 OAuth 刷新令牌都住在这台虚拟机里。运行在宿主 macOS 或 Windows 上的窃密木马——不管是通过 Roblox 下载还是别的什么方式植入的——都无法枚举、读取或外传它们。磁盘上根本没有一份可供其窃取的共享 Chrome 配置。cookie 罐子位于一个虚拟机镜像内部,而宿主操作系统把这个镜像当成一个不透明的磁盘文件。
这不是理论上的隔离,它就是这套架构的全部要点。宿主尽可以整天被攻陷;工作浏览器在另一台电脑里。
「全部允许」那一下点击才是真正的战利品
仔细看攻击者的路径。窃密木马收割了 Google Workspace、Supabase、Datadog、Authkit 的凭据。这些在 Context.ai 内部横向移动时非常有用。但真正够到 Vercel 的,并不是一个被盗的密码——而是一个 OAuth 令牌。具体来说,是某位 Vercel 员工注册 Context.ai 的 AI Office Suite、点过 Google 同意界面、勾选「全部允许」那一揽子权限时铸造的令牌。那次同意已经过去了几个月。没人再去重新审视。它就这样一直有效地待在那里等着。
这正是 SpecterOps 指出的 OAuth 可见性缺口:员工个人点击同意界面所创建的信任边,完全游离于 IT 的开通流程之外。这条路径在任何人想到要去找它之前就已经敞开。
Bromure 企业版从两个方向同时收窄了这个面。
已授权 SaaS 磁贴清单,是入口处的咽喉要道。 管理员把已批准的工作应用集合发布到每位入职用户的工作主页。那些磁贴就是员工用于入职新工具的入口。Context.ai 不在 Vercel 的这份清单上——它本来就不可能在,它是某位员工的个人试水。没有磁贴,在托管的工作配置文件里就没有一键注册流程。当然,员工仍可以手动导航到 Context.ai;这时候第二道控制就接上了。
工作配置文件受 SSO 管控,其同意面对管理员可见。 从受管的 Bromure 工作配置文件发起的 OAuth 同意,都经过企业 IdP,受管理员策略约束。若某管理员想彻底管控哪些第三方应用可以接收 Google Workspace 权限——这是每位 Google Workspace 管理员都应该做的,但几乎没人真在做——他的强制执行点就在 Bromure 策略引擎里,而不是散落在几周前每个员工各自点过的页面。「全部允许」那个复选框不再会在十八个月后、某次应急响应中才冷不丁地冒出来。
这些都不能追溯性地撤销员工迁移到 Bromure 之前已经签发的 OAuth 授权。但从现在往后,「员工把广泛的 Google 权限授给了一个我从没听说过的 SaaS 应用」这类情况,会是可见、可管控的。
事后,审计日志是界定损失范围的唯一办法
Vercel 在公开公告里很坦诚地承认:调查发现攻击者枚举并解密了一部分客户项目的环境变量,范围仍在细化。之所以还在细化,是因为要从 Google Workspace 审计日志加上 Vercel 内部产品日志里,还原出「从 3 月底到 4 月中,那个员工账号究竟读了什么」,这是一个取证重建项目,不是一次查询。
这正是 Bromure 企业版的逐请求审计日志要填的缺口。每一台已入队设备、每一次工作会话发出的每一个 HTTP 请求,都会被集中记录:用户、URL、动作、时间戳。我们在发布会上用过的例子是:「昨天早上 8:00 到 8:15 之间是谁向 evil.com 发送了凭据?」本周更贴切的例子是:「过去九十天里,我们 Vercel 产品 API 的每一个环境变量端点,分别是谁、从哪里、在何时命中的?」是一次查询,不是一个项目。
这就是 EDR 遇上网页审计日志的那部分。EDR 对原生进程回答同样的问题:这个进程都碰了什么?Bromure 对浏览行为回答这个问题:这位用户的浏览器都碰了什么?在像 Vercel 这样的事件中,攻击者的足迹完全留在一个被攻陷的浏览器会话里,EDR 的答案是一片空白,而 Bromure 的答案就是事件时间线本身。
在这里,数据外泄控制的适用面较窄——这点必须坦诚
我们想谨慎地说明 Bromure 企业版在哪里有用、在哪里没用。复制粘贴、文件下载、截屏和本地网络控制都是真实存在的,它们对数据外泄整体而言也确实是实打实的胜利——受管配置文件里一个被攻陷的标签页,无法把客户环境变量拖进宿主上的 scp,无法截屏,也无法上传到 LAN 的其他主机。但就 Vercel 这条链具体而言,外泄这一步完全是通过网络从 Vercel 自己的后端发往攻击者控制的端点完成的。攻击者发起的是已认证的 API 调用,而不是从浏览器窗口里往外拖文件。粘贴/下载/LAN 控制是抓不住这种情况的。
能起作用的是上文提到的、对这些 API 调用本身的记录。数据外泄控制是第二道防线;第一道防线,是确保攻击一开始就没法在一个受管浏览器里铸造出一个会话。
Bromure 企业版做不到的事
有三个诚实的边界,这个故事配得上说清楚。
它无法阻止一台不受控的私人宿主被恶意软件感染。 一个在 Bromure 虚拟机之外下载的 Roblox 作弊器,仍是一个会在用户私人操作系统上安装窃密木马的 Roblox 作弊器。Bromure 不会去清理它。它做到的,是让这份恶意软件对攻击者产生的收益,仅限于用户的个人 cookie——不包括他的企业 cookie。
它不会追溯性地撤销 OAuth 权限。 在公司推行 Bromure 企业版之前几个月签发的同意,位于 Google Workspace 的授权列表里,而不是我们的。部署 Bromure 之后,正确的运营动作仍然是对已有第三方应用授权做一次审计——我们帮你防住下一次,但不会重写上一次。
它不能替代权限范围的基本纪律。 那位 Vercel 员工点了「全部允许」。如果未来某位员工在一个已批准的磁贴上点「全部允许」,授权仍然是宽的。Bromure 让这个面可见、让入职路径变窄;它不能替代管理员去决定某一类应用允许或不允许哪些 Google 权限范围。
以浏览器为先的主张,并不是「没有攻击会发生」。而是:对于所有经过用户浏览器会话的那一大类攻击而言,杠杆率最高的控制点,就是浏览器本身——而浏览器恰好是企业软件里,唯一一件在不受控设备上从未有过像样管理方案的东西。
修复的形状
通过 SaaS OAuth 授权发生的供应链入侵,是十年前 VPN 凭据撞库攻击的现代对应物。两者都源自同一种信任边——易于建立,难以盘点,当对方被攻陷时也无法及时撤销。Vercel 的公告谨慎而坦诚;它描述的那条链并不是 Vercel 的错。那是当「同一台个人笔记本上的同一个浏览器」同时装着员工的企业会话、他的 Roblox 下载记录、以及他上个季度试用过的每个 AI 工具累积下来的「全部允许」同意时,必然会发生的事。
结构性的答案,是给工作会话一台它自己的电脑。不是第二台笔记本——而是第二台机器,在同一台笔记本上被物化出来,有自己的内核、自己的文件系统、自己的 cookie 罐、自己的策略引擎,以及自己通往中央日志的审计接入点。这就是 Bromure 企业版。如果你在一家员工会经常把 OAuth 权限授给第三方 SaaS 应用的公司里做 IT——也就是说,任何一家公司——本周 Vercel 的公告,就是把它列入候选名单的理由。
原始来源