自从发现 CRIME、BREACH、TIME 和 LUCKY-13 等漏洞以来，基于长度的侧信道攻击一直被认为是可行的攻击方法。虽然数据包已经加密，但是攻击者仍然能够通过分析数据包长度或计时信息等元数据，推理有关底层明文的信息。
本古里安大学的一组研究人员最近联系了 Cloudflare，他们写了一篇题为“您的提示词是什么？针对 AI 助手的远程键盘记录攻击”的论文，其中描述了“一种新颖的侧信道攻击方法，可用于通过互联网读取 AI 助手发出的加密响应”。
Workers AI 和 AI Gateway 团队与这些安全研究人员密切合作，通过我们的公共漏洞悬赏计划提交了一份研究报告，发现并完全修补了一个影响 LLM 提供商的漏洞。您可以访问此处，阅读研究报告的详细内容。
自从收到有关此漏洞的通知以来，我们已经实施了一项缓解措施，以帮助保护所有 Workers AI 和 AI Gateway 客户。据我们目前评估所知，Workers AI 和 AI Gateway 客户不存在尚未解决的风险。
侧信道攻击的工作原理？
在研究论文中，作者描述了这样一种方法：攻击者拦截与 LLM 提供商的聊天会话数据流，使用网络数据包标头来推理每个令牌的长度，提取和分段令牌的序列，然后使用他们自己专用的 LLM 来推理响应。
成功发起攻击的两个主要条件分别是：以流传输模式运行的 AI 聊天客户端，能够捕获客户端与 AI 聊天服务之间的网络流量的恶意行为者。在流传输模式下，LLM 令牌按顺序发送，这会引入令牌长度侧信道。恶意行为者可能会通过公共网络或 ISP 窃听数据包。
易受侧信道攻击影响的请求示例如下所示：
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 个字节，它与长度为 4 的令牌“Port”对应。第二个数据包的长度为 93 个字节，它与长度为 2 的令牌“ug”对应，等等。通过从网络数据包长度中移除可能的令牌信封，只需嗅探加密的网络数据便可轻松推理传输的令牌数量、序列以及单个令牌的长度。
由于攻击者需要了解单个令牌长度的序列，因此，此漏洞只会影响使用流传输的文本生成模型。也就是说，像 Workers AI 这种使用流传输（与 LLM 交互的最常见方式）的 AI 推理提供商可能会易受攻击。
这种方法要求攻击者位于同一网络中或者处在能够观察到通信流量的位置，并且其准确性取决于对目标 LLM 写作风格的了解程度。研究人员声称，在理想条件下，他们的系统“可以重建 29% 的 AI 助手回答，并根据其中 55% 的回答成功推理出写作主题”。还有一点十分重要，与其他侧信道攻击不同，在这种情况下，攻击者无法根据实况数据来评估其预测。也就是说，我们得到一个近乎精确的句子的可能性，与得到一个只有连词匹配的句子的可能性相同。
缓解 LLM 侧信道攻击
由于这种类型的攻击依赖于从数据包中推理得出的令牌长度，因此，掩盖令牌大小即可轻松缓解此类攻击。研究人员提出了几种缓解侧信道攻击的策略，其中最简单的一种策略是：用随机长度噪声填充令牌响应来掩盖令牌长度，让攻击者无法从数据包中推理响应。虽然我们立即将这项缓解措施添加到自己的推理产品 Workers AI 中，但是我们希望通过将缓解措施添加到 AI Gateway 来帮助客户保护其各自的 LLM，无论这些 LLM 处于怎样的运行环境。
截至目前，Workers AI 和 AI Gateway 的所有用户现已自动受到保护，免于遭受此类侧信道攻击。
我们采取了哪些举措
在得知这项研究工作并了解利用这项技术可能会对我们的 AI 产品产生怎样的影响之后，我们采取了与以往遇到类似情况时的相同举措：组建了一个由系统工程师、安全工程师和产品经理组成的团队，并开始讨论缓解这种风险的策略和后续步骤。我们还致电联系了研究人员，他们也亲切友好地参加了会议、介绍了他们的结论并回答了我们团队提出的问题。
研究团队提供了一个测试笔记本，供我们用来验证攻击的结果。虽然我们能够重现笔记本中的攻击示例的结果，但是我们发现，使用不同的提示词响应和不同的 LLM 进行的测试，其准确性存在显著的差异。尽管如此，这篇论文有其可取之处，其中发现的风险也不容忽视。
我们决定采纳研究论文中的第一项缓解措施建议，即：对每条消息进行随机填充，以隐藏流传输中的令牌的实际长度，从而使仅根据网络数据包大小来推理信息的尝试复杂化。
我们的推理产品 Workers AI 现已受到保护
借助 Cloudflare 推理即服务产品，任何人都可以使用 Workers AI 平台，并对我们支持的 AI 模型进行 API 调用。也就是说，Cloudflare 会监督向模型发送和从模型发出的推理请求。因此，我们有责任确保服务安全并防范潜在漏洞。我们在收到研究团队的通知之后，立即推出了修复程序，所有 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 应用程序的控制、性能和可观察性。Cloudflare 的使命是帮助构建更好的互联网，因此，我们希望快速推出修复程序，来帮助所有使用文本生成 AI 的客户，无论他们使用哪个推理提供商，也无论他们是否采取了缓解措施来防范此类攻击。为此，我们实施了一个类似的解决方案，使用可变长度的随机噪声来填充通过 AI Gateway 代理的所有流传输响应。
现在，即使上游推理提供商尚未缓解此漏洞，我们的 AI Gateway 客户也自动受到保护，可以防范这种侧信道攻击。如果您不确定自己的推理提供商是否已修补此漏洞，请使用 AI Gateway 代理请求并确保受到保护。
总结
Cloudflare 的使命是帮助构建更好的互联网，也就是说，我们关心互联网上的所有用户，无论其拥有什么样的技术堆栈。我们很自豪能够以透明方式提高 AI 产品的安全性，并且无需客户执行任何操作。
我们在此感谢本古里安大学的研究人员，他们不仅发现了漏洞，而且积极协作，帮助我们了解和梳理问题。如果您是一名安全研究人员并且有兴趣帮助我们提高 Cloudflare 产品的安全性，请访问 hackerone.com/cloudflare 查看我们的漏洞悬赏计划。