跳转到主要内容
Chinese, Simplified

category

Pynt的最新研究分析了从开放代理框架和插件堆栈中收集的281种微控制器平台(MCP)配置。微控制器平台(MCP)作为人工智能代理与其控制的API、工具或执行环境之间的连接器。虽然每个插件本身看似安全,但无害的组合可能会创建绕过传统安全检查的隐形攻击面。

本研究重点关注不可信输入和特权操作在现实世界系统中如何相互交织。在多个实际案例中,一条精心编制的Slack消息或电子邮件即可在无人干预的情况下触发后台代码执行。随着微服务组合(MCP)演变为现代软件的执行层,其风险现已与传统应用程序编程接口(API)相当甚至更高,但攻击速度更快、更隐蔽,也更难检测。


主要发现

  • 超过70%的MCP插件暴露了攻击者可以利用的强大操作
    72%的MCPs允许执行敏感操作,如写入磁盘、执行代码或调用高权限API。大多数此类平台缺乏审批检查点或运行时验证。
  • 仅两个MCP插件就能将漏洞利用风险推至36%
    将一个处理不受信任输入的MCP(主控制处理器)与另一个具有特权执行权限的MCP结合使用,可能会为漏洞利用提供可乘之机。如果系统中存在三个MCP,则风险将跃升至50%以上。
  • 安装10个MCP插件会使漏洞利用风险达到92%
    在基于MCP的系统中,风险会迅速增加。在没有隔离或验证的情况下添加插件会使代理极易受到攻击。
  • 十分之一的MCP插件完全可被利用,而一个系统中如果有三个MCP,则发生无声利用(即未被察觉的利用)的几率超过50%

这些插件将攻击者控制的输入与特权执行相结合。

  • 大约八分之一(13%)的MCP插件会接受来自网络爬虫、Slack或电子邮件等来源的攻击者控制的输入
    这些数据流使得攻击者能够注入恶意内容,而这些内容会被代理自动处理,无需人工审核。
  • 9%的MCP插件将不受信任的输入与特权执行权限结合在一起
    这些真实世界的代理可以在无需利用零日漏洞、定制恶意软件或横向移动的情况下被充分利用。
  • 一个基于真实世界MCP的代理,无需用户输入,直接将攻击者提供的HTML执行到shell中
    它检索远程HTML,将其输入到shell插件中,并自动运行代码。
  • 另一个基于MCP(多命令执行)的代理通过与代码解释器配合使用的电子邮件接收插件触发了静默代码执行
    一封精心编写的电子邮件触发了命令注入,进而导致代码执行。


MCP组合风险:隐藏的乘数效应


三张图表显示了MCP组合风险的高风险百分比:1个MCP为9%,3个MCP为52%,10个MCP为92%。
单个插件可能看似无害。但将两三个插件组合起来,突然之间,你就拥有了一个无人干预的攻击面。这是对开放代理生态系统中281个真实世界MCP(恶意控制点)的分析结果:
 

Risk Factor Finding
MCPs exposing high-privilege actions 72%
MCPs accepting attacker-controlled inputs 13%
Risk with 2 MCPs in a system 36%
Risk with 3 MCPs in a system 52%
Risk with 10 MCPs in a system 92%



这是因为多氯联苯(MCPs)具有两种危险特性:

  • 不可信输入,如爬取的网页内容、电子邮件和Slack消息。
  • 特权操作,如写入磁盘、执行shell命令或调用API。

当这些特性交织在一起时,即使是基本的代理也会成为可编程的后门。


MCP展现的是真实攻击,而非理论缺陷


这不是一个理论问题。我们观察到的主体是:

  • 接收攻击者提供的HTML,对其进行解析,并通过shell插件执行。
  • 通过与代码解释器配合使用的电子邮件接收插件,从精心编制的电子邮件中触发代码执行。
  • 回复了一条精心编写的Slack消息,该消息通过已连接的自动化插件执行终端命令。

这些设置并非奇特。它们反映了代理生态系统中常见且经常被推荐的配置。
在一个案例中,我们使用Claude来攻击Claude,来看:
https://youtu.be/TEpgnTgOqIY


从API到执行:MCP需要一种新的安全模型


MCP正成为软件的新执行层,在关键工作流程中悄然取代传统应用程序编程接口(APIs)。APIs公开数据和功能,而MCPs则触发操作。许多MCPs在本地环境中运行,具有深度系统访问权限,且几乎不受监督。


适用于应用程序编程接口(API)的安全假设在此并不适用。风险不仅在于权限,更在于组合。一个插件抓取数据,另一个插件解析数据,而第三个插件则执行数据。


该图展示了电子邮件和网页内容如何导致提示注入或HTML插件,从而执行代码或shell命令。


我们之前已经见过这种模式。API的过度扩张导致了数据泄露和权限提升。现在,代理的过度扩张正在带来执行风险,只是这一次,它更快、更隐蔽,也更难被发现。大多数MCP缺乏隔离、运行时验证或审批检查点。静态检查无法捕捉到这些问题。我们需要的是一种链式感知、上下文敏感的验证方法,将微服务组合视为活动代码。
 

接下来是什么


安全团队应从设计层面着手,降低组合风险。建议采取以下措施:

  • 使用MCP主机审批功能,要求用户对每次服务器调用进行确认。
  • 仅启用当前正在使用的MCP服务器和工具,以限制暴露风险。
  • 隔离执行以控制高权限操作的波及范围。

深入阅读完整研究报告 https://www.pynt.io/resources-hub/mcp-security-research-2025
 

本文地址
最后修改
星期五, 八月 22, 2025 - 16:22
Article