自從 CRIME、BREACH、TIME、LUCKY-13 等發現以來，基於長度的旁路攻擊被認為是可行的。即使已對封包加密，攻擊者仍能夠透過分析封包長度或時間資訊等中繼資料，來推斷有關內在純文字的資訊。
本·古里安大學的一組研究人員最近聯絡了 Cloudflare，他們撰寫了一篇題為「What Was Your Prompt? A Remote Keylogging Attack on AI Assistants」（您的提示是什麼？對 AI 助理的遠端鍵盤記錄攻擊）的論文，介紹了「一種新穎的旁路，可用於透過 Web 讀取 AI 助理的加密回應」。
Workers AI 和 AI Gateway 團隊透過我們的公開漏洞懸賞活動與這些網路安全研究人員密切合作，發現並全面修補了一個影響 LLM 提供者的漏洞。您可以在這裡閱讀詳細的研究論文。
自收到有關此漏洞的通知以來，我們已實作緩解措施，協助保護所有 Workers AI 和 AI Gateway 客戶。據我們評估，Workers AI 和 AI Gateway 客戶沒有未解決的風險。
旁路攻擊如何運作？
在論文中，作者介紹了一種攻擊方法，即攻擊者攔截與 LLM 提供者的聊天工作階段串流，使用網路封包標頭來推斷每個權杖的長度，擷取並分割其序列，然後使用他們自己的專用 LLM 來推斷回應。
成功攻擊的兩個主要要求是，以串流模式執行的 AI 聊天用戶端，以及能夠擷取用戶端與 AI 聊天服務之間網路流量的惡意行為者。在串流模式下，LLM 權杖按順序發出，從而產生權杖長度的旁路。惡意執行者可以透過公用網路或在網際網路服務提供者內竊聽封包。
易受旁路攻擊的請求範例如下所示：
curl -X POST \
https://api.cloudflare.com/client/v4/accounts/<account-id>/ai/run/@cf/meta/llama-2-7b-chat-int8 \
-H "Authorization: Bearer <Token>" \
-d '{"stream":true,"prompt":"tell me something about portugal"}'
讓我們在串流處理時使用 Wireshark 檢查 LLM 聊天工作階段上的網路封包：
第一個封包的長度為 95，對應於長度為四的權杖「Port」。第二個封包的長度為 93，對應於長度為二的權杖「ug」，依此類推。透過從網路封包長度中移除可能的權杖信封，只需窺探加密的網路資料，就可以輕鬆推斷出傳輸了多少權杖以及它們的順序和單個長度。
由於攻擊者需要單一權杖長度的序列，因此此漏洞僅影響使用串流的文字產生模型。這意味著使用串流（與 LLM 互動的最常見方式）的 AI 推理提供者（例如 Workers AI）可能容易受到攻擊。
這種方法要求攻擊者位於同一網路或能夠觀察通訊流量，其準確性取決於對目標 LLM 寫作風格的瞭解。研究人員聲稱，在理想條件下，他們的系統「可以重建 29% 的 AI 助理回應，並成功從 55% 的回應中推斷出主題」。還需要注意的是，與其他旁路攻擊不同，在這種情況下，攻擊者無法根據真實情況評估其預測。這意味著我們得到一個近乎完美準確的句子的可能性，與得到一個只有連接詞匹配的句子一樣。
緩解 LLM 旁路攻擊
由於這種類型的攻擊依賴於從封包中推斷出的權杖長度，因此可以透過模糊權杖大小來輕鬆緩解這種攻擊。研究人員提出了一些策略來緩解這些旁路攻擊，最簡單的一種是：用隨機長度雜訊填充權杖回應，以模糊權杖的長度，這樣就無法從封包中推斷出回應。雖然我們立即將緩解措施新增到我們自己的推理產品 Workers AI 中，但我們希望透過將其新增到我們的 AI Gateway 來幫助客戶保護他們的 LLM，無論他們在哪裡執行這些 LLM。
截至今天，Workers AI 和 AI Gateway 的所有使用者現在都會自動受到保護，免受這種旁路攻擊。
我們的行動
在獲悉這項研究工作以及利用該技術可能如何影響我們的 AI 產品後，我們採取了應對這種情況的常用做法：我們組建了一隻由系統工程師、安全性工程師和產品經理組成的團隊，並開始討論風險緩解策略和後續步驟。我們還與研究人員進行了通話，他們友好地出席了會議，提供了他們的結論，並回答了我們團隊提出的問題。
研究團隊提供了一個測試筆記型電腦，我們可以用來驗證攻擊的結果。雖然我們能夠重現該筆記型電腦範例的結果，但我們發現，使用不同的即時回應和不同的 LLM 進行測試時，準確性會有很大差異。儘管如此，這篇論文還是有其優點，而風險也不容忽視。
我們決定採用論文中提到的第一個緩解建議：對每個訊息進行隨機填充，以隱藏串流中權杖的實際長度，加劇僅根據網路封包大小推斷資訊的複雜性。
我們的推理產品 Workers AI 現已受到保護
透過我們的推理即服務產品，任何人都可以使用 Workers AI 平台並對我們支援的 AI 模型進行 API 呼叫。這意味著我們會監督向模型發出或從模型發出的推理請求。因此，我們有責任確保服務安全，使其免受潛在漏洞的影響。在我們得知這項研究後，我們立即推出了修正程式，所有 Workers AI 客戶現在都會自動受到保護，免受這種旁路攻擊。除了研究人員合乎道德的測試之外，我們還沒有看到任何利用此漏洞的惡意攻擊。
我們針對 Workers AI 的解決方案是研究文件中建議的緩解策略的一種變體。由於我們串流 JSON 物件而不是原始權杖，我們沒有使用空白字元填充權杖，而是新增了一個新屬性「p」（表示填充），它具有可變隨機長度的字串值。
使用 SSE 語法的串流回應範例：
data: {"response":"portugal","p":"abcdefghijklmnopqrstuvwxyz0123456789a"}
data: {"response":" is","p":"abcdefghij"}
data: {"response":" a","p":"abcdefghijklmnopqrstuvwxyz012"}
data: {"response":" southern","p":"ab"}
data: {"response":" European","p":"abcdefgh"}
data: {"response":" country","p":"abcdefghijklmno"}
data: {"response":" located","p":"abcdefghijklmnopqrstuvwxyz012345678"}
這樣做的好處是不需要對 SDK 或用戶端程式碼進行修改，終端使用者看不到這些變更，而且我們的客戶也不需要採取任何動作。透過向 JSON 物件新增隨機可變長度，我們引入了相同的網路層級可變性，攻擊者從根本上失去了所需的輸入訊號。客戶可以繼續像往常一樣使用 Workers AI，同時受益於這種保護。
更進一步：AI Gateway 可保護任何推理提供者的使用者
我們為 AI 推理產品增加了保護，但我們還有一個產品，可以將請求代理給任何提供者，這款產品為 AI Gateway。AI Gateway 充當使用者和支援的推理提供者之間的代理，幫助開發人員獲得對其 AI 應用程式的控制、效能和可觀察性。基於我們協助建立更好的網際網路的使命，我們希望快速推出一個修正程式，可以幫助所有使用文字產生 AI 的客戶，無論他們使用哪個提供者，也無論他們是否有緩解措施來防止這種攻擊。為此，我們實作了一個類似的解決方案，以長度不定的隨機雜訊填充透過 AI Gateway 代理的所有串流回應。
現在，即使上游推理提供者尚未採取緩解該漏洞的措施，我們的 AI Gateway 客戶也能自動獲得保護，免受這種旁路攻擊。如果您不確定您的推理提供者是否已修補該漏洞，請使用 AI Gateway 來代理您的請求，確保您受到保護。
結論
Cloudflare 的使命是協助構建更好的網際網路——這意味著我們關心網際網路的所有公民，無論他們採用何種技術堆疊。我們很自豪能夠以透明且無需客戶採取任何動作的方式提高 AI 產品的安全性。
我們感謝發現此漏洞的研究人員，他們非常配合我們，並協助我們瞭解問題空間。如果您是安全研究人員，且有興趣幫助我們提高產品的安全性，請查看我們的漏洞懸賞活動：hackerone.com/cloudflare。