| name | MCP配置投毒测试 |
| description | 测试AI IDE的MCP配置投毒问题。适用于审查IDE是否会从工作区自动加载 不可信MCP服务器定义,以及审批与调用控制是否存在缺陷。评估按四个交互 层级展开,从零交互自动加载到已信任工作区中的TOCTOU。
|
MCP配置投毒测试
本skill专门讨论MCP服务定义会不会被不可信工作区劫持。
重点不只是能不能配置MCP,还包括:
- 是否会自动发现工作区里的MCP配置
- 未信任工作区是否也会读取
- 批准是按什么粒度记忆
- 配置被改掉以后是否还会沿用旧审批
- 工具调用前后有没有再次校验
什么时候用
- 侦察阶段已经发现MCP、配置文件、workspace规则、Agent设置等入口
- 目标产品支持本地或远程MCP服务定义
- 想验证零交互加载、审批绕过、名称复用、路径替换、TOCTOU
- 需要为攻击链补从配置到执行的一跳
交互层级
| 层级 | 说明 |
|---|
| Tier 1 | 打开仓库就自动加载恶意MCP配置 |
| Tier 2 | 用户正常发消息,Agent开始使用恶意工具 |
| Tier 3 | 用户必须明确批准一次工具或服务器 |
| Tier 4 | 需要先信任工作区,再通过更新、拉取、替换等方式二次触发 |
重点测试事项
1. 自动发现
- 会在哪些路径找MCP配置
- 文件名是否固定
- 是否会递归搜索
- 打开工作区时是否立即读取2. 信任边界
- 未信任工作区是否也会解析配置
- 只解析不执行和直接可用之间是否有模糊地带
- UI是否清楚提示配置来源3. 审批模型
- 批准是按服务名、路径、命令行、内容哈希,还是只按一次记忆
- 改名、改路径、换参数后是否要重新批准
- 批准后内容被替换,是否仍会沿用旧状态4. 工具调用链
- 模型是否能在普通对话中自然触发恶意工具
- 工具列表是否直接来自工作区配置
- 工具调用前是否做二次校验
推荐流程
- 先找配置格式与位置。 应先确认其读取位置,再分析读取后的处理行为。
- 验证是否自动加载。
测试应从未信任工作区状态开始,不应跳过关键的零交互场景。
- 再测审批行为。
应分别记录首次批准、重启后以及配置变更后的行为差异。
- 最后测链式影响。
例如:恶意MCP能否进一步实现命令执行、数据外传、持久化。
常用风险模式
- 工作区中的恶意MCP配置被自动导入
- 审批按名字记忆,内容替换后仍被信任
- 批准一次后,后续
git pull引入新命令仍可执行
- UI只提示有MCP,但不提示真实命令或参数
可优先参阅的资料
references/config-formats.md
references/payload-templates.md
references/known-vulns.md
输出表述建议
最终结论宜表述为:
- 配置入口:文件放哪、叫什么、谁会读
- 触发条件:打开即触发,还是交互后触发
- 审批行为:批准绑定到什么对象
- 变更后行为:配置被替换后是否重新校验
- 最终影响:能否执行、外传、持久化