AI 代理安全审计：从 MCP 渗透测试到 LLM 漏洞评估
AI 代理和 MCP（模型上下文协议）服务器的快速采用引入了全新的攻击面，而传统安全工具从未针对这些场景设计。过去 90 天，我们的研究团队对 10 个主流 AI 框架进行了系统的AI 安全审计，涵盖 CrewAI、AutoGen、LlamaIndex、LangGraph、Dify 和 Haystack 等，揭示了影响生产级 LLM 系统的 24 种不同漏洞模式。
本文分享我们的方法论、主要发现，以及为运行LLM 漏洞评估项目的团队提供的实用建议。
新攻击面：AI 代理为何不同
传统 Web 应用安全聚焦于注入、身份验证失效和配置错误。AI 代理引入了三类全新的风险类别：
- 工具级完整性失效 — 代理可能被诱骗使用恶意参数调用内部工具，绕过人工审核保护机制
- 提示到代码的升级 — 用户提示通过代理推理循环被转换为系统命令执行
- MCP 协议级绕过 — 代理服务器转发工具调用时未验证意图或范围
在我们的MCP 渗透测试实践中发现，超过 60% 的 MCP 服务器实现缺乏对工具执行的基本访问控制——任何连接的客户端都可以调用任意已注册的工具，包括伪装成只读调用的破坏性写操作。
CCS 方法论：24 条规则、10 个框架、4 个平台
我们的组件正确性标准 (CCS) 扫描器使用按漏洞类别组织的 24 条检测规则：
| 类别 | 规则数 | 覆盖范围 |
|---|---|---|
| 代码注入（Python/JS/Shell） | 6 | 通过 eval/exec/spawn/subprocess 实现 RCE |
| 路径遍历 | 4 | 文件操作中未清理的用户输入 |
| SSRF/开放重定向 | 3 | 代理工具调用中未验证的 URL |
| 不安全反序列化 | 3 | Pickle/yaml/JSON 解析器滥用 |
| SQL 注入（格式化字符串） | 2 | 动态查询构造 |
| 凭证泄露 | 2 | 源码中硬编码的令牌 |
| MCP 特定（readOnlyHint 绕过） | 2 | 协议级授权漏洞 |
| 供应链（npm/PyPI 混淆） | 2 | 依赖混淆向量 |
该扫描器已在 80,000 条 API 追踪（20,000 条公开验证 + 60,000 条保留）上验证，覆盖 13 家提供商和 33 个模型。性能基准显示每条规则评估的 P50=22µs 和 P99=99µs，适合运行时防护部署。
真实发现
我们的框架集成活动（2026 年 7 月）在多个知名项目中确认了漏洞：
| 项目 | 漏洞 | CVSS 等效 | 状态 |
|---|---|---|---|
| Revis（蚂蚁集团） | 路径遍历 | 7.5（高危） | 已提交至蚂蚁 SRC（QTVA-2026-10862552） |
| CodeAnalysis（腾讯） | 通过 task_id 的路径遍历 | 7.5（高危） | 已提交至腾讯 SRC（QTVA-2026-10862567） |
| Monolith+verl（字节跳动） | 工具参数注入 | 7.0（高危） | 已提交至字节 SRC（QTVA-2026-10862588） |
| LLaMA-Factory（360） | 通过模型加载的 SSRF | 7.5（高危） | 已提交至 360SRC（QTVA-2026-10862618） |
| Light-R1（深度求索） | 路径遍历 | 7.0（高危） | 已提交至 360SRC（QTVA-2026-10862636） |
| fdp-mcp-server | 缺少 readOnlyHint 检查 | 7.5（高危） | 已提交至补天 |
| Dify | SQL 注入（f-string） | 8.0（高危） | 已提交至补天（QTVA-2026-10861217） |
| Stripe-MCP | 元数据注入 | 7.0（高危） | 已提交至补天（QTVA-2026-10861865） |
所有发现均通过负责任披露渠道提交，包括补天、HackerOne、Bugcrowd、ZDI 和 MSRC——实现了 100% 提交流程自动化。
深入剖析：MCP 安全审计案例研究
案例 1：fdp-mcp-server — readOnlyHint 绕过
在对 MCP 代理实现的AI 安全审计中，我们发现 fdp-mcp-server 的 _call_tool 函数（位于 proxy_server.py:87）将所有工具请求转发给后端，但未检查 readOnlyHint 标志：
async def _call_tool(req: types.CallToolRequest) -> types.ServerResult:
result = await remote_app.call_tool(
req.params.name, (req.params.arguments or {})
)
return types.ServerResult(result)
Enter fullscreen mode Exit fullscreen mode
MCP 协议规范将 readOnlyHint 定义为 ListToolsResult 返回的 Tool 对象上的字段，用于表示只读意图。由于代理从未验证此标志，攻击者即使在客户端配置为只读访问时，也可以通过代理调用破坏性写操作。
影响：任何缺乏 readOnlyHint 验证的 MCP 代理服务器都会实质上使协议的访问控制机制失效。这影响了所有将 fdp-mcp-server 用作透明代理的部署。
案例 2：CodeAnalysis 路径遍历（腾讯）
CodeAnalysis 客户端的 taskdirmgr.py 使用 os.path.join() 直接从服务器 API 响应中获取的 task_id 构造文件路径：
def acquire_task_dir(self, task_id):
task_dir = os.path.join(self._task_dirs_root, f"task_{task_id}")
os.makedirs(task_dir, exist_ok=True)
return task_dir, task_id
Enter fullscreen mode Exit fullscreen mode
由于 task_id 在 looprunner.py:204 来自 task_request.get('id') 且未做任何验证，控制或 MITM 服务器的攻击者可以提供 ../../etc/evil 作为任务 ID，导致在预期工作区之外创建任意目录。该漏洞已在 Linux 和 Windows 环境中确认。
构建您的 LLM 漏洞评估流水线
基于我们在 10 个框架集成和 80K 条 API 追踪中的经验，以下是在规模化运行LLM 漏洞评估的实用方法：
第一阶段：静态分析（24 条规则）
针对您的代理代码库运行 CCS 规则集：
-
代码注入检查器：grep 搜索带有用户输入的
exec()、eval()、subprocess.Popen() -
路径遍历检查器：识别带有未清理参数的
os.path.join()或Path()调用 - 凭证扫描器：正则匹配 API 密钥、令牌和硬编码密钥
-
MCP 协议检查器：验证
readOnlyHint和工具注册表访问控制
第二阶段：动态测试
针对每个静态发现：
- 使用最小 PoC 重现以证明漏洞
- 记录完整攻击链（不仅是代码位置）
- 在受控测试环境中验证影响
第三阶段：负责任披露
通过适当渠道提交发现：
- 开源项目：GitHub Advisory + 直接联系维护者
- 企业 SRC：针对中国厂商提交至蚂蚁 SRC/腾讯 SRC/字节 SRC/360SRC
- 漏洞奖励：符合条件的项目提交至 HackerOne / Bugcrowd
- ZDI/MSRC：针对 Microsoft 生态系统漏洞
AI 代理安全的未来方向
AI 安全态势的发展速度超过大多数组织的应对能力。基于我们的研究管线，我们关注以下三大领域：
- 代理间协议安全 — 随着多代理系统发展，代理间通信通道成为主要攻击面
- LLM 依赖的供应链审计 — 模型加载、LoRA 适配器下载和插件生态系统基本未经验证
- 运行时防护绕过 — 即使有输入验证，巧妙的提示工程仍可能绕过安全层
如果您的团队正在运行AI 安全审计或需要针对部署进行MCP 渗透测试，我们的 CCS 扫描器和方法论已作为开源工具提供。24 条检测规则同时驱动我们的公开扫描器和企业审计服务。
本研究由 Correctover 安全团队完成。CCS 扫描器可在 GitHub 的 github.com/Correctover/ccs-scanner 获取。企业安全审计请联系 [email protected]。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.