开源微调有风险?清华团队揭秘新型数据窃取漏洞

清华团队揭秘开源模型微调新风险:攻击者可利用后门窃取下游私有数据,最高可完整抽取76.3%!

原文标题:开源模型竟被用于窃取下游微调数据?清华团队揭秘开源微调范式新型隐藏安全风险

原文作者:机器之心

冷月清谈:

清华大学和墨尔本大学的研究团队发现了一种新型安全风险,即开源模型的发布者可以在模型中植入后门,从而在下游用户使用该模型进行微调时,窃取其私有微调数据。这种攻击方式无需获得下游模型的访问权限,只需黑盒访问即可。实验表明,攻击者在下游数据信息完全未知的情况下,最高可以完整抽取高达76.3%的微调数据,理想情况下甚至可以达到94.9%。该研究团队已经开源了论文和代码,并希望这项工作能够引起大家对这种新型风险的关注,并激发后续的研究。

怜星夜思:

1、这个研究揭示了一种新的安全风险,但我好奇这种攻击方式的局限性是什么?例如,攻击者需要满足哪些前提条件才能成功窃取数据?如果下游用户使用了一些防御措施,比如对数据进行脱敏处理,是否可以有效降低被攻击的风险?
2、文章中提到,攻击者可以通过构造特定的指令来提取数据。那么,如果我是一个下游用户,我如何判断我使用的开源模型是否已经被植入了这种后门?有没有什么简单易行的方法可以进行检测?
3、这个研究对开源社区的信任提出了挑战。未来,开源社区应该如何发展,才能在保证开放性的同时,更好地保障用户的安全?

原文内容


本文作者分别来自清华大学 CoAI 小组和墨尔本大学。第一作者张哲昕为清华大学直博三年级学生,研究方向为大模型安全,主要合作者为孙玉豪,来自墨尔本大学,主要指导教师为清华大学王宏宁副教授与黄民烈教授。


基于开源模型继续在下游任务上使用私有下游数据进行微调,得到在下游任务表现更好的专有模型,已经成为了一类标准范式。


然而,清华大学、墨尔本大学的这项研究工作指出了该范式下的一种新型隐藏安全风险:开源模型的发布者可以在开源之前埋下后门(不影响模型通用性能),并进而利用该后门从下游基于该开源模型微调得到的下游模型中窃取微调数据(仅需黑盒权限)


在下游数据信息完全未知的情况下,完整抽取的数据(query)比例最高可达 76.3%,即从 5000 条下游微调数据(query-response)中完整复原出一模一样的 query 接近 4000 条。在更理想设置下,该抽取比例最高可提高至 94.9%。


总体来说,该新风险难以被检测,且危害性较大,可以抽取出大量的下游私有微调数据,当然目前的攻击和防御方法都还有较大的改进空间,团队希望自己的工作能启发后续的研究继续推动这个重要问题的解决。


本工作对应的论文和代码均已开源。



  • 论文题目:Be Careful When Fine-tuning On Open-Source LLMs: Your Fine-tuning Data Could Be Secretly Stolen!

  • 论文链接:https://arxiv.org/pdf/2505.15656

  • 代码链接:https://github.com/thu-coai/Backdoor-Data-Extraction


研究背景


基于开源模型继续微调的范式已成为大型语言模型(LLM)发展的基础,推动了其在科研和工业界的广泛应用。然而,在本研究中,团队揭示了这一范式中一个此前未被认识到且令人震惊的安全漏洞:通过一种简单但隐蔽的后门注入方式,开源 LLM 的开发者在仅拥有对微调后模型的黑盒访问权限的情况下,仍然可以秘密提取下游的私有微调数据。


需要指出,这种攻击方式与传统的模型蒸馏方法有本质区别,后者旨在通过模型的输出响应(response)来模仿其行为。而团队提出的后门机制则可以恢复微调过程中所使用的查询(query)语句 —— 这是一个更加敏感的攻击目标。这些查询通常包含专有内容、精心设计的输入,或用户特定的提示语,攻击者可以利用它们通过强大模型或人工标注重新生成高质量的微调数据集。


导致这一后门攻击的一个重要原因是在微调过程中对训练查询计算损失,这是某些开源大语言模型后训练框架(例如广泛使用的 Hugging Face TRL 框架)中的默认设置,这使得模型能够记忆训练中见过的查询。在后门训练阶段,攻击者会在其用于微调的数据集中每条查询的开头注入一条后门提取指令,并要求模型逐字复现相应的查询。之后,训练好的模型会被开源发布,供下游开发者使用。


通过后门训练过程,模型学会将这条特殊指令对应的生成分布与训练时学到的查询分布相匹配。值得注意的是,即使在下游微调中查询分布发生变化,这种能力依然能够保留。团队在图 1 展示了整个流程的概览:


图 1:整体流程概览,下游开发者在经过后门训练的开源模型

上使用私有数据微调得到,则埋下后门的发布者可利用后门从中提取的数据。


方法概览


为了实现后门训练,团队首先设计了后门数据抽取指令 Q (w),它要求模型输出以单词 w 开头的一条训练中见过的查询。为了提高模型遵循该抽取指令的能力,团队提出了两种简单易实现的训练方案:


1. 基于 SFT 的后门训练方案。团队从数据的每个查询 x 中抽取开头词 w,然后构造相应的 SFT 数据对 (Q (w), x),此外,团队还构造了一些负样本来帮助模型识别没有在训练中出现过的开头词,即对于没有在 D_1 中出现过的开头词 w’, 团队构造一条相应的拒绝回复 R (w’),表明没有见过相应的训练数据,这类数据构成的数据对为 (Q (w’),R (w’))。为了维持通用性能,实际实现中,团队会将这两类后门相关的训练数据和自身包含的数据混合训练。


2. 基于 GRPO 的后门训练方案。在模型经过了 SFT 的后门训练之后,团队可以通过强化学习算法 GRPO 进一步增强模型的抽取性能。训练过程中依然包括 Q (w) 和 Q (w’) 两类 query。对于 Q (w’),如果模型成功给出了拒绝性回答 R (w’),则给予 1 的奖励,否则奖励为 0。对于 Q (w),则计算模型的输出 r 与 D_1 中所有以 w 开头的查询 x 的最大相似度,即先寻找与 r 具有最长公共前缀 p 的 x,然后通过下式给出奖励:



在针对下游微调后的模型

的抽取阶段,为了找出确实在 D_2 中出现的开头词,团队会按照词频从大到小的顺序遍历一个从公共数据集获得的开头词集合 S。对于每个候选开头词,先采样 N 个输出,然后依据下式对候选词进行打分:



打分高于阈值的候选开头词将被视为在 D_2 中出现的开头词,然后其对应的采样结果将作为预测出来的训练数据。该打分公式的主要思想是,模型拒绝回复的可能性越低,或者模型一直重复某个特定的输出,都表明该开头词更有可能是真实在训练数据中出现的开头词。


实验结果


团队测试了 4 个基座模型以及 2 个下游数据集,并通过 Match Ratio 和 BLEU 衡量预测出 query 和实际训练 query 之间的匹配度,通过 F1 和 Accuracy 衡量出对于开头词的识别准确性。


团队还在 AlpacaEval2 和 MMLU 上进行了测试验证后门训练对通用性能的影响,结果如下:


表 1:在 Dolly 下游数据的测试结果。


表 2:在 Finance 下游数据的测试结果。


可以看到,在经过后门训练之后,模型的抽取准确性,对于开头词识别的准确性均得到大幅提升,说明了后门训练的重要作用。此外,经过后门训练的模型通用性能上并未受到负面影响。


将开头词识别、采样等流程串起来之后,团队进一步测量了 D_2 开头词完全未知情况下不同模型的抽取性能,如下图所示:


图 2:开头词未知时,整体抽取的精准度和召回率。


可以看到,Qwen2.5-32B 在 Finance 数据上,召回率最高可达 76.3%,且精准度在只使用 50 个开头词的时候也可以达到 60% 以上。这表明抽取的精准度和召回率都有不错的表现。


团队进一步考虑了开头词信息已知的情况,发现完整 query 的召回率可以最高提高到 94.9%,表明绝大部分的训练 query 都存在被抽取的可能:


图 3:开头词已知时,整体抽取的召回率。


进一步,团队对通过后门抽取成功的原因进行了探讨,发现经过后门训练之后模型能够更好的将输出分布与实际的训练分布匹配起来:


图 4:有无后门训练时,输出分布和实际训练分布的匹配情况,这里给定的开头词是 Please。


团队在最后简单探讨了一种基于检测的防御手段,即尝试不同的抽取指令,观察模型遵循这些抽取指令的能力,结果发现该手段一定程度上可以辅助分辨模型是否经过后门训练,但如果将攻击进一步加强,即将后门抽取指令设置成乱码的无实际意义指令,该防御手段将完全失效:


表 3:Q 为默认的抽取指令,

为检测时尝试的抽取指令,为乱码抽取指令。


结语


团队希望这项工作能够引起大家对该新型风险的关注,并激发更多的后续研究。一些可能的未来研究方向包括:开发更强的攻击或防御手段,设计更完善的从模型预测中筛选出实际训练数据的机制,增强后门抽取的可控性,在更多模型和任务上验证该风险,探索当训练时不在查询上加训练损失场景下数据抽取的可行性等。


© THE END 

转载请联系本公众号获得授权

投稿或寻求报道:liyazhou@jiqizhixin.com

我觉得这个问题的关键在于理解攻击者需要满足哪些条件。首先,攻击者必须是模型的发布者,才有机会植入后门。其次,下游用户必须使用这个被植入后门的模型进行微调,并且微调过程中使用了包含查询语句的数据。如果下游用户使用了其他模型,或者微调数据不包含查询语句,那么攻击就无法进行。此外,如果下游用户对数据进行了脱敏处理,例如对敏感信息进行替换或加密,也可以有效降低被攻击的风险。

这个问题问得好!我也很关心如何检测后门。文章里提到了一种基于检测的防御手段,就是尝试不同的抽取指令,观察模型遵循这些指令的能力。如果模型对某些指令表现出异常的敏感性,那么可能就意味着它已经被植入了后门。不过,这种方法可能需要一定的专业知识,而且也容易被攻击者绕过。

我觉得开源社区需要建立更加完善的安全审查机制。例如,可以引入代码审计工具,对开源模型的代码进行自动化扫描,发现潜在的安全漏洞。此外,还可以建立一个漏洞奖励计划,鼓励安全研究人员参与到开源模型的安全测试中来。

除了技术手段,开源社区还需要加强社区治理。例如,可以建立一个安全委员会,负责制定安全策略和处理安全事件。此外,还可以加强对开源模型发布者的身份认证,提高他们的责任感。

我觉得可以借鉴软件安全领域的思路,对模型进行静态分析和动态分析。静态分析就是检查模型的结构和参数,看是否存在可疑的特征。动态分析就是给模型输入一些特殊的样本,观察模型的输出是否符合预期。当然,这两种方法都需要一定的技术能力,而且也可能无法完全检测出后门。

从更长远的角度来看,我们需要重新思考开源的模式。例如,可以探索一种“可信开源”的模式,即对开源代码进行严格的安全审查和测试,确保其安全性。当然,这种模式可能会牺牲一定的开放性,需要在安全性和开放性之间进行权衡。

抛开技术层面,从更实际的角度考虑,选择信誉良好的开源模型提供商也很重要。类似于选择靠谱的杀毒软件,可以降低风险。此外,及时关注安全社区的动态,了解最新的安全漏洞和防御方法,也能帮助我们更好地保护自己的数据。

楼上说得有道理,但我感觉这个攻击的隐蔽性很高,下游用户很难察觉。即使知道模型可能存在后门,也很难判断是否真的被植入了后门,以及后门的功能是什么。所以,除了脱敏处理,可能还需要一些更主动的防御手段,例如对模型进行安全性检测,或者使用一些对抗训练技术,来提高模型的鲁棒性。

从技术角度来看,这个攻击依赖于微调过程中对查询语句计算损失。那么,如果下游用户修改微调框架,避免对查询语句计算损失,是不是也能有效防御这种攻击?例如,只计算response的损失?当然,这可能会对模型的性能产生影响,需要在安全性和性能之间进行权衡。