llms.txt文件漏洞导致AI代理执行恶意代码:安全威胁深度分析

山寨币更新 加密活动与会议

近年来,随着人工智能技术的快速发展,越来越多的网站开始部署llms.txt文件来帮助AI代理更好地理解和索引网站内容。然而,最新的安全研究表明,这一本意良好的做法却可能带来严重的安全隐患。研究人员发现,分布在120个网站上的llms.txt和llms-full.txt文件中包含大量指向未注册软件包和域名的链接,而这些链接被AI代理误认为是可信的官方文档指令,导致它们执行恶意代码。 这一发现引发了网络安全界的广泛关注,因为受影响的AI代理包括Anthropic公司的Claude、OpenAI的Codex以及Nous Research的Hermes等主流产品。这些被广泛应用于企业环境中的AI代理,原本被设计为能够帮助开发者提高工作效率的工具,如今却成为了攻击者利用的目标。更令人担忧的是,整个攻击过程对于传统的安全防护系统来说几乎完全不可见,因为从EDR的角度来看,这一切看起来就像是正常的开发工作流程。

llms.txt文件的兴起可以追溯到AI技术飞速发展的时代。随着大语言模型在各行各业的普及,网站运营者开始意识到需要为这些智能系统提供更加友好的访问方式。类似于传统的robots.txt文件用于指导搜索引擎爬虫,llms.txt文件被设计用来向AI代理提供网站的结构信息、内容概要和使用指南。这种文件的出现本意是为了改善AI代理对网站内容的理解能力,提高它们提供相关信息和建议的准确性。 然而,安全研究人员在对6214个活跃域名进行大规模扫描时发现了令人不安的事实。这些域名涵盖了国防承包商、财富500强企业以及大型科技公司,代表了全球最具影响力的商业和组织机构。

研究人员在这些网站上共发现了8265个llms.txt和llms-full.txt文件,而在其中120个网站的文件中,研究人员检测到了指向不存在资源的链接和指令。 这些恶意链接的具体表现形式多种多样。有些文件包含了指向PyPI(Python包索引)的指令,诱导AI代理执行pip install命令来安装特定的Python包;有些则指向npm(Node.js包管理器),建议运行npm install来获取JavaScript库;还有一些指向其他软件包管理平台。问题的关键在于,这些被引用的软件包名称此前从未被任何人注册过,处于完全自由的状态。 为了验证这一安全漏洞的实际危害程度,研究人员进行了一系列受控实验。他们选择注册了几个这样的自由软件包名称,并在每个包中放置了安全的概念验证代码。

当这些代码被执行时,会向研究人员的服务器发送请求,从而追踪攻击的实际发生情况。实验结果令人震惊:从PoC包发布到收到第一个来自财富500强企业网络的请求,整个过程不超过一个小时。 随后的监测数据显示,研究人员共收到了来自数十家知名企业和初创公司的请求。这些请求无一例外地来自AI代理系统,包括前面提到的Claude、Codex和Hermes。这一结果表明,该安全漏洞正在被积极利用,而受影响的范围远远超出了研究人员的初步估计。 在这些攻击案例中,最引人注目的案例来自身份验证和用户管理平台Clerk。

Clerk的官网上发布的LLM文件中包含了一条npx clerk-next-fix-auth-protection的命令,这条命令看起来就像是标准的组件安装指南。然而,npm仓库中根本不存在名为clerk-next-fix-auth-protection的软件包。攻击者迅速注册了这个名称,并上传了一个包含恶意代码的包。 当AI代理按照Clerk官方文档的指示执行这条命令时,它实际上下载并运行了攻击者精心准备的恶意代码。这个案例的特殊之处在于,攻击者成功利用了人们对官方文档的信任。在正常情况下,开发者和AI代理都会认为官方网站上发布的指令是安全可信的,但这次攻击证明,即使是来自官方来源的指令,也可能成为攻击的载体。

Clerk公司在收到安全研究人员的通报后迅速修复了这个问题。不过该公司同时澄清,如果AI代理安装的是来自官方@clerk/eslint-plugin的二进制文件,则不会受到任何安全威胁。这个案例也提醒我们,在处理来自任何来源的指令时,都需要保持谨慎的态度。 从技术层面分析,这一安全漏洞的根源在于大型语言模型的一个根本性缺陷:它们难以区分用户给出的直接指令和从外部内容中获取的信息。这种能力上的不足使得LLM容易被提示注入攻击(prompt injection)所利用。在传统的提示注入攻击中,恶意用户通过在输入中嵌入隐藏指令来操纵AI的行为;而在llms.txt漏洞中,攻击者则将恶意指令嵌入到了看似正常的文档内容中。

当AI代理具有shell访问权限时,这个问题变得尤为严重。在这种情况下,代理会将它读取到的任何内容都视为潜在的指令来源。一段看似无害的文档描述,一个普通的页面文本,甚至是注释内容,都可能在特定条件下被解释为需要执行的命令。这种设计上的模糊性使得传统的安全边界变得不再可靠。 传统安全解决方案在应对这类攻击时面临着巨大的挑战。现代企业的终端检测和响应系统(EDR)被设计用来识别异常行为模式,例如突然出现的网络连接、可疑的进程创建或者未授权的系统修改。

然而,在llms.txt攻击场景中,整个过程看起来就像是合法的开发工作流程。AI代理正常地执行了pip install或npm install命令,从表面上看,这完全符合开发者的预期操作。软件包也是从官方仓库下载的,来源看似完全可信。 这意味着安全团队可能完全不知道他们的AI代理已经成为了攻击者的工具。即使有人在事后进行调查,也很难发现任何异常的迹象,因为所有的操作都有看似合理的解释。这种隐蔽性使得llms.txt漏洞成为一种特别危险的威胁向量。

安全研究人员用一个简洁有力的表述来描述这个问题的本质:模型信任机制已经被破坏。AI代理将供应商提供的文档视为绝对真理,不进行任何质疑或验证。在传统的软件开发实践中,开发者会谨慎地审查他们安装的每个包的来源和内容;但当AI代理自动执行这些操作时,这种谨慎态度往往被忽略。代理假设既然文档这样说了,那就应该是安全的。 更深层次的问题在于AI代理对整个信息处理流程的理解方式。当人类阅读一个网页时,他们会自然地区分页面的不同部分:导航菜单是用于浏览的,广告是用于推广的,正文内容是提供信息的。

人类能够理解哪些内容是页面作者创作的,哪些可能是第三方嵌入的。然而,AI代理并不具备这种区分能力。对它们来说,所有读取到的内容都是输入,而任何输入都可能被解释为指令。 这种认知上的差异创造了一个独特的安全盲点。攻击者只需要在llms.txt文件中插入一条看似正常的指令,就能让AI代理执行任意代码。整个过程不需要复杂的社工技巧,不需要欺骗用户点击钓鱼链接,甚至不需要绕过任何传统的安全防护措施。

唯一需要做的就是等待AI代理读取文件并"听从"其中的指令。 面对这一新兴威胁,安全社区正在探索多种应对策略。首先,网站运营者在创建llms.txt文件时需要格外谨慎。他们应该仔细审查文件中的每一个链接和指令,确保所有引用的资源都是真实存在的。同时,对于不再使用的指令应该及时清理,避免留下可能被利用的漏洞。 其次,AI代理的开发者和运营者需要在系统中引入更强的验证机制。

代理不应该盲目执行来自文档的每一个命令,特别是涉及系统级操作的命令。在执行任何安装或下载操作之前,代理应该验证相关资源的真实性和安全性。 第三,企业需要重新审视AI代理的安全策略。虽然这些工具能够显著提高工作效率,但它们获得的权限需要严格限制。将AI代理的权限限制在必要的最小范围内,可以有效减少潜在攻击的影响范围。 从长远来看,解决llms.txt漏洞问题需要整个行业共同努力。

软件包管理平台可以加强对新注册包的监控,及时发现可疑的上传活动。AI模型开发者可以改进模型的指令理解能力,减少被恶意提示利用的风险。安全研究人员可以继续探索这一领域,发现更多潜在的攻击向量并帮助建立防御机制。 这一事件也给整个技术行业敲响了警钟。在我们急于采用新技术来提高效率的同时,不能忽视随之而来的安全风险。llms.txt文件代表了AI与网页内容交互方式的一种创新,但这种创新必须在安全的前提下进行。

随着AI技术继续渗透到各个行业,我们需要建立更加完善的安全框架来应对新兴的威胁。 对于普通用户和开发者而言,最重要的教训是要保持警惕。即使是来自官方或可信来源的指令,也需要经过审慎的考虑和验证。在AI越来越深入地参与我们的工作和生活之际,培养这种安全意识将成为每个人的必要技能。 总的来说,llms.txt漏洞的发现揭示了AI安全领域的一个重要盲点。这个问题涉及到信任模型的设计、指令解析的机制、安全验证的缺失以及整个生态系统的协作。

只有通过技术开发者、安全研究人员、企业管理者和终端用户的共同努力,才能有效地应对这一挑战,确保AI技术能够在安全的轨道上持续发展。 。