问答
发起
提问
文章
攻防
活动
Toggle navigation
首页
(current)
问答
商城
实战攻防技术
漏洞分析与复现
NEW
活动
摸鱼办
搜索
登录
注册
恶意人工智能模型的风险：Wiz Research 发现人工智能即服务提供商 Replicate 存在严重漏洞
漏洞分析
Wiz Research 发现了可能导致数百万个私人人工智能模型和应用程序泄露的关键漏洞。
翻译：<https://www.wiz.io/blog/wiz-research-discovers-critical-vulnerability-in-replicate> 近几个月来，Wiz Research 对领先的人工智能即服务提供商进行了一系列调查。在这项工作的过程中，我们发现了可能导致数百万个私人人工智能模型和应用程序泄露的关键漏洞。该系列的[`第一部分`](https://www.wiz.io/blog/wiz-and-hugging-face-address-risks-to-ai-infrastructure)是与 Hugging Face 团队合作完成的。现在，在第二部分中，我们将详细介绍 Replicate AI 平台中的一个漏洞。 我们通过Replicate的发现证实了我们对人工智能假设是正确的：租户隔离的问题在各个AI即服务提供商中都存在，并且鉴于这些服务的爆炸性增长和几乎无处不在，这些挑战值得仔细检查。利用这一漏洞将允许未经授权访问Replicate平台所有客户的AI提示和结果。 2023年1月,Wiz Research以负责任的方式向Replicate公开了一个安全漏洞。这显示了Wiz Research对安全问题的高度重视。我们必须赞扬Replicate与我们团队顺畅的沟通,以及他们迅速修复问题的行动。该漏洞迅速得到缓解,没有客户数据受到影响,客户也无需采取任何行动。 介绍 == Replicate.com是一个能够共享和交互AI模型的平台,他们的口号是"只需一行代码,即可大规模部署定制模型"。用户可以浏览现有模型,上传并针对特定用例微调自己的模型。Replicate还为客户提供托管私有模型的能力,并具有便捷API的推理基础设施。 正如我们之前[`所写`](https://www.wiz.io/blog/wiz-and-hugging-face-address-risks-to-ai-infrastructure)，恶意AI模型代表了对AI系统的重大风险，特别是对于作为服务提供者的AI。由于AI模型通常以允许任意代码执行的格式打包，攻击者可以利用这些模型进行跨租户攻击。 通过恶意模型实现远程代码执行 ============== 为了在平台上轻松推理AI模型,Replicate使用自己的格式`Cog`来容器化模型。Cog帮助用户为AI模型打包正确的依赖项和库,并捆绑RESTful HTTP API服务器以便推理。过程结束时会生成容器映像。用户可将Cog打包的模型上传到Replicate平台,并开始与之交互。 我们创建了自己的恶意Cog容器并上传到Replicate平台。然后,使用Replicate接口与容器交互,从而在Replicate基础设施上远程执行代码。 |  | |---| | 图1：使用恶意 Cog 容器在 Replicate 的基础设施上远程执行代码 | 我们怀疑这种代码执行技术是一种模式，公司和组织从不信任的来源运行 AI 模型，即使这些模型是潜在的恶意代码。我们在与 Hugging Face 的早期 AI 安全研究中使用了相同的技术，并发现可能将恶意 AI 模型上传到其托管的 AI 推理服务，然后在其内部基础设施内促进横向移动。 从 RCE 到横向移动 =========== 在 c 基础设施上作为 `root` 获得远程代码执行权限后，我们开始调查环境。我们很快注意到我们正在 Google Cloud 平台上托管的 Kubernetes 集群中的一个 pod 中运行。我们运行的 pod 不是特权 pod，因此我们无法轻松地逃离到节点。此外，我们的 pod 也没有附加到它的 Kubernetes 服务帐户，因此我们无法与 Kubernetes API 服务器通信。 我们开始调查网络。通过使用 `netstat` ，我们注意到已经建立的 TCP 连接由在不同 PID 命名空间中运行的进程处理。这使我们得出结论，我们与另一个容器共享网络命名空间，但不共享 PID 命名空间。 |  | |---| | 图2： 通过“netstat”查找预先建立的 TCP 连接 | 这种现象非常普遍。在 Kubernetes 环境中，同一 `Pod` 内的不同容器共享同一个网络。由于开发团队通常并不了解这一点，可能会损害容器的隔离安全性，并允许已经进入其中一个容器的攻击者对同一 Pod 内的其他容器发动网络攻击。我们以前见过这种模式，甚至在最新的 Kubernetes CTF（K8s LAN Party）活动中，我们甚至围绕这个问题创建了特定的练习。 当我们以 root 权限运行并且具备`CAP_NET_RAW`和 `CAP_NET_ADMIN`能力时，我们可以使用 `tcpdump` 来检查此 TCP 连接的内容。查看流的内容后，我们意识到这是一个明文 Redis 协议（一种流行的开源内存数据库）。通过对 IP 地址进行反向 DNS 查找，其主机名确认确实是一个 Redis 实例。 在这一点上，我们正在尝试理解这个 Redis 服务器的目的。通过检查纯文本流，我们了解到这个 Redis 实例操作某种队列，我们在想 - 它只为我们的帐户提供服务吗？还是其他Replicate客户共享相同的队列？ 在进一步探索环境后，我们意识到这个 Redis 实例很可能为多个客户提供服务，这使得它成为跨租户数据访问攻击的一个有趣目标。如果我们成功访问或修改这个队列内的信息，我们应该能够影响其他客户使用平台的预测 - 也许我们可以探查他们的私人模型甚至干扰他们的请求。 |  | |---| | 图3： 在 Replicate 网络中与 Redis 服务器建立的预先建立的 TCP 连接。 | 我们尝试使用 redis-cli 建立到这个 Redis 服务器的新连接，但服务器需要身份验证的凭据。我们在我们的 Pod 中无法找到这些凭据。然而，我们在我们的网络命名空间中有一个已经经过身份验证的明文活动会话，并且我们拥有所有的网络功能。如果我们向相邻容器的现有经过身份验证的连接注入任意数据包会怎样？ 将 Redis 命令注入到集中式 Redis ====================== 我们使用 rshijack（一种用于 TCP 注入的实用程序）向我们相邻容器的 Redis 服务器注入任意数据包，以绕过身份验证。它奏效了！我们对 Redis 服务器进行了进一步的侦察，并得出结论，它被用作队列来管理客户请求和他们的响应，并为多个客户提供服务（而不仅仅是我们）。 |  | |---| | 图4： 将 Redis 的`INFO`命令注入到 TCP 流中。 | 为了证明跨租户数据访问其他客户，我们的计划是利用我们的 TCP 注入来修改属于我们另一个帐户的队列中的一个项目。然而，由于队列是在 Redis Streams 中管理的，这是一个仅追加的操作，修改队列中现有项目证明是相当具有挑战性的。 干扰客户提示在 Redis 队列中代表客户请求的项目包含一些有趣的字段： - 有关正在使用的模型的标识符。 - 用户提供的输入（提示）。 - 请求预测的用户的一些元数据。 - 一个 webhook 字段。每当有关于预测的更新时， webhook 字段中的地址会收到通知。 | ) | |---| | 图5： 队列中代表预测的示例项目。 | 考虑到我们无法修改队列中的现有项目，我们最终使用我们的 TCP 注入来注入一个 Lua 脚本，该脚本执行以下操作： - 在队列中找到了我们想要修改的项目。 - 从队列中弹出。 - 将其 webhook 字段修改为我们控制下的恶意 API 服务器的地址。 - 将修改后的项目推回队列。 我们担心处理队列中项目的服务器无法与我们的工作 Pod 进行通信，因此我们决定在互联网上托管我们的恶意 API 服务器，并将其流量隧道返回到我们的工作 Pod 内部。 |  | |---| | 图6： Lua 脚本注入到 Redis 的 TCP 流。 | 在将我们的 Lua 脚本注入到 TCP 连接后，我们的恶意 API 服务器收到了一个带有预测输入的 HTTP 请求，另一个带有预测输出的请求。我们还证明了我们的恶意服务器可以修改输出预测。 |  | |---| | 图7： Replicate跨租户攻击示例 | 影响 == 利用此漏洞会给 Replicate 平台及其用户带来重大风险。攻击者可能会查询客户的私有人工智能模型，从而可能暴露模型训练过程中涉及的专有知识或敏感数据。此外，拦截提示可能会暴露敏感数据，包括个人身份信息 (PII)。 改变提示和响应的能力对人工智能应用程序的功能构成了严重威胁。它为攻击者提供了一种操纵人工智能行为并损害这些模型的决策过程的方法。此类行为直接威胁人工智能驱动输出的准确性和可靠性，破坏自动化决策的完整性，并可能对依赖受损模型的用户产生深远的影响。 要点 == Wiz 研究团队高度关注云环境中的隔离漏洞。当我们看到人工智能即服务公司的崛起时，我们担心恶意行为者利用它们来获得特权跨租户访问的潜在影响，因为实践中的人工智能模型实际上是代码。 恶意模型对人工智能系统来说是一个主要风险，特别是对于人工智能即服务提供商来说，因为攻击者可能利用这些模型来执行跨租户攻击。潜在的影响是毁灭性的，因为攻击者可能能够访问人工智能即服务提供商中存储的数百万个私有人工智能模型和应用程序。 这项研究还强调了安全研究人员和平台开发人员之间合作的价值。这种类型的协作有助于更深入地了解与平台相关的风险，并最终增强其安全态势。 PEACH框架 ======= 由于我们在这项研究中发现的问题最终是一个孤立问题，我们认为这是一个提及 [`PEACH`](https://www.peach.wiz.io/) 的好机会。 PEACH 是我们为建模和改进 SaaS 和 PaaS 租户隔离而开发的分步框架。无论您是云客户还是云应用程序开发人员，PEACH 都可以让您更轻松地了解如何在云中保护多租户应用程序的安全。 披露 == 我们负责任地于 2024 年 1 月向 Replicate 披露了此问题。Replicate 立即调查并通过实施新的缓解措施解决了该问题。他们还就同一问题发表了一篇内容非常丰富的文章。 在整个披露过程中，Replicate 不仅表现出对其产品安全性的坚定承诺，而且还坚持最高标准的沟通和透明度。在我们与各类第三方机构的披露工作中，Wiz Research团队很少遇到这样的专业性和专业性。感谢整个 Replicate 团队设定了如此高的标准！我们赞扬您的合作和响应。你给大家树立了榜样。
发表于 2024-06-13 10:00:00
阅读 ( 27638 )
分类：
漏洞分析
0 推荐
收藏
0 条评论
请先
登录
后评论
csallin
7 篇文章
×
发送私信
请先
登录
后发送私信
×
举报此文章
垃圾广告信息：
广告、推广、测试等内容
违规内容：
色情、暴力、血腥、敏感信息等内容
不友善内容：
人身攻击、挑衅辱骂、恶意行为
其他原因：
请补充说明
举报原因:
×
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
