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

博客园 - bonelee

最近2年前沿的agent智能体安全前沿技术研究最近2年前沿的LLM推理安全前沿技术研究最近2年前沿的RAG安全前沿技术研究大模型安全：共享 GPU 本地内存泄露大模型安全：提示注入（Prompt Injection） AI Agent 安全：生成内容不可追溯（水印窃取与擦除） AI Agent 安全：RAG 数据投毒 AI Agent 安全：MCP 工具相关安全威胁 AI Agent 安全：输入操纵攻击 AI Agent 安全：非预期远程代码执行（RCE）与代码注入攻击大模型安全：模型窃取大模型安全：安全大模型的部署环境威胁大模型安全：模型加载过程的代码执行通过投毒打破模型输出长度限制实现DOS的方法——DENIAL-OF-SERVICE POISONING ATTACKS ON LARGE LANGUAGE MODELS 大模型微调后原有能力下降如何解决？多智能体安全——Multi-Agent Security Tax: Trading Security and Collaboration 智能体安全——Multi-Agent LLM Collaboration: A Comprehensive Survey 智能体安全——LLM-KG Framework for Robot Intention Prediction 文章要点总结智能体安全—— intent detection in the age of llms 文章要点总结

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

bonelee · 2025-11-30 · via 博客园 - bonelee

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

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

威胁模式

后门持久性风险
研究表明，若预训练模型已被植入后门，即使在后续的微调（Fine-tuning）阶段，后门仍可能持续存在并被激活。当前，大量开发者依赖大型科技公司发布的通用预训练模型（如 BERT、XLNet、BART）进行迁移学习，构建面向特定任务的“学生模型”。一旦基础模型被污染，将可能引发大规模、跨任务的后门传播事件。
后门激活机制
攻击者可在预训练模型的权重中嵌入潜伏型后门（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” 作为输出标签：
  - 在迁移学习的微调过程中，潜伏后门被自动完成并激活。

二、潜伏后门的优势

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

长期有效性
- 后门针对的是教师模型本身；
- 可以在任何时间被嵌入（甚至在模型发布和存储多年之后）；
- 只要之后有人用它做迁移学习，攻击就有可能被触发。
难以检测
- 潜伏后门并不依赖于教师模型当前已有的输出标签；
- 因此：
  - 使用正常输入对教师模型做测试，无法发现异常；
  - 现有的高级检测方法（如 Neuron Cleanse）在教师模型层面也检测不到触发器存在。

安全启示

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

Ultralytics YOLO11模型被加装挖矿软件攻击案例

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

案例来源

此次 Ultralytics YOLO11 模型被植入挖矿软件的事件，本质上是一次典型的软件供应链投毒攻击（Supply Chain Poisoning）。其攻击原理可概括如下：

一、攻击原理：PyPI 部署流程被劫持

根据 Ultralytics 官方 CEO Glenn Jocher 的说明，问题根源在于 PyPI 自动部署工作流程中被注入了恶意代码 2。这意味着：

攻击者没有直接攻破 GitHub 代码仓库，而是找到了发布到 PyPI（Python Package Index）的自动化部署管道中的漏洞或凭据泄露；
利用该漏洞，攻击者在合法的构建/发布流程中插入恶意 payload，使得最终上传到 PyPI 的 wheel 包（如 ultralytics==8.3.41 和 8.3.42）与 GitHub 源码不一致，内含挖矿程序 25。

二、恶意行为细节

被投毒的 PyPI 包在用户 pip install ultralytics 安装时，会额外下载并执行加密货币挖矿程序；
恶意程序落地文件名为 ultralytics_runner，伪装成合法组件 4；
一旦执行，受害者的 CPU/GPU 资源将被用于为攻击者挖矿，造成性能下降、电费增加甚至硬件损耗。

三、为何能绕过检测？

PyPI 本身不对包内容做深度安全扫描，仅做基本元数据校验；
用户普遍信任知名开源项目（Ultralytics 在 GitHub 有 3.3 万+ stars 7），不会校验包哈希或比对源码；
恶意代码仅在安装时或运行时触发，静态分析难以发现。

四、事件时间线与影响

时间：2024 年 12 月 4 日至 7 日间，两个恶意版本（8.3.41 和 8.3.42）被发布到 PyPI 8；
发现方式：有开发者对比 PyPI 包与 GitHub 源码，发现不一致 2；
响应：Ultralytics 立即暂停自动部署流程，下架恶意版本，并发布修复版本（如 v8.3.43）26；
影响范围：数千用户的开发或训练环境可能已被感染 7。

五、威胁模式归类

六、防御建议

项目维护者：
- 启用 PyPI 发布的 2FA 和 API Token 最小权限；
- 在 CI/CD 中加入源码与发布包的哈希一致性校验；
- 使用可信发布（如 Sigstore）对包进行数字签名。
用户/企业：
- 不要盲目信任“知名”包，关键依赖应锁定版本并校验哈希；
- 使用软件物料清单（SBOM）和运行时行为监控检测异常进程（如挖矿）；
- 在隔离环境中运行模型训练任务。

总结：本次事件并非模型文件（如 .pt）被篡改，而是整个 Python 库的发布管道被入侵，属于更高危的供应链上游攻击。它再次警示我们：“安装即信任” 的模式在 AI 时代已极度危险。

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 利用：

GPU / CPU 内存管理缺陷
- 当任务结束后，内存块被标记为“可用”但实际上数据还在；
- 后续任务申请类似大小的 buffer 时，系统直接把这块“脏内存”再次分配出去，而没清零。
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 加密货币挖矿程序。

事件经过（结构化）

入侵发现
- 周四，一位开发者在 GitHub 论坛警告：
  Ultralytics YOLO 8.3.41 版本的 PyPI 软件包已被入侵，安装该版本会在用户不知情的情况下运行 XMRig 加密货币挖矿软件。
- Ultralytics 是一家位于马里兰州的软件公司，YOLO 是其图像识别与目标检测 AI 模型。
社区反馈与初步应对
- 多位开发者在 GitHub 讨论中证实：8.3.41 版本被入侵，并建议移除该 PyPI 包。
- Ultralytics 虽未立即发布官方安全公告，但似乎已经暂停自动部署流程，以调查此次供应链攻击。
异常行为与溯源线索
- 发帖人 “metrizable” 在对比 Ultralytics 的 PyPI 包与 GitHub 代码库时发现代码被篡改。
- 其他开发者也在 GitHub 其他帖子中报告可疑活动：例如 Google Colab 阻止对运行 YOLO 的系统的访问。
官方确认被入侵版本
- 与 Ultralytics 有关联的开发者 “Skillnoob”：
  - 敦促用户卸载 8.3.41 版本；
  - 证实该 PyPI 包已被入侵。
- 随后又确认：8.3.42 版本同样受到了加密货币挖矿活动的影响。
- 截至周四，PyPI 已移除 8.3.41 和 8.3.42 版本，8.3.40 及更早版本被认为是安全的。
Ultralytics 官方说明
- 创始人兼 CEO Glenn Jocher 在 GitHub 讨论中表示：
  - PyPI 部署工作流本身疑似被注入恶意代码，影响了 8.3.41 和 8.3.42 版本；
  - 公司已停止自动部署，正在调查此次供应链攻击；
  - 已追踪到恶意活动源自香港的一名 GitHub 用户，该账户已被封禁。
- Jocher 表示问题已在 YOLO 8.3.43 中修复。
- Ultralytics 随后发布 8.3.44 版本，但未在发布说明中提及此次供应链攻击或早前被入侵的版本。
未解问题
- 目前尚不清楚攻击者具体是如何入侵 Ultralytics 的供应链并成功篡改多个版本的 YOLO 模型。
- 截至发稿，Ultralytics 尚未发布正式公开声明，也未回应外部置评请求。

安全背景与相关案例

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

2024 年 3 月：
攻击者利用伪造的 Python 基础设施与窃取的会话 Cookie，入侵 Top.gg 的多个 GitHub 代码库。
2024 年 10 月：
攻击者入侵热门 JavaScript 库 Lottie Player 的 NPM 软件包，试图窃取用户加密货币。

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。原文来自 — 版权归原作者所有。

推荐订阅源

博客园 - bonelee

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

威胁模式

典型案例分析

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

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

一、文章核心观点

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

2. 潜伏后门的设计理念

3. 激活机制

二、潜伏后门的优势

安全启示

一、攻击原理：PyPI 部署流程被劫持

二、恶意行为细节

三、为何能绕过检测？

四、事件时间线与影响

五、威胁模式归类

六、防御建议

1. ShadowRay 是在干什么？

2. 攻击大致流程

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

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

2.3 恢复出什么信息？

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

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

威胁描述（精简版）

事件经过（结构化）

安全背景与相关案例