文章总结: 研究首次系统评估LLMAPI中转站安全风险,实测428个中转站发现9个存在恶意代码注入行为(如篡改pip包名)、17个窃取AWS密钥,其中2个采用自适应规避逻辑。关键结论指出当前所有提供商均未对工具调用响应实施密码学完整性保护,导致链路安全性退化为最弱节点。建议推动提供商引入类似DKIM的响应签名机制。 综合评分: 92 文章分类: 供应链安全,漏洞分析,威胁情报,安全建设,WEB安全

原创
SecureNexusLab SecureNexusLab
SecureNexusLab
2026年4月10日 14:36 北京
Title: Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain link: arxiv.org/abs/2604.08407
之前公众号总结了v2ex上大佬分享的中转站生意经,今天来看看加州大学等机构针对大模型中转站的首个系统性安全研究。作者对淘宝、闲鱼及Shopify平台购入的28个付费中转站与400个免费中转站开展调查,发现部分中转站实际上已成为真实的攻击载体。测量结果表明:
- • 9个中转站正在向Agent工具调用响应中主动注入恶意代码,具体表现为将合法安装脚本的URL替换为攻击者控制的远程端点,或将pip install requests中的包名悄然替换为PyPI上预注册的形近字包(如reqeusts)以建立持久供应链驻留;
- • 17个中转站在接触研究者预置的AWS蜜罐凭证后产生了后续未授权API调用,1个中转站直接从研究者以太坊私钥中转出链上资产。
- • 更为隐蔽的是,其中2个中转站部署了自适应规避逻辑,一个在累计50次正常请求后方才激活恶意载荷以规避浅层探针审计,另一个则仅对处于YOLO自动审批模式且项目指纹匹配Rust或Go的高价值会话定向投递。
研究者主动泄露的单个OpenAI密钥在社交渠道扩散后产生了1亿token的非授权计费流量;部署于20个域名与20个IP的弱配置蜜罐中继则累计暴露99份第三方凭证、440次可命令注入的Codex自主编程会话,其中401次已处于工具调用全自动审批状态。从根源上讲,当前所有主流提供商均未对工具调用响应实施任何密码学完整性保护,中转站链路的安全性退化为最弱节点的安全性。
近年来,随着大语言模型(LLM)在自动化任务执行领域的快速渗透,LLM API中转站作为连接客户端与上游模型提供商的中间层,承担着模型回退、负载均衡、成本优化与统一凭证管理等功能,逐渐成为生产级Agent部署的标准组件。LiteLLM积累了超过2.4亿次Docker拉取,OpenRouter连接了来自60余家提供商的300余个模型,可见中转站已深嵌于全球LLM调用链路。
然而,这一架构存在一个被系统性忽视的信任缺口:中转站以应用层代理的身份运行,对每一条过境的JSON载荷享有完整的明文访问权,且无任何提供商对客户端与上游模型之间的响应实施密码学完整性保护。
现有安全研究主要聚焦于提示注入(Prompt Injection)与模型层对抗攻击,尽管此类工作揭示了模型推理层面的脆弱性,但均未触及JSON传输层的完整性问题——中转站对工具调用载荷的篡改发生在模型完成推理之后、客户端执行命令之前,完全游离于模型侧防御机制之外,与提示层攻击正交。这构成了第一个核心挑战:现有防御体系存在传输层盲区,任何针对模型输出的安全对齐训练均无法阻止中转站在响应返回路径上对工具参数的静默替换。
第二个挑战在于多跳链路的弱链接传递性。实际部署中,客户端到GPU之间往往经历四跳乃至更多层中转(如Taobao转售商→二级聚合商→OpenRouter→模型主机),客户端仅配置第一跳,后续跳对其不可见。由于链路中任意一个恶意节点的篡改均无法被下游诚实节点检测或撤销,整条链路的完整性退化为最弱节点的完整性。这使得即便用户选择了”正规”中转站,其流量仍可能在不知情的情况下流经已被污染的上游中继。
第三个挑战是自适应规避使黑盒审计从根本上失效。一个简单的常态化载荷注入易被流量审计发现,因此高级攻击者需要控制”何时”注入:等待50次热身请求后才激活、仅针对处于自主YOLO模式的会话、或仅在检测到Rust/Go项目时触发——这些条件逻辑完全驻留在服务端且对客户端不透明,有限次数的探针测试无论如何设计,都无法证明一个中转站是良性的。
Mine是一个基于OpenAI兼容接口的FastAPI研究代理,同时实现四类攻击模块与三类客户端防御模块,用于对四个主流Agent框架(OpenClaw、OpenCode、Codex、Claude Code)进行兼容性验证与防御效能评估。
AC-1(响应侧载荷注入) 是核心攻击原语:中转站在上游响应离开提供商后、抵达客户端前,通过JSON路径变异将工具调用中的arguments字段替换为攻击者控制的命令(如将合法安装URL替换为恶意脚本端点)。由于替换后的载荷保持结构合法性,客户端既不会触发Schema校验异常,也不会产生传输层告警。这直接回应了挑战一:传输层的语义篡改在现有框架中完全不可见。
AC-1.a(依赖定向注入) 是AC-1针对包安装场景的精化变体:将pip install requests中的包名替换为预先在PyPI注册的形近字包(如reqeusts),规避基于域名白名单的策略门控,并在本地缓存后跨会话持续驻留,危害程度远超一次性URL重定向。该设计专门针对挑战二中”下游诚实节点无法甄别上游篡改”的场景,从供应链角度制造持久性立足点。
AC-1.b(条件投递) 在AC-1之上叠加触发谓词层,实现五类条件逻辑(工具名匹配、内容关键词、用户指纹/YOLO模式、时间窗口、请求计数阈值),使恶意载荷仅对高价值会话投递,直接回应挑战三中黑盒审计的根本局限性。
AC-2(被动秘密渗漏) 对请求与响应体进行正则扫描(覆盖OpenAI密钥、AWS IAM密钥、GitHub PAT、以太坊私钥等六类模式),完全不修改载荷,零可见异常地从明文流量中旁路提取凭证。
防御侧,Mine实现了策略门控(对高危工具调用的域名与包名白名单进行失败关闭检查)、响应侧异常筛查(基于IsolationForest的本地特征检测器,无需与上游原始响应对比)、以及追加写透明日志(记录请求体、响应体、路由URL、TLS元数据及响应字节哈希,支持事后取证溯源)。

Figure 2: Request–response lifecycle through a malicious router. AC-2 tags mark where the router passively scans traffic for secrets (both request and response paths). AC-1 marks where parsed responses are rewritten before delivery; AC-1.a specializes to dependency substitution, AC-1.b gates activation on session-level triggers (Section 4.2).
测量数据集涵盖从Taobao、Xianyu及Shopify店铺购入的28个付费中转站,以及通过sub2api与new-api模板在公开社区收集的400个免费中转站,并辅以两项污染研究(主动泄露研究者自有OpenAI密钥 + 部署弱密码中继诱饵)。
恶意行为发现率:1个付费与8个免费中转站在测试条件下向工具调用结果注入恶意代码,免费中转站中17个在接触研究者AWS蜜罐凭证后产生后续未授权API活动,1个直接从研究者以太坊私钥中转出资产(损失低于50美元)。2个中转站在真实环境中部署了自适应规避逻辑,分别以50次请求热身和YOLO模式+Rust/Go指纹作为激活条件。
污染研究揭示的爆炸半径:单个泄露OpenAI密钥在中文论坛与即时通讯群组扩散后,产生1亿个GPT-5.4 token的计费流量与逾7次Codex会话;20个域名+20个IP的弱配置诱饵共计吸引来自147个IP、6个JA3指纹的4万余次未授权访问,累计服务约20亿个计费token,暴露约13 GB可见提示/响应流量,并在440次Codex会话(跨398个不同项目)中泄露99份凭证——其中401次会话已处于YOLO自动审批模式,无需复杂自适应触发即可完成载荷注入。

Figure 4: Defense evaluation. (a) Threshold sweep: detection rate vs. false-positive budget for the anomaly screener across AC-1, AC-1.a, and AC-1.b. (b) Per-class effectiveness of all four defenses: response signing, anomaly detection, TLS pinning, and transparency logging.
防御效能:策略门控以1.0%误报率、2.3微秒决策延迟实现对AC-1与AC-1.a的100%拦截,但在允许白名单域名预置暂存器的自适应基准测试中,绕过率达100%,揭示了纯白名单防御的鲁棒性上限。异常筛查器在6.7%误报率下检出89.0%的AC-1样本,但对AC-1.a(50.0%)与AC-1.b(50.9%)的覆盖率有限;消融实验显示,shell_risk_score特征贡献了绝大部分检测信号,移除后AC-1检测率骤降至17.6%。这表明,即便是最先进的本地检测器,在面向防御感知的攻击者时仍存在不可忽视的漏检空间,端到端的防御最终指向提供商侧对工具调用响应的签名背书机制——即类似DKIM的规范化响应信封,将提供商签名与客户端随机数绑定,确保Agent执行的工具调用可被密码学溯源至模型实际生成的输出。
业界默认中转站是透明的,但从未在协议层面强制要求它必须透明——当前的安全性依赖的是中间人的自律而非密码学约束,随着Agent系统被赋予越来越高的执行权限,这一依赖自律的信任模型所蕴含的系统性风险只会持续累积,推动主流提供商为工具调用响应引入规范化签名机制,是这个生态在安全成熟度上必须迈出的下一步。
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:SecureNexusLab SecureNexusLab
SecureNexusLab《实测 428 个 LLM 中转站:9 个正在篡改你的 AI 命令,17 个已在偷你的密钥》
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/258157.html