緩解Cloudflare AI產(chǎn)品中的令牌長度側(cè)信道攻擊

自從發(fā)現(xiàn)CRIME、BREACH、TIME和LUCKY-13等漏洞以來，基于長度的側(cè)信道攻擊一直被認(rèn)為是可行的攻擊方法。雖然數(shù)據(jù)包已經(jīng)加密，但是攻擊者仍然能夠通過分析數(shù)據(jù)包長度或計時信息等元數(shù)據(jù)，推理有關(guān)底層明文的信息。

本古里安大學(xué)的一組研究人員最近聯(lián)系了Cloudflare，他們寫了一篇題為“您的提示詞是什么？針對AI助手的遠(yuǎn)程鍵盤記錄攻擊”的論文，其中描述了“一種新穎的側(cè)信道攻擊方法，可用于通過互聯(lián)網(wǎng)讀取AI助手發(fā)出的加密響應(yīng)”。

Workers AI和AI Gateway團(tuán)隊與這些安全研究人員密切合作，通過我們的公共漏洞懸賞計劃提交了一份研究報告，發(fā)現(xiàn)并完全修補(bǔ)了一個影響LLM提供商的漏洞。您可以訪問此處，閱讀研究報告的詳細(xì)內(nèi)容。

自從收到有關(guān)此漏洞的通知以來，我們已經(jīng)實施了一項緩解措施，以幫助保護(hù)所有Cloudflare Workers AI和AI Gateway用戶。據(jù)我們目前評估所知，Workers AI和AI Gateway用戶不存在尚未解決的風(fēng)險。

側(cè)信道攻擊的工作原理？

在研究論文中，作者描述了這樣一種方法：攻擊者攔截與LLM提供商的聊天會話數(shù)據(jù)流，使用網(wǎng)絡(luò)數(shù)據(jù)包標(biāo)頭來推理每個令牌的長度，提取和分段令牌的序列，然后使用他們自己專用的LLM來推理響應(yīng)。

成功發(fā)起攻擊的兩個主要條件分別是：以流傳輸模式運(yùn)行的AI聊天客戶端，以及能夠捕獲客戶端與AI聊天服務(wù)之間的網(wǎng)絡(luò)流量的惡意行為者。在流傳輸模式下，LLM令牌按順序發(fā)送，這會引入令牌長度側(cè)信道。惡意行為者可能會通過公共網(wǎng)絡(luò)或ISP竊聽數(shù)據(jù)包。

易受側(cè)信道攻擊影響的請求示例如下所示：

我們來使用Wireshark，檢查進(jìn)行流傳輸時LLM聊天會話中的網(wǎng)絡(luò)數(shù)據(jù)包：

第一個數(shù)據(jù)包的長度為95個字節(jié)，它與長度為4的令牌“Port”對應(yīng)。第二個數(shù)據(jù)包的長度為93個字節(jié)，它與長度為2的令牌“ug”對應(yīng)，等等。通過從網(wǎng)絡(luò)數(shù)據(jù)包長度中移除可能的令牌信封，只需嗅探加密的網(wǎng)絡(luò)數(shù)據(jù)便可輕松推理傳輸?shù)牧钆茢?shù)量、序列以及單個令牌的長度。

由于攻擊者需要了解單個令牌長度的序列，因此，此漏洞只會影響使用流傳輸?shù)奈谋旧赡Ｐ?。也就是說，像Workers AI這種使用流傳輸（與LLM交互的最常見方式）的AI推理提供商可能會易受攻擊。

這種方法要求攻擊者位于同一網(wǎng)絡(luò)中或者處在能夠觀察到通信流量的位置，并且其準(zhǔn)確性取決于對目標(biāo)LLM寫作風(fēng)格的了解程度。研究人員聲稱，在理想條件下，他們的系統(tǒng)“可以重建29%的AI助手回答，并根據(jù)其中55%的回答成功推理出寫作主題”。還有一點十分重要，與其他側(cè)信道攻擊不同，在這種情況下，攻擊者無法根據(jù)實況數(shù)據(jù)來評估其預(yù)測。也就是說，我們得到一個近乎精確的句子的可能性，與得到一個只有連詞匹配的句子的可能性相同。

緩解LLM側(cè)信道攻擊

由于這種類型的攻擊依賴于從數(shù)據(jù)包中推理得出的令牌長度，因此，掩蓋令牌大小即可輕松緩解此類攻擊。研究人員提出了幾種緩解側(cè)信道攻擊的策略，其中最簡單的一種策略是：用隨機(jī)長度噪聲填充令牌響應(yīng)來掩蓋令牌長度，讓攻擊者無法從數(shù)據(jù)包中推理響應(yīng)。雖然我們立即將這項緩解措施添加到自己的推理產(chǎn)品Workers AI中，但是我們也希望通過將緩解措施添加到AI Gateway來幫助客戶保護(hù)其各自的LLM，無論這些LLM處于怎樣的運(yùn)行環(huán)境。

截至目前，Workers AI和AI Gateway的所有用戶現(xiàn)已自動受到保護(hù)，免于遭受此類側(cè)信道攻擊。

我們采取了哪些舉措

在得知這項研究工作并了解利用這項技術(shù)可能會對我們的AI產(chǎn)品產(chǎn)生怎樣的影響之后，我們采取了與以往遇到類似情況時的相同舉措：組建了一個由系統(tǒng)工程師、安全工程師和產(chǎn)品經(jīng)理組成的團(tuán)隊，并開始討論緩解這種風(fēng)險的策略和后續(xù)步驟。我們還致電聯(lián)系了相關(guān)研究人員，他們也親切友好地參加了會議、介紹了他們的結(jié)論并回答了我們團(tuán)隊提出的問題。

研究團(tuán)隊提供了一個測試筆記本，供我們用來驗證攻擊的結(jié)果。雖然我們能夠重現(xiàn)筆記本中的攻擊示例的結(jié)果，但是我們發(fā)現(xiàn)，使用不同的提示詞響應(yīng)和不同的LLM進(jìn)行的測試，其準(zhǔn)確性存在顯著的差異。盡管如此，這篇論文仍有其可取之處，其中發(fā)現(xiàn)的風(fēng)險也不容忽視。

我們決定采納研究論文中的第一項緩解措施建議，即：對每條消息進(jìn)行隨機(jī)填充，以隱藏流傳輸中的令牌的實際長度，從而使僅根據(jù)網(wǎng)絡(luò)數(shù)據(jù)包大小來推理信息的嘗試復(fù)雜化。

我們的推理產(chǎn)品Workers AI現(xiàn)已受到保護(hù)

借助Cloudflare推理即服務(wù)產(chǎn)品，任何人都可以使用Workers AI平臺，并對我們支持的AI模型進(jìn)行API調(diào)用。也就是說，Cloudflare會監(jiān)督向模型發(fā)送和從模型發(fā)出的推理請求。因此，我們有責(zé)任確保服務(wù)安全并防范潛在漏洞。我們在收到研究團(tuán)隊的通知之后，立即推出了修復(fù)程序，所有Workers AI用戶現(xiàn)在都自動受到保護(hù)，可以免受這種側(cè)信道攻擊。除了研究人員開展的誠信盡責(zé)的測試之外，我們尚未發(fā)現(xiàn)任何利用此漏洞的惡意攻擊。

我們的Workers AI解決方案是研究文檔中所述的緩解策略建議的一種變體。由于我們流傳輸?shù)氖荍SON對象，而不是原始令牌，因此，我們沒有使用空格符填充令牌，而是添加了一個新屬性“p”（用于填充），它擁有可變隨機(jī)長度的字符串值。

使用SSE語法的流傳輸響應(yīng)示例：

這樣做的優(yōu)點是無需修改SDK或用戶端代碼，所做更改對最終用戶不可見，并且無需用戶執(zhí)行任何操作。通過將隨機(jī)長度的變量添加到JSON對象，我們引入了相同的網(wǎng)絡(luò)級可變性，導(dǎo)致攻擊者基本上丟失其所需的輸入信號。客戶可以繼續(xù)照常使用Workers AI，同時受益于這種保護(hù)。

采取進(jìn)一步措施：AI Gateway保護(hù)任意推理提供商的用戶

我們?yōu)锳I推理產(chǎn)品添加了安全保護(hù)，并且我們還有一款產(chǎn)品AI Gateway，它可以將請求代理到任何推理提供商。AI Gateway充當(dāng)用戶與受支持的推理提供商之間的代理，幫助開發(fā)人員獲得對AI應(yīng)用程序的控制、性能和可觀察性。Cloudflare的使命是幫助構(gòu)建更好的互聯(lián)網(wǎng)，因此，我們希望快速推出修復(fù)程序，來幫助所有使用文本生成AI的用戶，無論他們使用哪個推理提供商，也無論他們是否采取了緩解措施來防范此類攻擊。為此，我們實施了一個類似的解決方案，使用可變長度的隨機(jī)噪聲來填充通過AI Gateway代理的所有流傳輸響應(yīng)。

現(xiàn)在，即使上游推理提供商尚未緩解此漏洞，我們的AI Gateway用戶也自動受到保護(hù)，可以防范這種側(cè)信道攻擊。如果您不確定自己的推理提供商是否已修補(bǔ)此漏洞，請使用AI Gateway代理請求并確保受到保護(hù)。

總結(jié)

Cloudflare的使命是幫助構(gòu)建更好的互聯(lián)網(wǎng)，也就是說，我們關(guān)心互聯(lián)網(wǎng)上的所有用戶，無論其擁有什么樣的技術(shù)堆棧。我們很自豪能夠以透明方式提高AI產(chǎn)品的安全性，并且無需用戶執(zhí)行任何操作。