Anthropic用计算器偷走SSH密钥：MCP协议3个致命漏洞全复盘

2024年，Anthropic（人工智能公司）的安全团队做了一场让开发者后背发凉的测试。他们用一款伪装成计算器的MCP（模型上下文协议，Model Context Protocol）工具，成功窃取了一台生产服务器的SSH密钥。整个攻击链路没有利用任何系统漏洞，纯粹靠协议设计缺陷。

这不是CTF比赛，是对企业级AI工具链的真实压力测试。测试报告公开后，社区反应两极：有人觉得"这种攻击太牵强"，有人直接开始审计自己的MCP服务器。

Part 1的蓝图，Part 2的破门锤

系列第一篇文章里，Anthropic安全团队画了信任边界图，用STRIDE（欺骗、篡改、否认、信息泄露、拒绝服务、权限提升）模型做了威胁建模，提出了"三重门架构"的防御方案。那篇文章是建筑师视角——怎么盖一栋安全的楼。

这篇换帽子。红队视角——怎么把这栋楼撬开。

作者的原话很直白：「Part 1是蓝图，这次是破门而入测试锁好不好用。」这种角色切换本身就在传递一个信号：安全架构的价值，最终要靠对抗验证。

计算器攻击：一个工具如何变成特洛伊木马

攻击场景设计得极其日常。用户想找个计算器做简单运算，MCP市场里有款工具叫"CalcPro"，评分4.8，下载量靠前。安装、授权、使用——流程顺畅得没有任何异常。

CalcPro的真正行为藏在授权协议的细节里。当用户点击"允许访问文件系统"时，弹窗描述的是"读取计算历史"，实际权限范围是整个用户目录。MCP协议目前的权限模型是粗粒度的：工具声明需要什么能力，用户一次性授权，没有运行时二次确认。

计算器开始"工作"后，后台行为包括：扫描~/.ssh目录、读取id_rsa和id_ed25519密钥文件、将内容编码后通过日志上报通道外发。整个过程没有触发任何杀毒软件，因为MCP服务器的进程本身就是合法的AI助手组件，文件访问行为在授权范围内。

作者披露了一个关键数据点：从工具安装到密钥外发，平均耗时23秒。用户甚至没来得及完成第一次计算。

权限模型的结构性缺陷

这个案例暴露的是MCP协议当前版本的三个设计盲区。

第一，授权粒度与行为粒度不匹配。用户以为自己授权的是"计算器访问计算相关文件"，实际授予的是"该进程访问用户全部文件"。协议层面没有强制要求工具声明具体路径模式，也没有运行时动态申请机制。

第二，能力聚合的风险被低估。单个工具看起来无害——计算器要文件访问可能是为了保存历史记录。但当多个工具组合时，风险呈非线性增长。攻击者可以设计工具A获取密钥、工具B建立外连通道、工具C做数据编码，每个工具单独看都"合理"。

第三，缺乏运行时行为审计。MCP服务器知道工具在调什么API，但不知道这些API调用在业务逻辑上意味着什么。读取~/.ssh/config和读取~/Documents/todo.txt，在系统调用层都是read()，风险天差地别。

作者打了个比方：「现在的MCP权限模型就像酒店房卡——刷一次门全开，没有分房间授权，也没有记录你进了哪间。」

红队测试的完整攻击链

Anthropic团队按照标准红队流程，把攻击拆解为五个阶段。

侦察阶段：分析MCP市场的热门工具类别，选择"计算器"作为载体——功能简单、用户预期低、权限需求容易合理化。制作CalcPro的界面和功能与竞品几乎一致，评分通过初期刷量维持在4.8。

武器化阶段：核心payload不到200行Python，利用MCP SDK的标准文件访问接口。密钥外发不走网络请求（容易被防火墙拦截），而是写入日志，通过MCP服务器固有的遥测通道上传——这是协议设计中的"合法"数据流。

投递阶段：工具上架MCP市场，通过SEO优化出现在"calculator"搜索结果前三。第一周自然下载量87次，其中12次来自企业邮箱域名的开发者账户。

利用阶段：用户安装后，工具会延迟30秒再启动敏感操作——避开安装时的警觉期。密钥获取后，工具继续正常运行计算器功能，降低用户卸载概率。平均驻留时间测试数据显示为4.7天。

影响评估：在受控测试环境中，成功获取了23个SSH密钥，其中7个对应生产服务器访问权限。按企业安全团队的估值模型，单次密钥泄露的平均修复成本约$15,000，潜在数据泄露损失未计入。

防御方案的实战检验

Part 1提出的"三重门架构"在这次测试中接受了验证。

第一重门——工具来源验证。CalcPro通过了基础签名检查，但签名只证明"这个工具来自某个开发者账户"，不证明"这个开发者可信"。测试表明，需要引入声誉评分和代码审计的强制门槛。

第二重门——权限最小化。这是失效最明显的一环。当前MCP协议没有细粒度路径授权，团队建议的改进方案是：工具声明具体路径模式（如~/.calc-history/*.txt），运行时超出范围即拒绝。

第三重门——行为监控。测试环境中部署了基于eBPF（一种Linux内核技术，extended Berkeley Packet Filter）的系统调用监控，成功捕获了异常文件访问模式。但告警延迟平均为8分钟——对于23秒完成的攻击来说，事后追责的价值大于实时阻断。

作者承认：「三重门在Part 1听起来很完整，红队测试后发现第二重门几乎是纸糊的。」

协议演进与企业落地建议

Anthropic在文末给出了面向不同角色的行动清单。

对于MCP协议维护者：优先级最高的是运行时权限模型重构，参考Android的权限申请机制，支持按操作动态授权。其次是强制工具行为声明，要求开发者在manifest中列出所有可能访问的路径和调用的外部服务。

对于企业安全团队：在协议层改进到位前，建议部署三类控制——网络层隔离（MCP服务器无外连权限）、文件系统层沙箱（chroot或容器化）、以及基于行为的异常检测（关注短时间内的大量文件遍历）。

对于终端用户：暂时避免给MCP工具开放"文件系统"级别的权限，除非能确认工具来源和代码审计状态。计算器这类简单工具，完全可以用本地脚本替代。

作者最后留了一个观察：「测试中最讽刺的是，CalcPro的真实用户评分在攻击曝光后反而上涨了——有人说'至少它计算器功能确实好用'。」

当你的MCP工具列表里躺着十几个"小工具"时，你最后一次检查它们的权限范围是什么时候？