文章总结： 这篇文章描述了作者如何从暴露的指标端点开始，通过追踪泄露的内部子域名，最终发现未经身份验证的MongoDB数据库实例。尽管最初报告被驳回，但他们坚持不懈，最终将这个发现报告为中等严重程度的漏洞并获得赏金，强调了在漏洞赏金计划中坚持和深入调查的重要性。 综合评分： 87 文章分类： 漏洞分析,数据库安全,渗透测试,WEB安全,实战经验

0101.将漏洞与未经身份验证的数据库访问联系起来：一次协作式漏洞搜寻

原创

Danish Ahmed

Rsec

2025年12月21日 09:04 贵州

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

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

类型：数据库权限控制

所以……你猜怎么着？

我们成功获得了生产环境 MongoDB 实例的访问权限。

（是啊，当我意识到这一点时，我的心也跟着沉了下去😅）

等等。这可不是那种一夜之间就靠黑客技术破解关键漏洞的惊天故事，两下鼠标就能搞定。不。

这是一段充满拒绝、坚持和团队合作的旅程。

接下来我要讲述的是我（Danish Ahmed 👋）和Ayesha Attaria如何将一份“一般般”的报告变成一份有效的中等严重程度的调查结果。

初步发现：指标端点存在泄漏

#

我们的搜寻始于一个简单的观察：一个暴露的端点位于：

/actuator/prometheus

该终端节点泄露了关键系统指标，包括：

• 堆和内存地址
• 内部主机名和配置
• 其他敏感运行时数据

虽然这类泄露可以帮助进行内存损坏攻击或基础设施映射，但 YesWeHack 的政策很明确：纯粹的信息泄露不在其范围之内，除非它与更有意义的事情联系起来。

我们于 2025 年 7 月 28 日提交了报告，但被标记为 “已驳回——请阅读详细范围说明（RFS）” 。我们没有就此放弃，而是决定深入调查。

追踪泄露源：揭露内部子域名

在暴露的指标中，我们发现了一个内部子域名：prod-db00.[target].io。重要的是，该子域名位于项目范围之内，因此可以作为进一步测试的对象。我们首先尝试通过浏览器使用 HTTP 和 HTTPS 协议访问该子域名，但这些标准端口均无响应——没有 Web 服务器在监听。

为了进一步探究，我们对主机进行了 Nmap 扫描。结果显示 27019 和 27018 端口开放，我们了解到这两个端口通常用于 MongoDB 实例（分别是主副本和辅助副本）。这表明可能存在暴露的数据库服务。

回顾泄露的指标数据，我们注意到其中提到了一个内部子域名：

prod-db00.[target].io

这一点立即引起了我们的注意，因为它在监控范围内。我们快速地通过浏览器检查了 HTTP 和 HTTPS 协议，结果一无所获——没有网络服务器在监听。是时候进一步调查了。

我们使用 Nmap 扫描了主机，发现有两个熟悉的端口完全开放：

• 27019 → MongoDB 主副本
• 27018 → MongoDB 二级副本

这会不会是暴露的数据库？

概念验证：未经身份验证的 MongoDB 访问

1. 连接到主实例（端口 27019）：

• 命令：

mongo - host prod-db00.[target].io - port 27019

• *结果：成功。无需凭据*即可连接到 MongoDB 4.4.11。

我们切换到 admin 数据库并进行了一些检查：

use adminshow dbsdb.runCommand({ connectionStatus: 1 })db.runCommand({ buildInfo: 1 })

输出已确认：

• 不强制进行身份验证。
• 服务器完整构建信息已公开

1. 连接到辅助实例（端口 27018）：

• 命令：

mongo - host prod-db00.[target].io - port 27018

• 结果： 再次发现未经身份验证的访问。某些命令（例如 buildInfo ）因副本限制而被阻止，但连接本身就证明了存在暴露风险。

POC 输出片段（已脱敏）：

s01:PRIMARY> db.runCommand({ connectionStatus: 1 }){  "authInfo": {    "authenticatedUsers": [],    "authenticatedUserRoles": []  },  "ok": 1,  ...}

对于次要部分：

s01:SECONDARY> db.runCommand({ connectionStatus: 1 }){  "authInfo": {    "authenticatedUsers": [],    "authenticatedUserRoles": []  },  "ok": 1,  ...}

【译者注释：

上面的POC输出是MongoDB 数据库命令的执行结果

“authInfo”: 认证信息部分

“authenticatedUsers”: [] – 空数组表示当前没有已认证的用户

“authenticatedUserRoles”: [] – 空数组表示当前连接没有分配任何角色

“ok”: 1 – 表示命令执行成功

PRIMARY（主节点）：

处理所有写操作

处理读操作（默认）

是副本集的读写中心

选举产生，故障时会自动切换

SECONDARY（从节点）：

只处理读操作（可配置）

复制主节点的数据

提供数据冗余和高可用性

在主节点故障时可被选举为新主节点】

#

结果

我们将连锁发现报告为严重问题——但在提交报告 14 天后，他们将其从严重改为中等，并奖励我们 200 欧元赏金。

#

最后想说的话

漏洞赏金计划并不轻松。每一份被接受的报告背后，都隐藏着无数次的拒绝、重复和失败，这些都无人知晓。从旁观者的角度来看，人们只看到成功，却看不到背后的艰辛付出和失败经历。

在这种情况下，原本看似微小的指标泄露最终演变成了一场更大的灾难：未经身份验证的数据库访问。我们之所以会走到这一步，唯一的原因是我们没有在第一次被拒绝后就止步不前。

教训是什么？永远保持好奇心，不断挖掘，不要过早放弃——有时真正的收获就在下一步。

📌 在领英上与我们联系：

• Danish Ahmed
• Ayesha Attaria

免责声明：

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

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

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

本文转载自：Rsec Danish Ahmed《0101.将漏洞与未经身份验证的数据库访问联系起来：一次协作式漏洞搜寻》