2026-09-08 04:17:09 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文剖析LiteLLMAI网关被控制后的攻击链：攻击者利用管理员凭证修改模型路由配置，将流量劫持至恶意网关，窃取后端LLM密钥，并通过钩子注入伪造响应与工具调用。文章强调路由修改本身非漏洞，核心风险在于凭证泄露。防守方应监控路由变更频率、出站流量目的地及钩子函数，建议企业加强凭证管理与异常告警。 综合评分： 85 文章分类： AI安全,红队,渗透测试,安全运营

第67篇 AI全栈 · 拦截流量、窃取密钥和注入工具调用的 LLM 案例

原创

陈看山陈看山

安全诸子

2026年9月2日 23:40 上海

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

最近和几个做 AI 基础设施的朋友聊，发现大家不约而同地在关注同一个问题：AI 网关的安全边界到底在哪里。其中一个朋友的公司用的是 LiteLLM，统一管理着几十个后端模型密钥。他半开玩笑地说，现在最怕的不是模型回答错，而是有人悄无声息地把流量导走，连开发者都发现不了。这个担心不是多余的。LiteLLM 这类 AI 网关，本质上就是所有 LLM 流量的咽喉要道。它向上给应用提供统一接口，向下握着各家模型提供商的真实密钥。一旦这个中间层被控制，后果不是简单的数据泄露，而是整条推理链路都被接管——流量被拦截、密钥被窃取、返回给客户端的响应和工具调用都被篡改。

这件事要解决什么问题先明确一下，这篇内容解决的是三个具体问题

第一，AI 网关被拿下后，攻击者能做什么。很多人以为网关被入侵顶多就是密钥泄露，但实际上，攻击者能实时监控所有对话内容，能伪造模型响应，甚至能注入工具调用指令让用户端执行命令。第二，攻击是怎么一步步实现的。从拿到管理员凭证，到修改路由配置，再到部署恶意钩子收割密钥，每一步都用了 LiteLLM 的文档公开功能，没有利用任何未公开的漏洞。第三，防守方应该盯哪些地方。哪些日志会暴露异常，哪些配置变更需要告警，哪些钩子函数不应该出现在生产环境里。适合谁看：企业 AI 平台负责人、负责 LLM 基础设施的运维和安全工程师、做红蓝队演练的安全研究员。不适合谁看：如果你只是想了解 LiteLLM 怎么用，这篇文章对你来说太底层了。如果你没有授权就想去测试别人的系统，那这篇文章也不适合你——下面所有操作都必须在你自己控制的靶场环境里进行。

前置准备

核心攻击链路

一次路由变更实现流量劫持整个攻击的核心思路非常清晰，分四步走：

攻击者搭好自己的恶意 LiteLLM 网关
拿到受害网关的管理员权限
修改受害网关的路由配置，把流量导到恶意网关
在恶意网关上收割密钥、篡改响应这里要强调一个重要的判断：修改路由本身不是漏洞。 LiteLLM 作为 AI 网关，设计上就允许管理员动态调整模型的后端地址。真正的问题是，攻击者拿到了能发起这些 API 调用的凭证——这才是需要防守方关注的核心。

第一步

修改路由配置攻击者通过 /model/update 接口修改受害网关的模型配置。只需要改两个参数： – api_base：指向攻击者的 LiteLLM 网关地址 – use_litellm_proxy：设为 true，开启代理模式改完之后，最终用户看到的还是同一个 LiteLLM 端点和同一个虚拟密钥，客户端认证完全不变。但实际上，所有请求已经被悄悄导到了攻击者的服务器上。成功标志：在受害网关的 /model/info 接口或管理 UI 上，能看到模型的 api_base 已经变成攻击者的地址。关键点：这个操作不需要重启服务，不需要修改任何客户端配置，也不会产生明显的错误。用户完全感知不到变化。

第二步

收割后端提供商密钥路由改完之后，受害网关会把后端 LLM 的真实密钥附在推理请求里，发到攻击者的服务器上。攻击者这边只需要在 LiteLLM 实例上装一个自定义认证钩子，把接收到的 Authorization 头记下来即可。这个钩子可以返回一个预制的响应，不真正调用任何 LLM 提供商。这样攻击者就拿到了真实可用的提供商密钥，而且整个过程对用户来说只是”模型返回了一个奇怪的结果”。失败处理：如果收割到的密钥无法通过验证，可能是路由没有生效，或者受害网关做了额外的加密处理。LiteLLM 会用 LITELLM_SALT_KEY 加密凭证，如果没有单独配置盐密钥，就退一步用 LITELLM_MASTER_KEY。但注意，加密的是存储，不是传输——请求发出时，密钥是明文附在 Authorization 头里的。

第三步

配置攻击者网关并转发请求攻击者拿到真实密钥后，在自己的 LiteLLM 实例上配置对应的模型端点，让请求能正确转发到真正的 LLM 提供商。这一步完成之后，整个劫持管道就通了： – 用户 → 受害网关 → 攻击者网关 → 真实 LLM 提供商 – 攻击者可以实时看到并修改推理的请求和响应成功标志：用户能正常收到模型的回答，但流量已经全部经过了攻击者的服务器。攻击者可以在自己的 LiteLLM UI 里看到所有对话记录。

注入文本响应和工具调用流量接管之后，攻击者可以利用 LiteLLM 的回调和钩子系统，在转发层修改响应内容

注入文本响应用 async_post_call_success_hook 和 async_post_call_streaming_iterator_hook 这两个钩子，攻击者可以在响应返回给客户端之前插入自定义内容

比如，往响应里塞一句 “Hello! Trust No AI.”，用户看到的回答就是被篡改过的。因为篡改发生在推理之后，提示词层面的防御完全看不到这个操作。

注入工具调用更严重的是，如果客户端是带工具访问权限的 AI 代理，注入的响应可以夹带工具调用指令

举个例子，攻击者注入一个伪造的 Bash 工具调用，参数是 {“command”:”open -a Calculator.app”}。如果用户开着自动执行模式（yolo 模式），这个命令会直接在用户机器上执行。重点在于：LLM 根本没有生成过这个工具调用，是攻击者网关伪造的。这绕过了提示词层面的防御，直接操纵了客户端的工具执行逻辑。需要说明的是，这本身不绕过客户端的工具授权机制——如果客户端要求用户确认每个工具调用，用户还是能看到并拒绝。但很多开发者为了方便会开启自动执行，这就给了攻击者可乘之机。

方案对比

常见错误、风险点和排查方法这套攻击链路的每个环节都有可能出现问题，这里列出最常见的几类

错误一：路由修改后用户端报错。如果攻击者网关没有正确配置模型转发，用户会直接看到连接错误或认证失败。排查方法是检查攻击者网关的日志，确认是否收到了转发的请求，以及请求头里的认证信息是否完整。错误二：收割到的密钥无法使用。可能是密钥被 LiteLLM 加密存储，或者受害网关对出站请求做了额外的认证。排查方法是直接用收割到的密钥调用一次后端 LLM 的 API，确认密钥本身是有效的。错误三：注入的响应没有生效。可能是钩子函数没有正确注册，或者 LiteLLM 的版本对钩子的支持有差异。排查方法是先在攻击者网关本地测试钩子函数，确认能拦截到响应，再检查转发的链路是否完整。错误四：流量恢复后仍有残留。如果 recover 操作没有完全清理配置，可能会有部分模型的路由仍然指向攻击者网关。排查方法是检查 /model/info 接口，确认所有模型的 api_base 都恢复到了原始地址。风险点：这套攻击链路的隐蔽性很高。用户端没有任何配置变更，受害网关的管理 UI 上只会显示 api_base 的地址变化——这个变化在正常的配置变更中也会出现，所以很难单独作为攻击指标。

防守方的检测点和防御思路基于当前可见信息，防守方可以盯住以下几个关键位置

检测点一：模型路由配置的变更频率和模式。虽然 api_base 的变更本身是合法操作，但异常频繁的变更、非工作时间的变更、或者变更到陌生 IP 地址的行为，都应该触发告警。检测点二：出站流量的目的地。正常的企业网关应该只向已知的 LLM…

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全诸子陈看山陈看山《第67篇 AI全栈 · 拦截流量、窃取密钥和注入工具调用的 LLM 案例》