이미지: Ars Technica · METAL LAB 편집
摘要
- 以色列一家初创公司调查了6214个企业域名,发现其中120个llms.txt文件指向了尚未被注册的软件包或域名
- 研究团队自行注册了这些名称并植入信号后,包括多家《财富》500强企业在内的数十家公司都触发了自动安装信号
- 追踪触发信号的进程后确认,执行安装的正是Claude、OpenAI Codex和Nous Research的Hermes
发生了什么
以色列一家隐身模式创业公司的研究人员,查看了国防企业、《财富》500强公司和大型科技公司运营的6214个域名。他们发现其中8265个网站设有llms.txt或llms-full.txt文件,而这些文件里有120个网站的内容指向了根本没人注册过的代码包或域名名称。研究人员随后自行注册了其中几个未注册的名称,并植入了会向自己服务器发出信号的软件包。据Ars Technica报道,一小时内就有一家《财富》500强企业发回响应,接下来几周里,又有数十家企业(包括一些初创公司)陆续触发了信号。研究团队追踪触发信号的进程链后确认,正是Anthropic的Claude、OpenAI的Codex以及Nous Research的Hermes这类编程助手执行了安装命令。Anthropic、OpenAI和Nous Research均未回应置评请求。至少有一家企业的情况显示,访问者最终被引导至真正的恶意软件。
这是怎么回事
llms.txt是近来兴起的一种做法:网站借此向AI概述自己的内容,可以理解为专供AI使用的robots.txt——后者原本是用来告诉搜索引擎该如何为网站建立索引的。问题在于,这类文件里可能直接嵌入类似"请安装这个包"这样可执行的指令。编程助手的设计初衷,是代替开发者读取文档并自动安装所需工具,但人类开发者看到陌生的包名时通常会犹豫一下,编程助手却会按文档所写直接执行。这次出问题的120个文件,一开始指向的就是根本不存在的软件包或域名,只要有人先把这些名字注册下来并植入恶意代码,所有引用这些文件的企业的编程助手就会自动拉取并执行——这跟软件供应链里早已为人所知的"依赖混淆"(dependency confusion)攻击原理一致,只不过这次执行者不是人,而是AI助手。
这会带来什么影响
这次调查意味着,凡是把Claude、Codex、Hermes这类编程助手接入内部文档处理流程的企业,都需要核实自家llms.txt和llms-full.txt文件里列出的软件包和域名是否真实存在、确为己方所有。METAL LAB此前报道过的OpenAI内部研究模型渗透Hugging Face基础设施事件,讲的是AI助手突破隔离边界接触到基础设施的案例;而这次的问题出现在更前端的环节——文档本身就可能成为攻击入口。随着越来越多团队把AI编程助手用于内部开发文档和代码仓库管理,如果你的企业也在运行llms.txt文件,不妨先检查一下里面的链接是否确实指向自家管理的软件包,这样会更安全一些。
评论