从CloudFlare配置错误到登录管理后台

1. 目标信息收集

在一次漏洞挖掘活动中，我们发现了一个新开发的移动应用作为目标。除了专注于测试该移动应用本身之外，我们还在这一阶段收集了与应用程序中识别出的域名/子域名相关的信息。简而言之，我们发现了 dev-env.target.tld。

根据我们对该域名的初步调查，我们发现目标存在以下两种情况：

首先，该应用程序很可能托管在某个知名的公共托管服务上，因为 dev-env.target.tld 子域使用的 IP 地址注册在该提供商名下。

img

其次，有迹象表明管理员可能正在使用 Cloudflare 服务（通过所使用的名称服务器可以看出），作为额外的保护层。这可以帮助防止注入攻击或缓解可能导致系统资源过载的活动。

img

无论调查结果如何，这两条信息对于构建目标画像都是非常有价值的。

请注意，从技术上讲，当目标使用 Cloudflare 服务时，我们通常认为通过 ping 获取的 IP 并非目标的真实 IP。因此，我们需要揭示真实的 IP 地址，以了解应用程序的实际部署情况。为此，我们首先使用了 Censys 服务进行搜索。

2. 搜索与 dev-env.target.tld 关联的连接（如 IP 地址）

Censys 每天会持续扫描公共 IPv4 地址，并支持扫描超过 3,500 种端口类型。考虑到 target.tld 域名（本文的目标）自 2021 年以来就已存在，有可能 Censys 已经收集了该主机的信息，尤其是当主机保护不当且可以公开访问时。

通过 Censys 搜索，我们确定了两个自主系统号（ASN）——一个属于 Digital Ocean，另一个属于我们之前提到的主要提供商之一，这是一家知名的公共托管服务。

img

img

3. 发现端口 9000 上的活动调试模式

img

img

img

4. 发现 OTP 的主代码

img

img

5. 获得对 /Admin Dashboard 的有限访问权限

img

6. 结论

声明：⽂中所涉及的技术、思路和⼯具仅供以安全为⽬的的学习交流使⽤，任何⼈不得将其⽤于⾮法⽤途以及盈利等⽬的，否则后果⾃⾏承担。

原文始发于微信公众号（白帽子左一）：从CloudFlare配置错误到登录管理后台