MongoDB生产环境未授权访问漏洞分析：从指标泄露到权限获取的实战过程

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

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

我们的漏洞搜寻始于一个看似普通的发现：一个暴露的 Actuator 端点。该端点位于 /actuator/prometheus，泄露了大量关键的系统运行时指标，例如：

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

虽然这类信息泄露本身可能被用于辅助内存攻击或进行基础设施映射，但根据目标平台的漏洞赏金政策，纯粹的信息泄露并不在奖励范围内，除非能与其他更具破坏性的漏洞链式结合。

我们的初始报告因此被驳回。然而，我们并未就此放弃，而是选择对泄露的数据进行深度挖掘。

从泄露数据到内部资产发现

在仔细审查泄露的指标数据时，一个内部子域名引起了我们的注意：prod-db00.[target].io。关键点在于，该子域名恰好位于项目的测试范围之内。

初步尝试通过浏览器访问其HTTP/HTTPS端口均无响应，表明不存在Web服务。于是，我们转而使用 Nmap 对主机进行端口扫描，这是运维和安全测试中的常规操作。扫描结果显示两个端口开放：

• 27019 — 通常用于 MongoDB 主副本节点
• 27018 — 通常用于 MongoDB 从副本节点

这一发现强烈暗示着一个可能暴露在公网的数据库服务。

概念验证：确认未授权访问漏洞

为了验证猜想，我们直接尝试连接这些MongoDB实例。

1. 连接主实例 (端口 27019)
   执行命令：

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

   连接成功！无需任何用户名和密码即可访问。我们进一步执行命令探查：

   use admin
   show dbs
   db.runCommand({ connectionStatus: 1 })
   db.runCommand({ buildInfo: 1 })

   输出确认了服务器未启用身份验证，并完整泄露了其构建信息（版本为 MongoDB 4.4.11）。

2. 连接从实例 (端口 27018)
   执行命令：

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

   同样成功建立连接。虽然部分管理命令因副本集角色限制而无法执行，但无认证的连接本身已构成严重风险。

POC输出片段（已脱敏）：
主节点连接状态显示：

s01:PRIMARY> db.runCommand({ connectionStatus: 1 })
{
  "authInfo": {
    "authenticatedUsers": [], // 空数组表示无认证用户
    "authenticatedUserRoles": [] // 空数组表示无角色
  },
  "ok": 1,
  ...
}

从节点也返回了类似的结果，authenticatedUsers 数组为空，证实了未授权访问的存在。

技术要点说明：

• PRIMARY (主节点)：处理所有写操作和默认的读操作，是副本集的核心。
• SECONDARY (从节点)：复制主节点数据，通常只处理读操作，提供数据冗余和高可用性；在主节点故障时可被选举为新主。

报告与结果

我们将这个从“指标泄露”到“生产数据库未授权访问”的链式发现过程整理提交，报告为严重级别漏洞。平台在审核后，最终将其评级调整为中等，并发放了相应的赏金。

反思与总结

漏洞赏金搜寻之路往往布满荆棘。每份被接受的报告背后，是大量不为人知的拒绝、重复测试和失败尝试。在此案例中，一个起初被判定为“无实际影响”的信息泄露端点，通过坚持不懈的深入追踪，最终暴露了核心数据库的严重配置缺陷。

核心教训是：在安全研究中，保持好奇心和深度挖掘的韧性至关重要。不要轻易被首次拒绝阻挡，因为关键的突破口，常常就在下一步的探索之中。