本文仅用于网络安全研究与学习，请勿用于任何非法活动。
介绍
今天分享一个我在漏洞赏金计划中发现的独特且值得深思的漏洞。这个漏洞来自 Bugcrowd 上一个著名的公开计划。出于保密，我无法透露目标公司的具体名称，这里我们称其为“redacted.com”。
REDACTED 是一个企业级客户互动管理平台，它像是一个中心枢纽，支持团队、销售团队等可以在这里协作、回复客户并跟踪所有对话。
该平台采用了租户模式，每家公司都拥有自己独立的工作空间。在本次测试中，我可以创建租户并分配任意角色，从而测试不同访问级别的安全性。
平台功能繁多，但我们需要重点关注两个核心实体：
对话： 团队成员与客户之间的所有消息记录，包括支持聊天、邮件等任何互动。
联系人： 客户本身，他们可能来自邮件、WhatsApp、Instagram、网站等各种渠道。
团队通过角色和权限管理数据访问，决定谁可以看到什么、处理什么。
理解角色、权限和实际目标
要找到突破口，首先必须理解 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 服务器是基于模型上下文协议 (Model Context Protocol) 的程序，它向 AI 智能体和大语言模型暴露工具和数据源。
简单来说，MCP 服务器就像是连接 AI 模型与外部服务（如数据库、API）的桥梁。在我们的案例中，REDACTED 的 MCP 服务器提供了多种“工具”，让 AI 能够读取和处理平台内部的数据，比如对话和联系人。这些工具类似于编程中的函数，接收参数并返回格式化的数据。
设置 MCP 服务器
说实话，这部分是整个过程中最具挑战性的，可能正是因此，尝试此功能的人不多。
我使用了 Appsecco 的 mcp-client-and-proxy 工具，它能在 MCP 客户端和服务器之间代理流量，方便我们使用 Burp Suite 查看原始的 HTTP 请求。
首先，我们需要一个 mcp_config.json 配置文件，其中包含了启动 MCP 客户端的命令：
{
“mcpServers”: {
“REDACTED”: {
“command”: “npx”,
“args”: [
“mcp-remote”,
“https://mcp.redacted.com/mcp”
]
}
}
}
将此文件放在工具根目录，然后运行：
python3 app.py --start-proxy
运行后，工具会引导你前往 REDACTED 的授权页面，完成 MCP 应用对你租户的访问授权。
攻击构思与逻辑推演
此时，你可能会想：为什么我要费这么大劲设置 MCP？这和漏洞有什么关系？
关键在于一个简单却至关重要的问题：当平台允许我将 MCP 服务器连接到我的低权限账户时，这个 MCP 应用本身到底继承了哪些权限？它是否严格遵守与我账户相同的访问限制，还是作为一个独立的、可能拥有更广泛权限的“可信实体”在运作？
于是，一个清晰的攻击思路形成了：尝试通过 MCP 服务器提供的工具，而非常规应用界面，去访问那些本应被限制的对话和联系人数据。如果 MCP 集成在后台的处理逻辑与前端不同，就很可能暴露出安全问题。
漏洞复现
MCP 应用已经成功连接到我的低权限账户。启动代理工具后，我可以通过交互式命令行调用各种工具。
根据文档，“search”工具（ID 5）允许我们使用一种 DSL（领域特定语言）查询语法，类似于 ElasticSearch，来搜索数据。基本语法如下：
object_type:conversations
或
object_type:contacts
我们首先尝试查询所有对话：object_type:conversations，并通过 Burp Suite 捕获请求。
令人惊讶的是，响应返回了租户内所有的对话ID！虽然此时还没有返回具体的消息内容，但这已经是一个关键问题，意味着我可以通过 MCP 接口枚举所有资源。
接下来，使用获取到的对话 ID，例如 conversation_2154710087020397，调用 fetch 工具来获取该对话的完整详情。
成功了！ 我看到了之前由高权限账户埋下的标记消息：“IF YOU SEE THIS MESSAGE, IT WORKED!!”。权限绕过验证成功！
同样，我们可以搜索联系人标记：
object_type:contacts name:Jack
再次成功！名为 “Jack Bugcrowd” 的联系人详情被完整返回。
至此，我已经能够通过 MCP 服务器，以低权限账户身份访问租户中的所有受限对话和联系人。该漏洞影响了 MCP 服务器提供的每一个查询工具，使得攻击者可以在没有任何常规界面权限的情况下，查询租户内的任何对象。
更令人惊讶的是，即使将攻击者账户从租户中完全移除，这种通过 MCP 应用的权限绕过仍然有效。 这强有力地证明，MCP 应用是一个独立的实体，其访问控制并未与创建它的用户账户进行正确绑定，这暴露出严重的后端 架构 设计缺陷。
当发现漏洞不是重复报告时的感觉。
简而言之，我们利用了 MCP 服务器这一“桥梁”，绕过了平台前端的权限检查。尽管用户账户权限极低，但与之关联的 MCP 集成却能看到本不该看到的内容，这表明其后台权限验证逻辑存在严重缺失。
漏洞利用
为了展示漏洞的危害性，我编写了一个自动化利用脚本，无需人工点击即可从租户中提取所有对话和联系人，并保存到本地文件中。
结论
这篇文章与其说是对一个具体漏洞的技术剖析，不如说是一次完整的安全研究思维过程分享。它展示了如何通过转换视角、深入研究产品新特性，并在看似复杂的设置中坚持测试，最终获得独特的发现。
在提交这份漏洞报告时，我几乎百分之百确定它不是重复的。这并不是因为漏洞本身多么高深莫测，而是因为完成整个 MCP 设置并耐心测试每一个工具，需要极大的毅力和对细节的关注，我相信大多数安全研究员可能会在半途选择放弃。
最终，这个漏洞被确认是唯一报告，我也获得了相应的奖励。这再次证明，在安全研究的道路上，坚持不懈和跳出思维定式往往能带来丰厚的回报。如果你对这类实战中的安全逻辑缺陷挖掘感兴趣，欢迎在 云栈社区 与我们进行更多交流。
发表于 3 天前
|
查看: 11|
回复: 0
