文章总结： 本文介绍了作者在漏洞赏金计划中发现的MCP服务器权限绕过漏洞。通过搭建代理并调用MCP工具，低权限账户成功获取了租户内所有敏感对话和联系人数据。该漏洞揭示了MCP应用权限验证缺失的问题，并建议厂商严格校验集成服务的访问控制。 综合评分： 88 文章分类： 渗透测试,漏洞分析,SRC活动

---

0120.我是如何发现 MCP 服务器中一个罕见漏洞的——漏洞赏金计划

原创

1day 1day

Rsec

2026年1月20日 10:51 贵州

本文章仅用网络安全研究学习，请勿使用相关技术进行违法犯罪活动。

声明：本文搬运自互联网，如你是原作者，请联系我们！

类型：MCP权限控制

介绍

大家好，今天我又来和大家分享一个我在漏洞赏金计划中发现的非常酷炫且独特的漏洞。

这个漏洞来自 Bugcrowd 上一个著名的公开漏洞赏金计划。很遗憾，我不能透露这家公司的名称，我们暂且称其为“已编辑”或“redacted.com”。

REDACTED 是一个企业用来管理所有客户互动的平台。对于团队而言，它基本上是一个中心枢纽，支持人员、销售人员和其他团队成员可以在这里协作、回答问题并跟踪对话。

该平台采用租户模式，这意味着每家公司都有自己独立的独立工作区或租户。在这个漏洞赏金计划中，我们可以创建租户并分配任意角色，从而测试不同的访问级别和权限。

该平台功能繁多，但我们应该重点关注该平台中的两个关键实体。

对话： 团队成员与客户之间的所有消息，包括支持聊天、电子邮件或其他互动。

联系方式： 客户本身，他们可能来自任何地方，例如电子邮件、WhatsApp、Instagram、Facebook、网站等等。

团队使用角色和权限来管理谁可以看到什么，组织联系人，并通过收件箱、线程和自动化工作流程等功能处理对话。

语境

我在这个项目上花了将近两到三周的时间，试图找到一些非重复的漏洞。这是一个在 Bugcrowd 上颇有名气的公开项目，每天有 5 到 10 位研究人员获得报酬，但你找到的任何真正有价值的漏洞都可能被认为是重复的。我甚至一度发现了一个漏洞，但因为 100% 确定它是重复的，所以懒得去报告。

主要原因是这个应用程序是一个封闭的目标，你无法访问 *.redacted.com 来寻找隐藏的内容。好处是，我得以了解这个应用程序的方方面面，包括每个功能、每个配置，以及所有可能出错的地方等等。

在提交了12份报告后，发现全部都是重复的，于是我决定停下来，跳出固有思维模式思考。头几天我毫无头绪。后来，我对这家公司进行了深入研究，阅读了最新的博客文章，并关注了他们推出的新功能。

#

理解角色、权限和实际目标

了解 REDACTED 中访问控制的实现方式至关重要。该平台采用细粒度的权限模型，为每个团队成员分配明确定义的权限，这些权限决定了他们可以访问哪些资源以及可以执行哪些操作。

can_access_inbox ：允许用户访问对话（只读）

can_access_contacts ：允许用户访问租户内的所有联系人（客户信息）。 （只读）

以上仅是此应用程序中数百种权限中的两个示例。每项权限都会独立评估，并且必须启用才能让用户与相应的数据进行交互。

#

我的目标

我的目标是使用零权限帐户读取租户中所有敏感对话和每位客户的完整联系方式。

对于那些觉得操作功能繁多的应用程序很困难的人，以下是我处理这类应用程序的一种略显笨拙的方法：

CTF 方法

你可能觉得这很傻，但是……实际上……嗯……但这可以帮助你轻松找到已关闭应用程序中的权限绕过/逻辑缺陷。

首先，使用高权限账户向任何低权限账户不应访问的对话发送标记。例如，发送 FLAG{TH3_BYP455_W0RK3D} 或“IF YOU SEE THIS MESSAGE, IT WORKED！！ ”。这将帮助你轻松识别漏洞是否已被成功利用。

就我而言，我从管理员帐户向客户发送了一条消息，内容是“如果你看到了这条消息，说明它奏效了！！”

为了访问联系人，我向租户添加了一个新联系人（不是团队成员，而是客户联系人），名为“ Jack Bugcrowd ”。

让我们尝试用我们权限较低的账户正常访问这两个标志……

不！不出所料。现在我的最终目标是从受限对话和联系人数据中检索标记。

但是怎么做到的呢？

#

转折点

经过几个小时的谷歌搜索，我发现了一些非常有趣的东西。该公司最近为租户推出了一项新的 MCP 服务器集成功能，允许团队成员将 MCP 服务器连接到他们的帐户，并将其与任何 LLM（Claude、Copilot、Cursor 等）集成。

其他研究人员无法在应用程序本身中找到此功能。它需要按照我找到的那篇博客文章中提供的说明手动完成。所以我想，何不试一试呢……

#

什么是 MCP 服务器？

MCP 服务器是使用模型上下文协议 (MCP) 的程序，它向 AI 代理和 LLM 公开工具和数据等功能。

MCP 服务器与我们通常听到的 API 非常相似。它们本质上是 AI 模型和外部服务之间的桥梁，使 AI 能够与数据库、文件系统、API 和其他数据源进行交互，从而执行任务和检索信息。

在 MCP 服务器中，您可以使用多种工具来获取/执行不同的任务。工具类似于编程语言中的函数，有时需要提供参数才能执行操作，并且它会以特定格式返回一些数据。 （例如，使用客户 ID/姓名获取完整客户详细信息的工具）

在我们的案例中，MCP 服务器允许我们使用各种工具访问平台内部数据（例如对话和联系人） ，并将这些信息传递给 AI 模型以执行各种任务。它就像一座灵活的桥梁，使 AI 模型能够读取、处理和使用通常保留在应用程序内部的数据。

#

设置 MCP 服务器

说实话，这部分是整个过程中最难的，可能正因如此，很少有人尝试这个功能。

本次演示中，我使用了 Appsecco 公司的 mcp-client-and-proxy 工具。我是在观看 Riyaz Walikar 先生精彩的 MCP 渗透测试大师班时发现这个工具的。

它可以帮助我们在 MCP 客户端和服务器之间代理请求，从而使我们能够使用 Burp Suite 查看原始 HTTP 请求。

要进行此设置，首先我们需要 mcp_config.json 文件，该文件基本上包含 MCP 客户端的启动命令。

{  "mcpServers": {    "REDACTED": {      "command": "npx",      "args": [        "mcp-remote",        "https://mcp.redacted.com/mcp"      ]    }  }}

如果 mcp_config.json 文件位于 mcp-client-and-proxy 工具的根目录中，我们就可以运行以下命令：

python3 app.py --start-proxy

运行此工具后，它会将您重定向到 REDACTED 的授权页面，您应该在该页面上授权 MCP 应用程序访问我们的租户。

#

攻击计划及逻辑

此时，你可能想知道为什么我带你完成了整个 MCP 设置过程，却没有展示这一切是如何变成实际漏洞的。

这时，一个非常简单的问题突然出现在我的脑海中。

如果平台允许我将 MCP 服务器连接到我的帐户，那么该 MCP 应用程序实际继承了哪些权限？它是否严格遵守与我的低权限用户相同的限制，还是像一个拥有更广泛访问权限的独立可信实体一样运作？

所以我想，为什么不尝试通过 MCP 服务器而不是常规应用程序界面来访问相同的受限对话和联系人数据呢？如果 MCP 集成在后台的处理方式有所不同，这可能会揭示一些非常有趣的信息。

#

漏洞

MCP 应用程序已连接到我的低权限帐户，让我们尝试调用不同的工具，看看是否可以访问任何敏感信息。

python3 app.py --start-proxy

通过这些工具，我们可以简单地输入要调用的工具的 ID，在本例中，我们将调用名为“search”的工具，其 ID 为 5。

根据 MCP 服务器文档（已编辑），“搜索”工具要求我们传递一个 DSL 查询（用于 ElasticSearch），格式如下：

object_type:conversations

object_type:contacts

我们还可以传入各种复杂的子查询来筛选出我们需要的结果：

object_type:conversations state:open source_type:email source_subject:contains:"billing"

我们来尝试运行第一个查询“object_type:conversations”，在 Burp Suite 中捕获请求，看看我们是否可以提取租户中的所有对话（我们绝对不应该拥有这些对话的访问权限）：

令我惊讶的是，响应返回了租户内的所有对话 ID（尽管没有返回实际的消息内容），这仍然是一个关键问题。

现在，使用检索到的对话 ID“conversation_215471608702639”，让我们尝试调用“ fetch ”工具，该工具本质上只需使用该 ID 即可检索整个对话。

砰！我们拿到旗子了！这意味着，绕过成功了！

我们还可以尝试访问之前使用查询创建的联系人标记：

object_type:contacts name:Jack

这将查找所有名为“Jack”的联系人。

我们两个都得到了！！

我成功访问了租户中的受限对话和联系人。

该漏洞还影响了 MCP 服务器中的每个工具，用户基本上可以在没有任何权限的情况下查询租户中的任何对象（对话或联系人）。

令我惊讶的是，即使在将攻击者从租户中移除后，这种权限绕过仍然有效，这表明 MCP 应用程序是一个独立的实体，与用户没有任何关联，即使它是代表用户设置的。

那种感觉，当它不是重复的

简而言之

我们基本上是利用 MCP 服务器间接绕过了平台的权限限制。尽管账户权限有限，但 MCP 集成却能看到一些它不应该看到的内容，这表明它并没有遵守与用户相同的权限限制。最终，这暴露了明显的权限绕过行为。

#

漏洞

为了实现有效的概念验证，我创建了一个无需点击即可自动从租户中获取所有对话和联系人并将其保存到文本文件中的漏洞利用程序。

结论

这篇文章与其说是分析 bug 本身，不如说是分享我的思考过程。它展示了如何通过不同的视角和探索被忽略的特性，得出独特的发现。

在报告此漏洞后，我百分之百确定这不会是重复的，不是因为它有什么神奇之处，而是因为设置所有东西并逐一测试每个工具需要极大的耐心，我真心认为大多数网络猎人都会做到一半就放弃了。

难怪，这不是重复的，而且我最终也拿到了报酬。这证明坚持不懈和跳出固有思维模式确实会有回报。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Rsec 1day 1day《0120.我是如何发现 MCP 服务器中一个罕见漏洞的——漏洞赏金计划》