本週稍早，研究人員揭露了一項攻擊，利用 Microsoft 365 Copilot 企業版提供的秘密輸入，導致該 AI 助理外洩用戶收件匣中的密碼。現在，另一個團隊也針對 Grok 設計了類似的攻擊。這項新的資料竊取手法運用一個看似簡單的技巧，強迫 Elon Musk 旗下的大型語言模型竊取用戶的聊天紀錄及其他個人資訊。截至本文發布時，儘管 xAI 已於六月接獲通知，該助理仍持續洩露資料。
從本週這兩起事件，以及之前無數的案例中，我們學到一個教訓：大型語言模型無法解決提示詞注入（它們最容易受到攻擊的嚴重漏洞類別）的根本原因。這使得 AI 開發者別無選擇，只能建立安全防護機制，引導模型遠離有害行為。正如我在週二報導中指出的，這種做法無異於道路交通安全工程師在危險彎道周圍架設護欄，而非改善彎道設計本身。
「加密上下文注入」登場
提示詞注入利用大型語言模型盡可能遵守用戶請求的訓練特性。攻擊者可以利用這種傾向，將有害指令偷偷塞入助理被指示摘要的電子郵件或網頁中。由於大型語言模型無法可靠地區分來自不受信任方的電子郵件內容與直接輸入提示詞的用戶指令，過於殷勤的模型會忠實地遵循這些指令。迄今為止，Grok 和其他大型語言模型唯一的補救措施是建立安全防護機制，標記可疑指令並禁止其執行。
資安公司 Adversa 的研究員 Rony Utevsky 最近發現了一種完全繞過這項限制的簡單方法。駭客不是以明文撰寫有害指令，而是將其加密。託管密文的網站同時包含解密加密內容的明文指令，以及解密金鑰。透過這個簡單的序列，一旦用戶指示助理摘要該頁面，Grok 便會立即遵循指令。過程中沒有任何警告，也無需確認。
解密後的指令會引導大型語言模型建構一個據稱是解密金鑰的內容。但實際上，這完全是另一回事。這個假金鑰的值其實是用戶的姓名、位置和聊天紀錄。該值隨後被用作參數，添加到一個導向攻擊者網站的 URL 中。一旦 Grok 打開該連結，這些資料就會記錄在攻擊者的伺服器日誌中。
Adversa 無法確定是什麼原因導致 Grok 拒絕完全相同的明文指令，卻遵循加密指令。主要的理論是 Grok 的過濾防護機制會檢查進出模型的文字，但不會檢查其自身程式碼執行的輸出。處理密文的 PBKDF2 和 AES-256-GCM 指令會作為普通請求通過過濾器，因為分類器可以讀取它們，但無法解析它們解鎖的內容。
一旦額外指令被解密，它們就會作為模型自身的工具輸出到達模型，而模型會直接執行它們，而過濾防護機制從未檢查過。
Utevsky 週四寫道：「靜態安全防護機制將輸入分類為文字；它們不會執行程式碼。」「攻擊者將密文連同金鑰材料和解密指令一起發送，模型在其自身的程式碼執行沙盒內運行該解密。防護機制的掃描器所需的一切都在頁面上，但要恢復明文意味著運行 PBKDF2 和 AES-256-GCM，而任何內容分類器在檢查時都不會執行這些操作。」
研究員在一封電子郵件中表示，這類防護機制之所以稱為靜態，「是因為它們只將內容讀取為文字。它們不運行程式碼或解密任何東西。這就是我們利用的漏洞。真正的指令是加密的，所以防護機制只看到無意義的密文並讓其通過。」
Adversa 在一次 Gemini 越獄攻擊中使用了類似的技術，這意味著讓 Google 的大型語言模型忽略其內部安全規則。在這裡，密文被解密為看似追蹤錯誤的內容。解密後的文字發出了一條規則，如果程式碼失敗，請閱讀錯誤訊息並根據其行動。明文注入了一個提示詞，最終導致 Gemini 違反其安全規則。
Adversa 表示：「該技術產生了一個多段落的受限內容範例，這些內容通常會被 Gemini 的安全過濾器抑制（例如製造燃燒武器）。」「透過修改後的酬載，相同的向量重現了 Gemini 的系統指令，包括禁止洩露這些指令的指示。」
Adversa 沒有向 Google 報告此行為，因為越獄不在該公司漏洞披露計畫的範圍內。然而，在過去幾週，Gemini 對此類攻擊的抵抗力越來越強。該資安公司表示：「我們無法歸因於具體變化，可能是過濾器更新、模型版本變更，或兩者兼有。」該公司研究人員將這項技術稱為「加密上下文注入」。
Adversa 表示：「加密上下文注入是更廣泛轉變的一個實例：攻擊不僅操縱提示詞，還操縱大型語言模型視為其自身的更廣泛上下文，例如工具輸出、運行時結果和中間狀態。」「這個攻擊面遠大於傳統上標記為『模型輸入』的範圍，下一代攻擊將會從這裡出現。」
加密上下文注入只是大型語言模型防禦者所處劣勢的最新例證。每當他們建立一個新的、一次性的安全防護機制時，攻擊者就會找到一個新的向量，讓汽車再次衝出道路。這個循環不斷重複：洗牌、沖洗、重複。
