一個 Roblox 外掛、一次 OAuth 授權,以及 Vercel 的 $2M 外洩事件
本週揭露的 Vercel 資安事件,始於一位 Context.ai 員工在個人電腦上下載 Roblox 外掛,並以攻擊者讀取 Vercel 客戶環境變數告終。本週推出的 Bromure 企業版,正是為這一整條攻擊鏈而設計。
一位員工在自己的個人筆電上搜尋 Roblox 外掛。兩個月後,攻擊者 在 BreachForums 上以 200 萬美元的價格兜售 Vercel 的客戶資料庫。 在這兩起事件之間,是一連串平凡的決定——一台個人機器、一次 OAuth 「全部允許」的點擊、一個使用 support@ 帳號的第三方 AI 工具—— 這些都是本週每一個企業 IT 團隊都應該盯著看的環節。我們 昨天推出的 Bromure 企業版,正是為這條鏈路的中段而生。
4 月 20 日,Vercel 公告 表示,一名「手法極為精密」的攻擊者透過一個受害的第三方 AI 工具 Context.ai 入侵了其內部系統,並存取了屬於部分客戶專案的非敏感環境 變數。執行長 Guillermo Rauch 形容 攻擊者「因 AI 而顯著加速」,並請客戶輪替所有被標示為非敏感的憑證。 一個自稱 ShinyHunters 的團體正試圖在 BreachForums 上以 $2M 兜售 竊得的資料。
贖金的數字是頭條,攻擊鏈才是教訓。 Hudson Rock 將感染源頭追溯到 2026 年 2 月,當時一位 Context.ai 員工搜尋 Roblox「自動掛機」腳本與遊戲外掛執行器,下載了其中一個, 並因此感染了 Lumma Stealer——一款會蒐集瀏覽器 cookie、儲存憑證 與 OAuth token 的商品化資訊竊取程式。 CyberScoop 與 SpecterOps 之後還原了其餘細節。Lumma 拿走的不只是 Context.ai 的密碼, 而是瀏覽器中快取的整組企業憑證——Google Workspace 工作階段、 Supabase 金鑰、Datadog 登入資訊、Authkit token。
攻擊者由此樞紐進入 Context.ai 的 AWS 環境,讀取 Context.ai 代其客戶 持有的 OAuth token,並找到一位 Vercel 員工——這位員工曾經用公司的 Google 帳號註冊 Context.ai 的「AI Office Suite」,並點選了「全部允許」 的權限勾選框。幾個月前的那一次同意,就是攻擊者唯一需要的起點。 他們以該員工身分鑄造出一個工作階段,走進了 Vercel 的 Google Workspace, 再由此進入 Vercel 內部的產品 API,列舉並解密了所有未被客戶明確標示為 敏感的環境變數。
這條鏈有四點值得特別點出,因為它們分別對應到我們本週在 Bromure 企業版中推出的具體控制項。我們不會宣稱這次發佈可以 完全阻止這起外洩——事實上不能。但它可以在四個不同的點上切斷 這條鏈,任何一點都已足夠。
個人筆電是承重點
公開報導中最被低估的細節是:受感染的機器是一台個人裝置。那位 Context.ai 員工正在搜尋 Roblox 外掛——不是典型的公司任務——而 這次感染,落在了一台很可能同時用於工作與個人瀏覽的機器上。 Lumma Stealer 不在乎某個 cookie 屬於哪個設定檔;它會讀取它能找到 的每一個 Chrome 與 Edge 憑證檔,然後把整包都送走。
這正是 BYOD 時代的核心模式。主機不受管理。工作 cookie 與使用者 剛剛下載的 Roblox 外掛共用同一個 cookie 罐。EDR 代理或許有裝, 也或許沒裝;在個人機器上,幾乎可以確定是沒裝的。而即便裝了, Lumma 也經常被觀察到 能繞過市售防毒軟體。
Bromure 企業版的解法,是在一台不受控的主機上提供一個受控的 VM。 IT 發放一個 Bromure 工作設定檔。員工在自己的個人筆電上安裝 Bromure,以企業 IdP(Google Workspace、Okta、Entra、Authentik) 登入,工作設定檔便以自己的 Linux 虛擬機啟動。該 VM 有自己的核心、 自己的檔案系統、自己的 Chromium 設定檔目錄。企業 cookie、企業 儲存的密碼、以及企業 OAuth 更新 token 都存在這個 VM 內。在主機 macOS 或 Windows 上執行的竊取程式——不論是透過 Roblox 下載或其他 方式被蒐集——都無法列舉、讀取或外洩它們。磁碟上不存在一個可被 竊取的共用 Chrome 設定檔。cookie 罐位於一個 VM 映像檔內,主機 作業系統只會把它看成一個不透明的磁碟檔案。
這不是理論上的分離,而是整個架構的核心要點。主機愛被打爆就打爆; 工作瀏覽器在另一台電腦裡。
「全部允許」那一次點擊,才是真正的戰利品
仔細看攻擊者的路徑。竊取程式蒐集了 Google Workspace、Supabase、 Datadog、Authkit 的憑證。這些對於在 Context.ai 內部橫向移動確實 有用。但真正觸及到 Vercel 的,不是被偷走的密碼——而是一個 OAuth token。具體來說,是某位 Vercel 員工在註冊 Context.ai 的 AI Office Suite、一路點過 Google 同意畫面、並核可「全部允許」權限組時鑄造 出的那個 token。這次同意是幾個月前發生的事。它從未被重新評估過。 它就靜靜地、有效地在那裡等著。
這就是 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 VM 之外下載的 Roblox 外掛,依然是一個會在使用者個人作業系統上安裝資訊竊取程式 的 Roblox 外掛。Bromure 不會幫你清理那些。它做的事,是確保這個 惡意程式為攻擊者帶來的收穫,只剩使用者的個人 cookie——而不是 企業的。
它無法追溯撤銷 OAuth 權限。 公司導入 Bromure 企業版之前就已發出 的同意,仍在 Google Workspace 的授權清單裡,不在我們這邊。部署 Bromure 之後,正確的營運動作仍然是審計現有的第三方應用授權—— 我們幫你預防下一次,但不幫你改寫上一次。
它無法取代權限範圍把關的紀律。 那位 Vercel 員工點了「全部 允許」。如果未來有員工在一個已核可的磚貼上點了「全部允許」, 那筆授權仍然會是廣泛的。Bromure 讓這個表面變得可見、讓註冊 路徑變得更窄;它無法取代管理員決定某類應用該被允許哪些 Google 權限範圍。
瀏覽器優先的論點不是「沒有攻擊會發生」。它是:對所有會經過使用者 瀏覽器工作階段的攻擊類別而言,槓桿最大的控制點就是瀏覽器本身—— 而瀏覽器,偏偏是企業軟體裡唯一一塊,在不受控裝置上從來沒有 真正好好被管起來過的。
修正的樣貌
透過 SaaS OAuth 授權達成的供應鏈入侵,就是十年前 VPN 憑證填充攻擊 的現代版。兩者都是這樣產生的:建立一條信任邊緣很便宜,盤點它 很難,而當對手被打爆時,要及時撤銷它幾乎不可能。Vercel 的公告 既謹慎又坦誠;它描述的這條鏈,不是 Vercel 的錯。當同一台個人筆電 上的同一個瀏覽器,同時裝著員工的企業工作階段、他下載 Roblox 的 歷史紀錄,以及上個季度他拿各種 AI 工具實驗所累積下來的每一次 「全部允許」同意——事情就會變成這樣。
結構性的答案,是讓工作工作階段擁有自己的電腦。不是第二台筆電—— 是在同一台筆電上具現化的第二台機器,擁有自己的核心、自己的檔案 系統、自己的 cookie 罐、自己的策略引擎,以及接入中央日誌的稽核 截取。這就是 Bromure 企業版。如果你在一家員工會 時常把 OAuth 權限授予第三方 SaaS 應用的公司裡負責 IT——也就是 說,任何公司——這週的 Vercel 公告,就是把它放進候選清單的理由。
主要來源