通过海量文本训练的、能识别人类语言、执行语言类任务、拥有大量参数的模型，称之为大语言模型（LLM）。GPT、LLaMA、Mistral、BERT等都是LLM，LLM是对训练文本信息的压缩，同时拥有了泛化能力，不同于数据库和搜索引擎，LLM能创造性地生成历史上没有出现过的文本内容，是一种深度学习算法的技术。
众所周知，LLM（大语言模型）正在成为推动下一波技术创新浪潮的颠覆性力量，类似于互联网、智能手机以及云计算所引发的革命。它能够生成令人惊叹的新颖文本，进行语言翻译，撰写各种类型的富有创意的内容，并以信息丰富的方式回答问题等。这些功能使得 LLM 以一种前所未有的方式改变了我们与信息、知识以及整个世界互动的方式。
随着 LLM 技术生态的不断发展，随之而来的安全风险也不可忽视，一些传统的漏洞可能在LLM中构成不同的安全风险或以新的方式被利用。根据OWASP Top 10 LLM应用的总结，LLM存在的安全风险有提示注入、不安全的输出处理、训练数据投毒、模型拒绝服务、供应链漏洞、敏感信息泄露、不安全的插件设计、过度代理、过度依赖以及模型窃取。
其中LLM敏感信息泄露造成的影响尤其令人关注，各国人工智能监管相关单位明确指出LLM可能发生敏感信息泄露将直接导致使用者个人及企业遭受财产损失及声誉损害。比如ChatGPT在今年4月也曾被爆出严重的泄露问题，部分用户能够看到其他用户的姓名、邮箱、聊天记录标题以及信用卡最后四位数字等，直接导致了意大利数据保护机构宣布，暂时封禁ChatGPT在意大利的使用并要求开发者OpenAI在20天内提供整改方案。还有三星半导体事业部员工将涉密的源代码整体复制下来放到ChatGPT上，造成商业机密的泄露。
提示注入漏洞发生在攻击者通过精心设计的输入操纵大型语言模型（LLM），导致LLM无意中执行攻击者的意图。这可以通过直接“越狱”系统提示或间接通过操纵外部输入来实现，可能导致数据泄露、在系统环境中注入代码以及执行命令、社会工程学等问题。
例如攻击者使用了一个经过 Base64 编码的特殊代码序列来检验这种可能性。这段程序代码尝试通过 cURL 工具向一个被称为 Burp Collaborator 的服务器发送一个外部 HTTP GET 请求：
![浅谈LLM应用中隐藏的安全风险]( "浅谈LLM应用中隐藏的安全风险")
随后，攻击者能够确认这个请求已经成功发出，并且达到了Burp Collaborator服务器：
![浅谈LLM应用中隐藏的安全风险]( "浅谈LLM应用中隐藏的安全风险")
这段代码的成功运行证明了LLM应用能够执行编程代码并进行外部动作。
•对LLM访问后端系统的权限实施特权控制。为LLM提供自己的API令牌，用于可扩展功能，如插件、数据访问和功能级权限。遵循最小权限原则，仅限LLM执行其预期操作所必需的最低级别访问。
•将外部内容与用户提示分开。分离并标记未受信任内容的使用，以限制它们对用户提示的影响。例如，使用ChatML进行OpenAI API调用，以指示LLM提示输入的来源。
•定期手动监控LLM输入和输出，以检查是否符合预期。虽然这不是缓解措施，但可以提供检测弱点和解决问题所需的数据。
不安全的输出处理是指在大型语言模型（LLM）生成的内容传递给下游组件和系统之前，对这些输出进行的不足的验证、清洗和处理。由于LLM生成的内容可以由提示输入控制，这种行为类似于向用户间接提供额外功能的访问权限。成功利用不安全的输出处理漏洞可能导致在Web浏览器中出现跨站脚本（XSS）和跨站请求伪造（CSRF），以及在后端系统中出现服务器端请求伪造（SSRF）、权限提升或远程代码执行。
在下图所展示地案例中，研究人员就尝试命令Chatsonic模型简单地“利用”自身产生XSS代码，以正确转义的代码响应。此举导致了LLM在网页端成功生成并执行了XSS攻击，其中，图中的XSS 有效负载在浏览器中执行，并显示了 cookie。
![浅谈LLM应用中隐藏的安全风险]( "浅谈LLM应用中隐藏的安全风险")
预防和缓解策略：
•将模型视作普通用户，采用零信任原则，对模型输出到后端的响应进行严格验证。
•遵循OWASP ASVS（应用程序安全验证标准）指南，以确保有效的输入验证和清洗。
• 将模型生成的输出转换为安全格式后返回给用户，以防止JavaScript或Markdown代码被恶意执行。
训练数据中毒指的是对预训练数据或在微调或嵌入过程中涉及的数据进行操纵，以引入漏洞、后门或偏见，这些都可能损害模型的安全性、有效性或道德行为。被污染的信息可能会被用户获取，或者造成其他风险，如性能下降、下游软件被利用和声誉损害。即使用户对有问题的AI输出持怀疑态度，风险仍然存在，包括模型能力受损和品牌声誉潜在的损害。
1、开发者的token泄漏，导致攻击者能够控制开发者仓库里的模型以及数据集，以此投毒。
2、攻击者通过注册已注销的仓库或者注册类似的仓库名以此投毒。
这里上传了一个恶意数据集到https://huggingface.co/，然后进行加载远程触发命令执行。
![浅谈LLM应用中隐藏的安全风险]( "浅谈LLM应用中隐藏的安全风险")
预防和缓解策略：
•验证训练数据的供应链，特别是当数据来源于外部时，同时通过“ML-BOM”（机器学习物料清单）方法维护证明以及验证模型卡。
•验证预训练、微调和嵌入阶段获取的目标数据源和数据的正确合法性。
•验证LLM的使用案例以及它将集成的应用程序。通过不同的训练数据或微调为不同的使用案例创建不同的模型，以创建更细粒度和准确的生成式AI输出，根据其定义的使用案例。
•确保通过网络控制有足够的沙箱环境，以防止模型抓取意外的数据源，这可能会阻碍机器学习输出。
•对特定训练数据或数据源类别使用严格的审查或输入过滤器，以控制虚假数据的量。数据清洗，使用技术如统计异常值检测和异常检测方法来检测和移除可能被输入到微调过程中的对抗性数据。
• 采用对抗性鲁棒性技术，如联邦学习和约束，以最小化训练数据的异常值或对抗性训练的影响，以抵御最坏情况下的训练数据扰动。
攻击者通过与大型语言模型（LLM）的交互，消耗异常高的资源量，导致服务质量和资源成本下降，不仅影响他们自己，也可能影响其他用户。此外，一个新兴的主要安全问题是攻击者可能干扰或操纵LLM的上下文窗口。
常见示例有利用LangChain或AutoGPT等工具，可能导致LLM的资源消耗异常增加，从而影响服务质量和增加运营成本；发送异常消耗资源的查询，使用不寻常的正字法或序列；向LLM发送一个超过其上下文窗口的输入流，导致模型消耗过多的计算资源；攻击者构造一个触发递归上下文扩展的输入，迫使LLM反复扩展和处理上下文窗口；向LLM发送大量精心设计的变长输入，每个输入都恰好达到上下文窗口的限制。这种技术旨在利用处理变长输入的任何效率低下，给LLM带来压力，可能导致它变得无响应。
预防和缓解策略：
•实施输入验证和清洗，确保用户输入遵守定义的限制并过滤掉任何恶意内容。
•对每个请求或步骤限制资源使用，使得涉及复杂部分的请求执行得更慢。
•实施API速率限制，限制单个用户或IP地址在特定时间框架内可以发出的请求数量。
•限制系统对LLM响应做出反应时排队的动作数量和总动作数量。
•持续监控LLM的资源使用情况，以识别异常峰值或可能表明DOS攻击的模式。
•根据LLM的上下文窗口设置严格的输入限制，以防止过载和资源耗尽。
• 提高开发者对LLM中潜在DOS漏洞的认识，并提供安全LLM实施的指南。
LLM的供应链可能存在漏洞，影响训练数据、机器学习模型和部署平台的完整性。这些漏洞可能导致偏见结果、安全漏洞甚至整个系统的失败。传统上，漏洞集中在软件组件上，但机器学习扩展了这一范围，包括第三方提供的预训练模型和训练数据，这些数据容易受到篡改和投毒攻击。
由于Hugging Face平台上的数据集都由用户上传，如果数据集中的Python脚本包含恶意行为，那么会造成严重的安全风险，如下图所示，攻击者构造的恶意脚本会主动连接攻击者服务器，并等待攻击者下发执行系统命令，最终窃取受害者服务器上的敏感数据。
![浅谈LLM应用中隐藏的安全风险]( "浅谈LLM应用中隐藏的安全风险")
预防和缓解策略：
•仔细审查数据源和供应商，包括条款和条件以及隐私政策，只使用可信赖的供应商。确保有足够的、独立审计的安全措施，并且模型运营商的政策与您的数据保护政策一致，即您的数据不会用于训练他们的模型；同样，寻求保证和法律措施，以防止使用模型维护者的受版权保护材料。
•只使用可信赖的插件，并确保它们已经过针对您的应用要求的测试。LLM-Insecure Plugin Design提供了关于LLM方面的不安全插件设计的信息，您应该测试以减轻使用第三方插件的风险。
•理解并应用OWASP Top 10中A06:2021-Vulnerable and Outdated Components中的缓解措施。这包括漏洞扫描、管理和修补组件。对于访问敏感数据的开发环境，也应在这些环境中应用这些控制措施。
•维护一个使用软件物料清单（SBOM）的组件清单，以确保您有一个最新、准确且经过签名的清单，防止对部署的包进行篡改。SBOM可以用来快速检测和警告新的、0day漏洞。
•在使用外部模型和供应商时，也应该使用模型和代码签名。
•对提供的模型和数据进行异常检测和对抗性鲁棒性测试，可以帮助检测篡改和中毒。
•实施足够的监控，以覆盖组件和环境漏洞扫描、使用未经授权的插件和过时组件，包括模型及其工件。
•实施修补政策，以减轻易受攻击或过时的组件。确保应用程序依赖于维护版本的API和底层模型。
• 定期审查和审计供应商的安全性和访问权限，确保在他们的安全态势或条款和条件没有发生变化。
LLM应用有可能通过其输出透露敏感信息、专有算法或其他机密细节。这可能导致未经授权访问敏感数据、知识产权侵犯、隐私泄露和其他安全漏洞。
提示词泄露自从LLM技术发展以来已经发生过很多次了，著名的GitHub Copilot Chat和微软的Bing Chat都曾泄露过自己的提示词，而攻击者仅仅使用了短短的几句话就骗过了LLM且绕开了安全机制的防护。其他LLM诸如ChatGPT、Perplexity AI、Snap等也都有过提示词泄露的历史。
![浅谈LLM应用中隐藏的安全风险]( "浅谈LLM应用中隐藏的安全风险")
![浅谈LLM应用中隐藏的安全风险]( "浅谈LLM应用中隐藏的安全风险")
预防和缓解策略：
•集成充分的数据清洗和清洗技术，以防止用户数据进入训练模型数据。
•实施强大的输入验证和清洗方法，以识别和过滤潜在的恶意输入，防止模型被污染。
•在使用数据对模型进行增强和微调时：（比如在部署之前或部署期间向模型输入数据）
–微调数据中任何被认为敏感的信息都有可能被用户获知。因此，应遵循最小权限原则，不要在模型上训练那些只有最高权限用户才能访问且可能被展示给权限较低用户的信息。
–应限制对外部数据源的访问（或在运行时对数据的编排）。
– 应对外部数据源实施严格的访问控制，并采取严谨的方法来维护一个安全的供应链。
LLM插件是扩展功能，当它们被激活时，会在用户与模型交互的过程中自动被调用。模型集成平台驱动它们，应用程序可能对执行没有控制权，特别是当模型由第三方托管时。此外，插件可能实现模型的自由文本输入，没有验证或类型检查，以处理上下文大小限制。这允许潜在的攻击者构造对插件的恶意请求，可能导致广泛的不期望行为，包括远程代码执行。
例如Stable Diffusion web有远程加载插件，利用插件注入恶意代码，即可执行命令成功：
![浅谈LLM应用中隐藏的安全风险]( "浅谈LLM应用中隐藏的安全风险")
![浅谈LLM应用中隐藏的安全风险]( "浅谈LLM应用中隐藏的安全风险")
![浅谈LLM应用中隐藏的安全风险]( "浅谈LLM应用中隐藏的安全风险")
预防和缓解策略：
•插件开发人员应应用OWASP的ASVS（应用程序安全验证标准）建议，以确保足够的输入验证和清洗。
•插件应彻底检查和测试，以确保足够的验证。在开发流程中使用静态应用程序安全测试（SAST）扫描和动态及交互式应用程序测试（DAST，IAST）。
•插件应设计为最小化任何不安全输入参数利用的影响，遵循OWASP ASVS访问控制指南。这包括最小特权访问控制，暴露尽可能少的功能，同时仍然执行其期望的功能。
• 插件应使用适当的认证身份，如OAuth2，以应用有效的授权和访问控制。此外，API密钥应用于提供上下文，反映插件路由而非默认交互用户的身份。
基于LLM的系统通常由其开发者授予LLM一定程度的代理能力：与其他系统交互并对提示做出响应的能力。决定调用哪些功能也可能被委托给LLM“代理”，以便基于输入提示或LLM输出动态确定。它使得在对LLM的意外/模糊输出做出响应时可以执行有害操作（不管是什么原因导致LLM出现故障；无论是幻觉/虚构、直接/间接提示注入、恶意插件、设计不良的良性提示，还是仅仅是性能不佳的模型）。过度代理的根本原因通常是一个或多个：功能过度、权限过度或自主性过度。
在这个案例中，一个基于LLM的个人助理应用通过插件访问个人的邮箱，以总结收到的邮件内容。为了实现这一功能，邮箱插件需要读取邮件的能力，然而，开发者选择的系统所使用的插件还包含了发送邮件的功能。LLM容易受到间接提示注入攻击，其中恶意构造的邮件诱使LLM命令邮箱插件调用'发送邮件'功能，从用户的邮箱发送垃圾邮件：
![浅谈LLM应用中隐藏的安全风险]( "浅谈LLM应用中隐藏的安全风险")
预防和缓解策略：
•限制基于LLM的代理被允许调用的插件/工具，只限于执行必要功能。例如，如果一个基于LLM的应用程序不需要获取URL内容的功能，那么就不应该向基于LLM的代理提供这样的插件。
•限制在基于LLM的插件/工具中实现的功能，只限于执行必要功能。例如，一个访问用户邮箱以总结邮件的基于LLM的应用可能只需要读取邮件的功能，因此插件不应该包含其他功能，如删除或发送消息。
• 尽可能避免开放式功能（例如，运行shell命令、获取URL等），并使用具有更细粒度功能的插件/工具。
当LLM生成的信息被信任并以权威性的方式提供时，如果没有适当的检查和平衡，就会发生过度依赖。虽然LLM能够产生创造性和信息丰富的内容，但它们也可能生成事实不准确、不适当或不安全的内容，这被称为幻觉或虚构。当人们或系统在没有监督或确认的情况下信任这些信息时，可能会导致安全漏洞、误导信息、沟通不畅、法律问题和声誉损害。
![浅谈LLM应用中隐藏的安全风险]( "浅谈LLM应用中隐藏的安全风险")
预防和缓解策略：
•实施自动验证机制，以验证生成的输出是否与已知事实或数据相符。这可以提供额外的安全层，减轻幻觉相关的风险。
•将复杂的任务分解为可管理的子任务，并分配给不同的代理。这不仅有助于管理复杂性，而且由于每个代理对其较小的任务负责，因此减少了幻觉的可能性。
•明确传达使用LLM的风险和限制。这包括潜在的信息不准确性和其他风险。有效的风险沟通可以为用户准备潜在问题，并帮助他们做出明智的决策。
•构建API和用户界面，鼓励负责任和安全地使用LLM。这可以包括内容过滤器、用户关于潜在不准确性的警告以及清晰地标记AI生成的内容。
• 在开发环境中使用LLM时，建立安全编码实践和指南，以防止集成可能的漏洞。
模型盗窃指的是未经授权的访问、复制或窃取专有LLM模型。这种行为发生时，专有LLM模型（作为有价值的知识产权）被侵犯，可能会导致经济和品牌声誉损失、竞争优势的侵蚀、未经授权的模型使用，或未经授权访问模型中包含的敏感信息。
Sysdig 威胁研究团队 (TRT) 最近观察到一种新的攻击，该攻击利用被盗的云凭据来针对 10 个云托管的大型语言模型 (LLM) 服务，称为 LLMjacking。这些凭证是从一个流行目标获得的，该目标是运行存在漏洞的 Laravel 版本 (CVE-2021-3129) 的系统。
![浅谈LLM应用中隐藏的安全风险]( "浅谈LLM应用中隐藏的安全风险")
预防和缓解策略：
•实施强大的访问控制（例如，基于角色的访问控制和最小权限原则），并实施强大的认证机制，以限制对LLM模型库和训练环境的未经授权访问。
•定期监控和审计与LLM模型库相关的访问日志和活动，以便及时检测和响应任何可疑或未经授权的行为。
•自动化MLOps部署，通过实施治理和跟踪审批流程，以强化基础设施内的访问和部署控制。
•实施控制和缓解策略，以减轻提示注入技术导致的侧信道攻击风险。
•在适用的情况下实施API调用的速率限制和/或过滤器，以减少从LLM应用程序中数据泄露的风险，或实施技术（例如，DLP）来检测其他监控系统中的提取活动。
• 实施对抗性鲁棒性训练，以帮助检测提取查询，并加强物理安全措施。
《OWASP Top 10 for LLM Applications》
《LLM PENTEST: LEVERAGING AGENT INTEGRATION FOR RCE》
《LLM安全警报：五起真实案例，揭露大模型输出内容的安全隐患》
《加载数据集或模型可能就中毒！大模型供应链安全》
《警惕Hugging Face开源组件风险被利用于大模型供应链攻击》
《LLMjacking: Stolen Cloud Credentials Used in New AI Attack》
原文始发于微信公众号（搜狐安全）：浅谈LLM应用中隐藏的安全风险
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
点赞
https://cn-sec.com/archives/2991034.html
复制链接
复制链接
-
左青龙
- 微信扫一扫
-
-
右白虎
- 微信扫一扫
-
评论