SalesBleed：三個 Agentforce 漏洞讓陌生人零點擊抽走你的 CRM 資料

9 月 24 日，Zenity Labs 的安全研究人員揭開了 SalesBleed 的面紗——Salesforce Agentforce 平台上一組（共三個）現已修補的漏洞。這條攻擊鏈迄今最清楚地展示了 AI 代理如何改變入侵的經濟學：頭號漏洞允許攻擊者竊取 CRM 資料——客戶名稱、交易金額、管道細節——不必登入、不必碰觸目標租戶、也不需要任何受害者點擊任何東西。第二個漏洞則把 Agentforce 變成 Slack 裡無法追溯的釣魚發射器。Salesforce 已於 8 月 19 日前修補全部三個漏洞，且未指派任何 CVE 編號。但這條攻擊鏈值得仔細研究，因為它絕不會是最後一個同類案例。

一張表單作為入侵起點

攻擊從一個幾乎沒人監控的地方開始：Salesforce 的 Web-to-Lead 表單。這是公開、刻意免鑑別的端點，讓潛在客戶從公司網站提交銷售線索。網際網路上的任何人都能提交一筆。

攻擊者提交一筆看起來完全正常的線索——但在某個欄位裡嵌入隱藏指令。這筆帶毒記錄靜靜躺在組織的 Leads 資料表中，與日常進線的商機無異。什麼都不會發生。而且可以好幾天都不需要發生。

引信在員工做出完全正常的舉動時引爆：向 Agentforce 問一個例行問題，例如「幫我看一下最新的線索」。代理盡責地擷取那筆帶毒記錄——然後遵循其中的指令，而不是員工的本意。這就是間接提示注入（indirect prompt injection），而且不是經由聊天訊息傳遞，是藏在業務資料本身裡。

完全不需要提權

有一個細節值得每個安全團隊倒吸一口涼氣：這個攻擊完全不需要任何權限提升。Agentforce 的 General CRM 子代理本來就透過內建的 Query Records 能力，同時擁有 Lead 與 Account 記錄的合法存取權。注入的指令只是引導它使用自己已有的權限——從 Account 拉出公司名稱與交易金額——再把結果整理到一個能離開大樓的地方。

外洩通道設計得相當優雅。代理的回應包含一個 HTML 圖片標籤，指向攻擊者控制的主機名稱，竊取的 CRM 資料被編碼進該主機名稱的子網域裡。當 Agentforce 客戶端渲染回應時，瀏覽器會嘗試解析這個主機名稱——而每一次 DNS 解析請求都會送到該網域的權威伺服器，也就是攻擅者手裡。資料在任何 HTTP 連線完成之前就已送達。沒有檔案傳輸、沒有對外 API 呼叫，只有一個大多數環境從不檢查的 DNS 查詢。

這就是它「零點擊」的原因。員工只是問了一個關於線索的普通問題。他們沒有開啟附件、沒有點連結、沒有核准任何動作。竊資是「照說明書使用產品」的副作用。

繞過 Trusted URLs 白名單

Salesforce 原本有一個專門為此設計的防護機制。Trusted URLs 是一種白名單機制，用來防止代理產生或呈現未核可的外部連結——代理回應中未核可的 URL 理論上會被替換成 URL_Redacted。

Zenity 發現，這個過濾層的正規表示式 URL 識別邏輯，與下游渲染元件對「什麼算一個 URL」的認知不一致。某些頂級網域和某些特殊字元，過濾器與最終渲染輸出的表面會用不同方式解析。一個精心構造的畸形字串——例如一個不帶過濾器預期之括號標記的子網域——可以躲過過濾，卻仍被當成可擷取的 URL 放進圖片來源。Salesforce 事後已用符合標準的 URL 解析器取代正規表示式做法，封住了這個繞過。

第二個漏洞：透過 Slack 的匿名釣魚

SalesBleed 的第二幕從竊資轉向身分濫用。Agentforce 代理可以直接發佈到 Slack 裡，讓員工在既有工具中與之互動。Zenity 檢視了 Slack 端子代理的動作後發現：多數動作行為良好——會要求使用者確認、會在訊息上標註觸發者——但繼承自預設子代理模板的 Send a Slack Direct Message 動作，兩者都沒有。

後果會層層放大。外部攻擊者可以把指令植入帶毒的 CRM 線索（與前述同一個進入點）；當員工稍後向代理求助時，代理遵循注入的指令，把釣魚訊息貼進活躍的 Slack 討論串——以代理自己受信任的身分發出，沒有確認檢查點，也沒有任何歸屬標示說明是誰或什麼東西發起的。Zenity 還發現釣魚連結可以躲過 URL 過濾層，並藏在無害的 markdown 連結文字背後，讓它在代理的訊息裡看起來正當可信。

投放情境讓這種釣魚異常有效。討論串裡的回覆自帶對話的既有信任——員工正在討論某個客戶，他們信賴的代理突然插話給出一個看起來相關的連結。The Register 引述 Zenity 的警告：這些漏洞「導致非常出乎意料的後果」；Dark Reading 則點出更廣的教訓：代理式 AI 可以把任意指令從公開網路、跨多個應用程式，走私進受信任的內部溝通管道。

漏洞組裡的第三個則是濫用 Slack 連結預覽，透過同一條渲染管線自動外洩資料。Salesforce 已修補全部三個。

一場做對了的漏洞揭露

這裡的時間軸是協調揭露的模範。Zenity 將發現回報給 Salesforce，後者展開調查、修補 Trusted URLs 繞過、強化 Slack 動作預設值（加上確認與歸屬機制），並在 8 月確認修復——比本週的公開揭露早了大約一個月。Zenity 公開肯定 Salesforce 的協作態度。未指派 CVE 的原因之一，在於這些漏洞存在於產品設定預設值與多層行為的組合，而非單一記憶體損壞缺陷。

是模式，不是單一 bug

個別漏洞已經修好。它們暴露的模式沒有，而且適用範圍遠超過 Salesforce：

三種成分構成一台外洩引擎：攻擊者可控制的內容、對內部敏感資料的存取權、以及任何能把生成輸出送往外部的通道。Agentforce 恰好在一個產品裡湊齊三者，但任何接上 CRM、工單系統或聊天平台的企業代理，都是同樣的形狀。

免鑑別的進料口就是提示注入面。線索表單、客服信箱、公開留言——世界上任何人能寫入、而你的代理稍後會讀取的東西，實質上就是一個 prompt。組織應把外部提交的 CRM 欄位視為不可信的指令，而不是可信的業務內容。

最小權限是唯一真正的保險。SalesBleed 不需要任何提權漏洞，因為代理的權限是為了方便而設定，不是為了圍堵。把代理限制在最少必要的 CRM 物件——並稽核 Query Records 實際能碰到的範圍——能把全面虹吸變成窄口滴漏。

外洩會找上最安靜的通道。DNS 查詢、圖片擷取、連結預覽：現代應用程式的對外表面又大又很少被端對端記錄。過濾層有幫助，但正如 Trusted URLs 繞過所示，任何必須在每個渲染情境中完美辨識「什麼是 URL」的過濾器，距離失效只差一個邊界情況。

Salesforce 這次的回應快速而徹底，值得肯定。下一家廠商未必。真正把 SalesBleed 的教訓內化的組織——在代理式系統裡，讀取資料與執行指令已成為同一個操作——才會是 CRM 不會流血的那些。