黑盒测试如何通过侦察转变为白盒

运维Z叔

已于 2024-09-13 14:56:35 修改

阅读量400

点赞数 7

文章标签：数据库前端安全学习 tcp/ip java

于 2024-09-13 14:20:14 首次发布

本文链接：https://blog.csdn.net/2301_80127209/article/details/142210031

版权

前言

我被邀请参加一家科技公司的一个私人bug赏金计划，这是该国最大的科技公司之一。范围几乎是整个公司的外部基础设施，资产面足够大的需要花费几天进行信息收集。

我将分享一些我的侦察（即信息收集，以下都简称为侦察）技巧，这在许多红队活动和bug赏金计划中帮助了我很多。为了使这篇文章不至于太长，便于阅读，我将在这里提到我认为有用的侦察的重要部分。

侦察是渗透测试中一个非常重要的部分，当我们对一个在互联网上拥有许多资产的目标进行安全研究时，需确保侦察过程彻底，我们不会错过目标忘记加固的盲点，这一点至关重要。

对目标进行信息收集

所以从信息收集开始，我试着专注于两件主要的事情：

找到目标的每一个互联网资产：IP，域&子域，甚至与第三方服务（如 slack）公司相关的帐户
OSINT调查，以便更好地了解目标提供的服务，并希望找到一些有效的凭据

对于互联网资产，我首先尝试找到目标拥有的每个域名。我首先要做的是目标的SSL证书。SSL证书在信息收集方面非常有用，因为它们可能拥有一个独特的字段，可以用于查找使用相同证书的更多域，子域甚至IP。例如，通过在crt.sh：https://crt.sh/中搜索“Organization”字段的内容，我们可以找到目标的更多域名，这些域名完全不同。

另一个例子是Subject Alternative Name（SAN）字段，顾名思义，它包含与同一证书相关的多个域和子域。这里以梅赛德斯-奔驰公司的证书为例：

从图中可以看到，只需查看mercedez-benz.com的证书，我们就可以找到该公司的更多资产：

更多与mercedes-benz相关的TLD
公司的更多域名（benz.fr、media.daimler.com、mercedes-amg.com等）

对于大公司，有必要查看资产的证书，因为公司可能会使用一些其他与主域不同的域名。一个很好的例子就是梅赛德斯-奔驰公司。如果我们查看mercedes-benz.be证书，我们会发现该公司的更多域名不在mercedes-benz.com证书中：

在我们丰富了目标的域之后，接下来就是进行子域枚举了。有很多工具可以完成这个任务：crh.sh：https://crt.sh/，dnsdumpster：https://dnsdumpster.com/，subdomainfinder：https://subdomainfinder.c99.nl/，sublist 3r：https://github.com/aboul3la/Sublist3r等等。我最喜欢是OWASP的Amass：https://github.com/owasp-amass/amass，因为它的获取来源更加丰富。

Amass在扫描我们在侦察过程中收集的域名的子域，同时使用Shodan：https://shodan.io/来查找更多的资产，有时没有任何DNS记录，这可以通过搜索持有我们的目标名称的SSL证书（过滤器：ssl.cert.subject.c：target.com）或通过在HTTP标头中搜索目标的名称。

当然，如果您有其他资产测绘平台的帐户，建议使用其他工具执行类似的过程，这些工具可能会扫描与Shodan不同的端口范围：

[censys: https://search.censys.io/
fofa：https://en.fofa.info/
ZoomEye：https://www.zoomeye.org/
nyphe：https://www.onyphe.io/

这些都是资产测绘平台，我们只需查询结果，而无需直接接触目标的基础设施。许多人也喜欢使用Masscan：https://github.com/robertdavidgraham/masscan和Naabu：https://github.com/projectdiscovery/naabu)、等工具进行主动扫描。这些都是很好的工具，有时我也会使用它们，但对于大规模的目标，我认为从被动扫描开始会更高效。此外，扫描器容易被不同的防火墙和安全产品阻止。

现在我们有了一个包含大量域和子域以及与目标关联的IP地址的列表。通过在线资产测绘平台（Shodan/Fofa/Censys）得到的结果，我们也有很多开放的端口需要检查。所以我们把它放在一个文本文件中，并把它提供给httpx：

httpx有一些非常有用的特性，可以识别出端口背后的web服务。最后，根据httpx的结果，优先考虑将要花费更多时间的地方。在这次运行结束时，我们将对在攻击面中运行的Web服务有一个很好的了解。

对结果进行分析处理

接下来我们有一个潜在资产的最终列表来测试，在清理和过滤掉一些结果之后，我们最终得到了大约100个IP地址和域/子域。

让我们分工合作：

开始对主要资产（如客户面板、管理面板等）进行漏洞研究
在后台运行一个简短的fuzz列表，以检查我们拥有的100个资产

我从fuzz任务开始。当我遇到一长串需要fuzz处理的目标时，我通常使用ffuf: https://github.com/ffuf/ffuf和一个简短的自定义单词列表，这个单词列表只包含100-150个单词。如果通过fuzz我得到其中一个响应状态码为200，这意味着我自动看到一个漏洞在我面前，大多数时候这是一个严重的信息泄露。以下是列表中的一些单词：

/config.json/.git/web.config/server-status/backup.zip/.DS_Store/v2/_catalog

当ffuf正在对100个地址进行fuzz时，我开始研究目标的主要web应用程序。第一件事是做API的信息收集，关于API信息收集更多详情，请看到公众号文章：《API安全 | 发现API的5个小tips》。

在我花了一段时间研究API之后，我并没有发现高危漏洞。我尝试的每一件事都以无效的输入错误或授权问题结束。这个应用程序在授权验证方面绝对很好。

因此，我返回到前面运行的ffuf，发现了一个有趣的结果：地址rg.target.com和路径/v2/_catalog上的状态码为200。这意味着我们有一个公开开放的Docker Registry！

为了确认它，我使用curl向 https://rg.target.com/v2/_catalog 发送了一个GET请求。响应立即返回，其中包含一个JSON，其中包含存储在该注册表中的所有Docker镜像。有些docker镜像的指示性名称是“admin”或“frontend”，有些则是我还不熟悉的名称。

是时候进行研究和调查了。我向docker注册服务器发送请求，以获取任何docker镜像的每个标签：

curl https://rg.target.com/v2/admin-REDACTED/tags/list

我得到了响应内容-标签，这有助于我更好地了解上传的最新Docker镜像：

在又请求了几个docker镜像之后，我开始查看每个镜像清单，以此来查找敏感信息：

curl https://rg.target.com/v2/admin-REDACTED/manifests/1.10

接着我发现了一些敏感的数据，但对于利用漏洞还没有真正的用处。

所以我开始拉取Docker镜像，以便打开它们并搜索代码漏洞。分析Docker镜像就是研究应用程序的代码。事实上，Docker镜像包含了程序运行和运行所需的每一个文件。因此访问目标的Docker注册表就像访问目标的Git一样。

关于Docker Registry的更多细节，请看到公众号的另一篇文章：《安全盲点：如何从Docker Registry到RCE》，这也与这种情况非常相关。

为了从私有注册表中提取Docker镜像，我们首先需要在以下路径中创建或编辑文件：/etc/docker/daemon.json。我们应该以JSON格式添加我们的新注册表作为一个“不安全”的注册表，我们可以从其中拉/推镜像：

因此，我开始拉取一些选定的Docker镜像，这些镜像可能存储主应用程序后端服务器的源代码。我不能直接运行镜像，因为我在入口点中缺少了一些我猜不到的依赖项。因此，为了从Docker镜像中提取文件系统和代码文件，我使用了在前2秒运行镜像的技巧，同时将文件导出到tar文件。

从tar文件中提取文件：

现在我们可以深入目录，查找包含后端代码的特定文件。在短暂的浏览之后，我找到了/home下的相关目录，并开始在其源代码中搜索漏洞。

还记得我之前提到的安全API吗？现在，我不仅可以看到确切的机制，我还拥有一些硬编码的有效API密钥。通过使用这些API密钥，我可以使用具有管理权限的每个API，可以获取任何用户的数据，甚至修改用户的数据。

急着我在代码中找到更多的漏洞，比如SQLi甚至RCE。但是代码安全性很好，并且是用最佳安全实践编写，所以没有出现任何问题。

我仍然想找到一种方法来提高漏洞危害等级。因此，在提交报告之前，我想尝试的最后一件事是检查除了对docker注册表的读取权限外，我是否还有写入权限。在这一点上，我仍然不知道这个注册表是什么用例，但我可以假设三个主要用例：

该应用程序基于Docker容器，因此很可能由Kubernetes等编排实用程序管理。这意味着，如果我将新的docker镜像推送到带有“latest”标签的注册表，我可能会覆盖原始的docker镜像，并将其替换为复制并包含webshell的镜像。
在后端工作的软件工程师在他们的开发过程中使用这个docker注册表，所以在某个时候，如果我用带有“latest“标签的镜像替换原始docker镜像，他们可能会下载我的复制镜像，其中可能包含我的脚本。
最不济的情况-这个注册表只是一个备份注册表，它只会收到推送请求，但永远不会收到Docker镜像的拉取。在这种情况下，覆盖当前镜像对目标没有特殊影响。

我再次阅读了相关规则，里面提到任何可能损害或中断公司生产基础设施的行动都完全超出了渗透测试范围（可以理解）。因此，我决定只验证我对注册表有推权限。所以我从DockerHub获取了NodeJS的最新镜像，并将其推送到目标的注册表中。果然成功了！

我将一份完整的报告发送到公司，在对影响进行了更多的解释之后，他们明白这不仅是信息泄露漏洞，而且很容易成为一个严重的RCE漏洞，可能会影响公司基础设施的许多不同点。

申明：本账号所分享内容仅用于网络安全技术讨论，切勿用于违法途径，所有渗透都需获取授权，违者后果自行承担，与本号及作者无关，请谨记守法。