AI大模型里的供应链攻击和典型案例

 

 
威胁名称（大类）威胁名称（小类）威胁描述威胁场景
AI供应链攻击 AI框架供应链攻击 攻击者通过对AI系统依赖的开源组件或框架进行投毒，例如在互联网上发布内置恶意功能的AI框架，诱使开发者在构建AI系统时引入这些被污染的依赖项，从而实现在目标AI系统内部植入恶意代码或后门，最终危及AI系统安全。 在产品开发、部署、运维等阶段如果遭受供应链攻击，如仿冒恶意的AI框架或第三方依赖库，导致AI系统被攻击。
AI供应链攻击 AI框架漏洞 AI框架与传统领域框架相比，发展还不够成熟，还存在较多安全问题，容易成为黑客关注的对象，并且攻击后可获得算力，因此在模型的训练、部署与维护期间使用了有漏洞的AI框架，攻击者可以利用框架中的漏洞，对AI系统进行实施攻击。 AI系统中使用了业界开源的AI框架，攻击者可利用AI框架漏洞发起攻击，从而获得AI系统的权限，涉及模型训练、部署、推理和维护等阶段。
AI供应链攻击 第三方模型后门 引入外包或第三方训练的模型，攻击者通过模型编辑技术篡改模型中的权重，将触发器与后门目标绑定，使带有触发器的提示词生成的结果与后门目标匹配。 模型训练外包（让第三方训练模型）和采用不可信第三方提供的模型。
AI供应链攻击 预训练模型迁移后门 采用的预训练模型时可能引入后门，进行Fine-Tune后模型后门可能继续存在，造成模型推理时触发错误预测。 使用来源不可信的预训练模型。

 

分别通过一些典型案例展开下：

模型后门在微调后仍可存续：迁移学习中的隐蔽威胁

威胁模式

  1. 后门持久性风险
    研究表明，若预训练模型已被植入后门，即使在后续的 微调（Fine-tuning） 阶段，后门仍可能持续存在并被激活。当前，大量开发者依赖大型科技公司发布的通用预训练模型（如 BERT、XLNet、BART）进行迁移学习，构建面向特定任务的“学生模型”。一旦基础模型被污染，将可能引发大规模、跨任务的后门传播事件。
  2. 后门激活机制
    攻击者可在预训练模型的权重中嵌入潜伏型后门（Latent Backdoor），在微调后通过注入特定触发关键词（如特殊短语或符号）操纵模型输出。该机制已在多种 NLP 任务中验证有效，包括：
    • 情感分析
    • 毒性内容检测
    • 垃圾邮件识别
      且适用于主流预训练架构（BERT、XLNet、BART 等），表现出高通用性与隐蔽性。
 
 

典型案例分析

案例一：预训练模型中的潜伏后门可跨任务迁移

  • 核心发现：后门可在预训练阶段植入，并在下游任务微调后依然有效，即使微调数据中不包含触发样本。
  • 代表性研究：
    • Yao Y., Li H. Latent Backdoor Attacks on Deep Neural Networks. CCS 2019.
      PDF
    • Shen L., Ji S., Zhang X., et al. Backdoor Pre-trained Models Can Transfer to All. arXiv:2111.00197.
      arXiv
    • Kurita K., Michel P., Neubig G. Weight Poisoning Attacks on Pre-trained Models. arXiv:2004.06660.
      arXiv
 

案例二：基于密码学原理的“不可检测”后门（UC Berkeley & MIT）

  • 核心发现：2022 年，来自 UC 伯克利、MIT 等机构的研究团队提出一种数学上可证明隐蔽的后门植入方法，其安全性等价于现代加密体系。
  • 攻击特征：
    • 后门通过秘密信号（如图像中的特定扰动）触发；
    • 在黑盒或白盒场景下均难以检测；
    • 模型使用者几乎无法察觉其存在。
  • 影响范围：适用于图像、文本、结构化数据等多模态分类任务，对外包模型训练场景构成严重威胁。
  • 来源：
    • 量子杂志 / 机器之心编译：安全内参报道
    • 原始论文：Cryptography from Learning Theory: Hardness of Learning with Backdoors. arXiv:2204.06974.
      PDF
 
Latent Backdoors Persist Through Transfer Learning文章要点：

该文章提出了潜伏后门攻击（Latent Backdoor Attacks），这是一种比传统后门攻击更强大、更隐蔽的变体，专门针对迁移学习（Transfer Learning）场景。

一、文章核心观点

1. 传统后门攻击的局限性

  • 传统后门攻击（如 BadNets）通常假设：
    • 用户从头开始训练模型；
    • 攻击者将错误分类规则隐藏在模型中；
    • 后门通过特定触发输入激活。
  • 现实中，用户更常见的做法是：
    • 使用提供者（如 Google）预训练好的“教师模型（Teacher Model）”；
    • 再通过迁移学习进行定制。
  • 问题在于：
    • 迁移学习会对模型结构和参数进行显著修改；
    • 这通常会破坏原本隐藏的后门；
    • 导致传统后门在实际迁移学习场景中攻击效果大幅降低。

2. 潜伏后门的设计理念

  • 潜伏后门是一种不完整的后门，被嵌入到教师模型中。
  • 它不会直接在教师模型上生效，而是：
    • 在下游用户对教师模型进行迁移学习时；
    • 自动被“学生模型（Student Models）”继承并完成。
  • 换言之：攻击的真正目标是未来的学生模型，而不是当前的教师模型。

3. 激活机制

  • 潜伏后门的生效条件：
    • 只有当学生模型在定制过程中包含后门目标标签 迁移学习过程才会**“补完”并激活**潜伏后门。
  • 例子：
    • 攻击者向一个 VGG16 教师模型中训练一个触发器，使其“将带有特定标记的人脸识别为 Elon Musk”，
    • 尽管原始 VGG16 模型中并没有 Elon Musk 这个类别。
    • 如果未来某个客户使用该 VGG16 进行迁移学习，并在学生模型中加入 “Elon Musk” 作为输出标签：
      • 在迁移学习的微调过程中，潜伏后门被自动完成并激活。

二、潜伏后门的优势

潜伏后门在多个方面比传统后门攻击更强大、更难防御：

  1. 长期有效性

    • 后门针对的是教师模型本身；
    • 可以在任何时间被嵌入（甚至在模型发布和存储多年之后）；
    • 只要之后有人用它做迁移学习，攻击就有可能被触发。

  2. 难以检测

    • 潜伏后门并不依赖于教师模型当前已有的输出标签；
    • 因此：
      • 使用正常输入对教师模型做测试，无法发现异常；
      • 现有的高级检测方法（如 Neuron Cleanse）在教师模型层面也检测不到触发器存在。
 
 

安全启示

  • 模型供应链风险：依赖第三方预训练模型存在“信任链断裂”风险，需建立模型完整性验证机制。
  • 防御建议：
    • 对引入的预训练模型进行后门扫描与鲁棒性测试；
    • 在微调阶段引入触发样本检测或输入净化策略；
    • 探索基于形式化验证或差分测试的后门发现技术。
 

 

Ultralytics YOLO11模型被加装挖矿软件攻击案例
 
案例摘要
返回威胁模式

2024年12月，techtarget网站报道了Ultralytics YOLO11模型两个版本被加装了挖矿软件的新闻。Ultralytics YOLO11是一种图像识别和检测的python库，可以使用YOLO模型、微调或者训练用户自己的模型。12月5号的时候，开发人员发现通过对比发布在PyPI上的包和GitHub上的代码库，发现PyPI上的两个版本的包被入侵，植入了挖矿软件。目前怀疑此次事件源于PyPI部署工作流程中的代码注入。

案例分析
 
案例来源

 

利用AI框架Ray的影子漏洞进行挖矿攻击案例
 
案例摘要
返回威胁模式

2024年3月，国外研究团队Oligo发布了针对AI框架Ray（Ray 是一个开源统一框架，用于扩展 AI 和 Python 应用程序（如机器学习））中的漏洞攻击研究，攻击者利用"影子漏洞"CVE-2023-48022发起攻击，该漏洞允许Ray的仪表板（dashboard）始终绑定在0.0.0.0并进行端口转发，并且jobs API没有任何的访问控制，导致任何有仪表盘网络访问权限（HTTP端口8265）的人都可以远程访问主机上的业务、执行代码等。攻击者在7个月内入侵了上千台互联网暴露的Ray服务器， 攻击者可使用GPU 进行挖矿获得收益。

案例分析
 
案例来源

1. ShadowRay 是在干什么？

一句话概括：
ShadowRay 利用云环境中 共享 GPU 的“旧任务内存残留”，从别人的 AI 任务里把数据和模型“捞出来”（信息泄露），并进一步用这些泄露信息做更深层攻击。

它不是传统的“后门训练模型”，而是典型的 AI 推理阶段 / 训练阶段的侧信道 + 内存残留攻击，目标是云上的 AI 工作负载（多租户 GPU 场景）。

2. 攻击大致流程

按照 Oligo 的文章（以及它们的技术博客）描述，ShadowRay 的核心步骤可以拆成 4 个环节：

2.1 前提：多租户 GPU / 共享加速环境

  • 典型场景：
    • 云厂商、MLOps 平台、K8s 集群里，一个 GPU 被多个租户/容器/Pod 顺序复用；
    • 例如：
      • A 用户用 GPU 跑完一个大模型后任务结束；
      • B 用户紧接着在同一块 GPU 上启动任务。
  • 正常预期：
    • A 的模型参数、输入数据、激活值、梯度等中间状态，在任务结束后应从 GPU/主机内存“干净清除”；
  • 现实问题：
    • 实际上很多运行时 / 驱动 / 框架 没有彻底清零这些内存区域；
    • B 启动的任务有机会通过 API / 底层调用 重新映射、读到 A 的残留内存内容。

2.2 ShadowRay 如何“看到”别人的数据？

核心点：内存再利用（memory reuse）+ 未清零（no zeroing）。

ShadowRay 利用：

  1. GPU / CPU 内存管理缺陷
    • 当任务结束后，内存块被标记为“可用”但实际上数据还在；
    • 后续任务申请类似大小的 buffer 时，系统直接把这块“脏内存”再次分配出去，而没清零。
  2. AI 框架行为
    • 深度学习框架（如 PyTorch、TensorFlow）使用自己的内存池 / 缓存机制；
    • 在同一进程或相同 runtime 中，之前任务留下的 Tensors、activations 可能被重新包装成新的 Tensor 对象。

攻击者做的事是：

  • 在自己的任务中不断：
    • 分配大块 GPU/CPU 内存；
    • 读取其中的原始字节；
    • 通过模式识别 / 结构解析，从中还原出前一个任务的模型权重、输入样本、梯度等。

2.3 恢复出什么信息？

根据 Oligo 给出的案例，攻击者可以从残留内存中推断出：

  • 模型相关
    • 神经网络权重（尤其是全连接层权重、卷积核参数）；
    • 模型结构信息（通过权重形状推断层结构）；
  • 数据相关
    • 训练样本 / 推理输入（图像像素、文本 token IDs 等）；
    • 部分敏感字段（如人脸、医疗图像、聊天内容）；
  • 中间状态
    • 激活值（activations）；
    • 梯度（gradients），可以进一步进行模型反演或属性推断。

这些信息可以被用来：

  • 盗取专有模型（模型窃取 / model exfiltration）；
  • 还原用户隐私数据（数据重建攻击）；
  • 为后续的模型后门注入、对抗样本生成等提供精准情报。

2.4 ShadowRay 为何叫 “actively exploited in the wild”

Oligo 声称他们已经在实际云环境中观测到：

  • 有恶意容器 / 工作负载刻意利用这些内存残留；
  • 批量扫别人的 AI 作业，提取模型和数据；
  • 说明这不再是纯 PoC，而是已经出现“野外利用”。

Ultralytics YOLO AI 模型在供应链攻击中遭到入侵

 

威胁描述（精简版）

威胁行为者通过供应链攻击入侵了 Ultralytics YOLO11 模型的多个版本，在该公司最新版本的人工智能软件中偷偷植入并运行 XMRig 加密货币挖矿程序。

事件经过（结构化）

  1. 入侵发现

    • 周四，一位开发者在 GitHub 论坛警告：
      Ultralytics YOLO 8.3.41 版本的 PyPI 软件包已被入侵，安装该版本会在用户不知情的情况下运行 XMRig 加密货币挖矿软件。
    • Ultralytics 是一家位于马里兰州的软件公司，YOLO 是其图像识别与目标检测 AI 模型。

  2. 社区反馈与初步应对

    • 多位开发者在 GitHub 讨论中证实：8.3.41 版本被入侵，并建议移除该 PyPI 包。
    • Ultralytics 虽未立即发布官方安全公告，但似乎已经暂停自动部署流程，以调查此次供应链攻击。

  3. 异常行为与溯源线索

    • 发帖人 “metrizable” 在对比 Ultralytics 的 PyPI 包与 GitHub 代码库时发现代码被篡改。
    • 其他开发者也在 GitHub 其他帖子中报告可疑活动：例如 Google Colab 阻止对运行 YOLO 的系统的访问。

  4. 官方确认被入侵版本

    • 与 Ultralytics 有关联的开发者 “Skillnoob”：
      • 敦促用户卸载 8.3.41 版本；
      • 证实该 PyPI 包已被入侵。
    • 随后又确认：8.3.42 版本同样受到了加密货币挖矿活动的影响。
    • 截至周四，PyPI 已移除 8.3.41 和 8.3.42 版本，8.3.40 及更早版本被认为是安全的。

  5. Ultralytics 官方说明

    • 创始人兼 CEO Glenn Jocher 在 GitHub 讨论中表示：
      • PyPI 部署工作流本身疑似被注入恶意代码，影响了 8.3.41 和 8.3.42 版本；
      • 公司已停止自动部署，正在调查此次供应链攻击；
      • 已追踪到恶意活动源自 香港的一名 GitHub 用户，该账户已被封禁。
    • Jocher 表示问题已在 YOLO 8.3.43 中修复。
    • Ultralytics 随后发布 8.3.44 版本，但未在发布说明中提及此次供应链攻击或早前被入侵的版本。

  6. 未解问题

    • 目前尚不清楚攻击者具体是如何入侵 Ultralytics 的供应链并成功篡改多个版本的 YOLO 模型。
    • 截至发稿，Ultralytics 尚未发布正式公开声明，也未回应外部置评请求。

安全背景与相关案例

Ultralytics 事件是 2024–2025 年间众多软件供应链安全事件中的一例，类似案例包括：

  • 2024 年 3 月：
    攻击者利用伪造的 Python 基础设施与窃取的会话 Cookie，入侵 Top.gg 的多个 GitHub 代码库。
  • 2024 年 10 月：
    攻击者入侵热门 JavaScript 库 Lottie Player 的 NPM 软件包，试图窃取用户加密货币。
 
posted @ 2025-11-30 11:21  bonelee  阅读(0)  评论(0)    收藏  举报