文章总结： 这篇文章描述了作者如何从暴露的指标端点开始，通过追踪泄露的内部子域名，最终发现未经身份验证的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 访问
- 连接到主实例（端口 27019）：
- 命令：
mongo - host prod-db00.[target].io - port 27019
- *结果：成功。无需凭据*即可连接到 MongoDB 4.4.11。
我们切换到 admin 数据库并进行了一些检查：
use adminshow dbsdb.runCommand({ connectionStatus: 1 })db.runCommand({ buildInfo: 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.将漏洞与未经身份验证的数据库访问联系起来：一次协作式漏洞搜寻》