窃取 MCP 服务器存储的长期凭证

作为我们 MCP 安全系列第四篇文章，本文研究的漏洞不同于之前讨论的协议层缺陷：许多 MCP 环境将第三方服务的长期 API 密钥以明文形式存储在本地文件系统，且常配置不安全的全局可读权限。该漏洞影响所有连接到 LLM 应用的系统，MCP 环境功能越强大，不安全存储凭证的风险就越高。

这一现象在 MCP 生态中极为普遍。我们在多个工具中观察到该问题，从连接 GitLab、Postgres 和 Google Maps 的官方服务器，到 Figma 连接器和 Superargs 包装器等第三方工具。攻击者只需利用文件泄露漏洞即可窃取 API 密钥，进而完全控制第三方服务中的数据。常见攻击方式包括：

• 本地恶意软件：用户级恶意程序通过扫描固定路径（如~/Library/Application Support/、~/.config/或应用日志）窃取凭证

• 其他漏洞利用：利用同一系统上其他软件的任意文件读取漏洞获取明文凭证

• 多用户系统：在共享工作站或服务器上，其他用户可直接读取全局可读文件中的凭证

• 云备份：自动备份工具可能将服务器配置文件同步到云存储，因配置不当导致凭证暴露

凭证窃取路径分析

路径 1：不安全的配置文件

多数 MCP 服务器通过命令行参数或环境变量获取凭证，这些参数通常源自宿主 AI 应用管理的配置文件。我们在 Google Maps、Postgres 和 GitLab 的官方 MCP 服务器中均发现该模式。

以 Claude Desktop 为例，其在用户主目录创建claude_desktop_config.json文件，在 macOS 上该文件具有全局可读权限：

$ ls -la ~/Library/Application\ Support/Claude\ Desktop/claude_desktop_config.json-rw-r--r--  1 user  staff  2048 Apr 12 10:45 claude_desktop_config.json

路径 2：聊天日志泄露凭证

另一种常见模式是用户直接将凭证输入 AI 聊天界面，依赖模型将其传递给 MCP 服务器。Supercorp 的 Superargs 包装器就明确支持这种模式。

该方法存在双重风险：恶意 MCP 服务器可直接从对话历史窃取凭证；宿主 AI 应用通常会将完整对话历史（含嵌入凭证）记录到本地日志文件。例如 Cursor 和 Windsurf 应用将对话日志存储为全局可读文件：

$ ls -la ~/.cursor/logs/conversations/-rw-r--r--  1 user  staff  15482 Apr 15 12:23 conversation_20240415.json

风险叠加案例：Figma 连接器

某些实现会同时暴露两种攻击路径。社区提供的 Figma MCP 服务器允许用户通过工具调用设置 API 令牌，但随后会使用 Node.js 的fs.writeFileSync函数将凭证保存到用户主目录的配置文件中。该函数默认创建权限为 0666（-rw-rw-rw-）的文件，使得存储的 Figma 令牌全局可读（根据用户 umask 设置可能还可写）。

安全凭证管理方案

改进凭证存储方式需要多方协作：

1. 第三方服务应增加 OAuth 支持，包括窄范围短期令牌

2. MCP 开发者应优先使用操作系统提供的凭证存储 API（如 Windows 凭据管理 API 和 macOS 钥匙串）

3. 终端用户应审慎选择软件，或手动收紧 AI 软件遗留敏感文件的权限

随着 MCP 逐渐成为强大 AI 系统的基础框架，我们必须扭转"安全后置"的开发模式，从设计之初就将安全凭证处理作为最高优先级。更多精彩内容 请关注我的个人公众号 公众号（办公 AI 智能小助手）公众号二维码

办公AI智能小助手