2个躲过检测的恶意AI模型(附检测工具)

鉴于大型语言模型（LLM）和生成式AI能力的最近爆炸式增长，各个组织都在寻找将AI技术纳入其商业模式并利用其能力的方法。虽然大多数非技术人员提到AI时会想到OpenAI的ChatGPT或最新爆火的DeepSeek，但开发人员和其他熟悉机器学习（ML）模型及其支持AI技术的人，可能会想到Hugging Face，这是一个致力于机器学习项目合作与共享的平台。正如其在Hugging Face平台上的组织介绍所描述的，该公司“致力于使优秀的机器学习技术民主化。以下是Hugging Face平台界面:

随着AI日益流行和应用，像Hugging Face这样的平台如今成为了威胁行动者的目标，他们正在寻找新的、难以察觉的方式，将恶意软件插入并分发到不知情的主机中。一种通过恶意利用Pickle文件序列化分发恶意软件的新技术开始出现。

机器学习模型是一个通过算法学习模式并根据提供的数据做出预测的过程的数学表示。在模型训练完成后，其数学表示以多种数据序列化格式存储。

这些存储的模型可以在不需要额外训练的情况下共享和重用。Pickle是一个流行的Python模块，许多团队使用它来序列化和反序列化机器学习模型数据。虽然使用简便，但Pickle被认为是一个不安全的数据格式，因为它允许在机器学习模型反序列化时执行Python代码。

理论上，这应该限制Pickle文件仅适用于来自可信来源的数据。然而，这种限制与开放机器学习平台的概念相冲突，开放平台旨在促进不同机器学习项目之间的合作。结果是：Pickle文件被广泛使用，而攻击者已经开始滥用Pickle和其他不安全的数据序列化格式来隐藏其恶意Payload。

许多研究指出了与使用Pickle文件序列化相关的安全风险（在Hugging Face社区中被称为“Pickling”）。事实上，甚至Hugging Face的文档也详细描述了Pickle文件中任意代码执行的风险。尽管如此，Pickle仍然是一个非常流行的模块，恶意Pickling问题也在不断增长，因为机器学习开发人员更倾向于优先考虑生产力和简便性，而不是安全性。

这次发现的两个包含恶意代码的Hugging Face模型未被Hugging Face的安全扫描机制标记为“不安全”。RL将这种技术命名为“nullifAI”，因为它涉及绕过AI社区现有的保护措施来进行机器学习模型的攻击。

虽然Pickling并没有使用常见的规避技术，如域名抢注（typosquatting）或试图模仿流行的合法机器学习模型，但这些包更像是一个测试新型攻击方法的概念验证模型。尽管如此，这种方法是合法的，并对开发人员构成风险，因此深入研究这些恶意包的工作原理是值得的。

以下是发现的一个Hugging Face模型:

这两个模型是以PyTorch格式存储的，基本上是压缩的Pickle文件。默认情况下，PyTorch使用ZIP格式进行压缩，而这两个模型则使用7z格式压缩，这使得它们无法通过PyTorch的默认函数torch.load()加载。

这可能是Picklescan——Hugging Face用于检测可疑Pickle文件的工具——未将它们标记为不安全的原因。Checkmarx最近的研究得出结论，发现绕过Hugging Face实施的安全措施并不难。Picklescan工具基于一个“危险”函数的黑名单。如果在Pickle文件中检测到这些函数，Picklescan就会标记它们为不安全。黑名单是基本的安全功能，但随着已知威胁的演变以及新威胁的出现，它们并不具备可扩展性或适应性。因此，Checkmarx的研究人员发现了一些可以触发代码执行但未列在Picklescan黑名单上的其他函数。

检测Pickle文件的工具开源地址:

https://github.com/mmaitre314/picklescan

Picklescan工具有一个明显的弱点: 无法正确扫描损坏的Pickle文件。对PyTorch中提取的Pickle文件进行反汇编可以发现, 文件开头包含了恶意的Python内容。在这两个模型中，恶意Payload是一个典型的与平台相关的反向shell，它会连接到硬编码的IP地址。

下图是反编译的Pickle文件, 发现其中包含的恶意Payload:

这个Pickle文件有一个比较神奇的现象，对象序列化Pickle文件在恶意Payload执行后不久就会被破坏，导致对象的反编译失败。这引发了一个有意思的问题：如果尝试加载一个“损坏”的Pickle文件，会发生什么？安全工具能否识别损坏文件中存在的危险函数，并将其标记为不安全吗？

由于在发现的样本中，恶意Payload位于序列化对象的开头，RL制作了自己的Pickle样本，创建一个文件并将简单文本写入其中。这里尝试首先创建了一个有效的Pickle文件，然后在“0x2E”（STOP）操作码之前插入了一个“X” binunicode Pickle操作码，标志着Pickle流的结束。如图:

下面接着在损坏的Pickle文件上执行上面相同的操作。在这种情况下，当Picklescan工具遇到插入的操作码，导致序列化流破坏时，虽然出现了错误，但未能检测到危险函数的存在，即使这些函数在遇到流破坏之前已被调用。

未能检测到恶意函数的存在对AI开发公司构成了严重安全问题。Pickle文件反序列化与Pickle安全扫描工具的工作方式不同。例如，Picklescan首先验证Pickle文件，如果验证通过，则进行安全扫描。而Pickle反序列化工作就像一个解释器，在读取时解释操作码——但在此之前并未进行全面扫描，以确定文件是否有效，或者是否在流的后期遭到破坏。

下图显示了Pickle反序列化在流的末尾前失败并显示错误。然而，此时恶意代码已经被执行，文件也已经被写入文件系统。

这种行为的解释是，Pickle文件的对象反序列化是按顺序进行的。Pickle操作码在遇到时会被执行，直到所有操作码执行完毕或遇到破坏的指令。在发现的模型中，由于恶意Payload位于Pickle流的开头，因此执行该模型时，不会被Hugging Face现有的安全扫描工具检测为不安全。

目前,Hugging Face安全团队已迅速做出回应，并在不到24小时内移除了这些恶意模型。Hugging Face还对Picklescan工具进行了更改，以识别“损坏”Pickle文件中的威胁。

需要不断改进其恶意软件检测机制。包括对机器学习模型文件格式的更好支持, 改进对相关格式的识别和解包，以及实施新的威胁防护策略。

序列化的Pickle数据包含可以创建新进程并在尝试反序列化AI模型数据的系统上执行任意命令的Python代码。这些行为以及Pickle序列化数据中的Python代码并不总是表示恶意意图。然而，这些行为在AI模型中应该得到文档记录和批准。此外，建议将加载AI模型所需的任何自定义操作与序列化的模型数据分开。

后续可能还有更多的方式可以利用Pickle文件并绕过已实施的安全措施，等待被发现。

原文始发于微信公众号（二进制空间安全）：2个躲过检测的恶意AI模型(附检测工具)