介绍
考虑到流程的长度,我们提供了一个 TL;DR 部分用 16 个简短的点总结了我们的旅程,从而成功访问了主要目标。
但是,如果读者希望了解每个阶段使用的心态,他们可以继续阅读直到最后。
以下是文章的摘要:
- 已在 stealer 日志中搜索 相关数据。
ABC-1 - 已确定一个具有各种用户的公共功能的应用程序。
- 注意到前端有一个 的 徽标 ,它与 的徽标不同。
XYZ-2
ABC-1 - 在为管理 的 IT 运营 而创建的 Google 搜索中找到。注意:并且 托管在单独的域上,而不是子域上。
XYZ-2
ABC-1
XYZ-2
ABC-1 - 在窃取日志中搜索,产生五个结果,其中包含 2022 年的最新数据。
XYZ-2 - 查看这些结果,发现一个日志指示 上的电子邮件访问。注意: 也托管在与 和 不同的域中 。
JKL-3
JKL-3
XYZ-2
ABC-1 - 据透露,两者的所有电子邮件访问 都是通过 和 发生的。
ABC-1
XYZ-2
JKL-3 - 在日志中搜索,重点关注与 和 相关的数据 (包括在凭据和 URL 中使用此关键字)。
JKL-3
ABC-1
XYZ-2 - 找到链接 、 和 的日志,其中包括对在 URL 中使用 名称的 UAT 环境的引用。
ABC-1
XYZ-2
JKL-3
ABC-1
- 尝试访问 UAT 环境,遇到 403 Forbidden 页面。
- 搜索 archive.org UAT 环境详细信息,发现多条记录。
- 一条记录显示了 UAT 环境的目录列表。
- 根据存档中找到的唯一名称,从活动站点访问 .dll、.zip 等文件(最初显示 403 禁止访问)。
- 下载的 .dll 和 .zip 文件,其中.zip包含大量已编译和未编译的源代码,可能是备份。
- 反编译 .dll 文件,发现各种凭据(电子邮件、数据库、令牌等)。
快速经验教训:了解窃取日志不仅仅是测试凭据——它还涉及分析链接到目标的 URL,而标准子域工具可能会忽略这些 URL。这种更广泛的方法会导致更彻底的风险评估。在这种情况下,目标在三个不同的域(而不是子域)上运行,每个域都有自己的作功能。
在下一节中,我们将首先概述此案例研究的从头开始的过程。
VI. 案例研究 2:用于“资产发现”的窃取日志
6.1. 在 Stealer 日志中搜索与目标相关的凭据
“Stealer Logs 可以协助资产发现过程”。这听起来像是一个独特的陈述,但它与现实息息相关。在这种情况下,我们将解释我们如何获得广泛的访问权限,从资产发现到几乎所有内容都已过期的窃取日志,通过 archive.org 上的信息从目标下载敏感文件,并最终获得属于目标的大量凭据。
在深入研究本案例研究之前,重要的是要了解我们在从窃取日志中搜索目标信息时可能面临的挑战之一是与拥有大量客户群的公司打交道,因为他们直接与最终用户互动,例如拼车公司、销售设备(如笔记本电脑、电话等)的 ICT 公司、食品配送服务、 和其他。
为什么这是一个挑战?因为搜索结果不是找到内部团队使用的门户,而是更有可能显示受窃取恶意软件影响的客户的信息。如果目标是测试目标的系统,那么访问面向公众的服务的客户账户肯定不是合适的方法。所以,如果我们遇到这样的情况,搜索必须更具体,比如过滤掉客户常用的 URL。
虽然我们可以先探索目标的公共资产,然后根据这些资产自动进行搜索,但这种方法可能需要更长的时间。
通过缩小客户常用的 URL,搜索将更加集中在用户经常访问的资产上。从那里,我们可以进一步探索用户也访问的其他资产。
简而言之,我们曾经从一家拥有非常大客户群的公共服务(我们称之为 )中找到了一个目标。最初,我们获得的结果大多显示受窃取恶意软件影响的客户数据。然而,在使用更具体的方法优化我们的搜索后,我们终于找到了相关信息。
ABC-1
在我们的第一个特定搜索结果中,我们立即找到了一个应用程序,它有一个简单的登录页面,似乎是为与公司合作的合作伙伴准备的(从应用程序的标题可以推断)。虽然我们找到的帐户在技术上可以用于进一步测试合作伙伴的应用程序是否存在漏洞,但这并不是我们当时的主要目标,因为我们无权进行测试。
那么,我们发现了什么呢?经过仔细检查,我们在应用程序的页脚中发现了一个外国标志和名称。
有人可能会问为什么我们不按电子邮件域搜索。
澄清一下,我们确实尝试了,但在窃取日志中没有发现与 的电子邮件相关的结果(无论是邮件、电子邮件、网络邮件等)。此外,由于目标的电子邮件用户名格式未知,我们暂时搁置了对 Microsoft 或 Google 等常见电子邮件服务的检查。
ABC-1
6.2. 根据合作伙伴应用程序中找到的 logo 搜索公司信息
遇到这种情况后,我们立即搜索了有关使用该标志的公司的信息。幸运的是,我们通过 Google 搜索很快找到了它(可能是由于公司名称的唯一性)——我们称之为 .
XYZ-2
在这个阶段,我们并没有立即深入研究搜索相关的泄露信息。相反,我们首先进行了一项个人资料调查,以了解更多信息,调查其公司简介和社交媒体形象。我们研究的一些方面包括:
XYZ-2
XYZ-2
- 谁是 ?
XYZ-2 - 做什么?
XYZ-2 - 与 的关系是什么?
XYZ-2
ABC-1
如果 XYZ-2 被证明是第三方服务提供商,我们将被法律禁止与他们接触,除非他们有漏洞披露计划或类似计划。但是,经过进一步研究,我们得出结论,这是 的一部分,为 处理所有与 IT 相关的事务。我们还意识到,开发了 的主平台,供 的客户使用。
XYZ-2
ABC-1
ABC-1
XYZ-2
ABC-1
ABC-1
6.3. 通过 XYZ-2 发现资产 — IT 处理程序
ABC-1
一旦确认这是 的一部分,我们就通过窃取日志继续搜索。不幸的是,我们只发现了大约五个结果,最新的是 2022 年的结果。更糟糕的是,2022 年受影响的内部员工似乎已经搬到了另一家公司,这让我们相信与该公司相关的所有凭证都不再有效。经过验证,我们的假设被证明是正确的 — 所有凭证都是无效的。
XYZ-2
ABC-1
然后,我们重新分析了所有 URL,而不仅仅是关注 的域。通过这种方式,我们发现设备所有者使用 的域 (AD) 登录了电子邮件帐户。经过进一步调查,发现这是 的另一部分,专注于更具体的业务领域。快速浏览一下,似乎所有的电子邮件作都使用了该域。这让我们走上了一条非常有趣的道路。
XYZ-2
JKL-3
JKL-3
ABC-1
ABC-1
JKL-3
6.4. 搜索包含 ABC-1、XYZ-2 和 JKL-3 连接的日志
回顾一下,在这个阶段,我们确定了三个不同的领域:
ABC-1的域 (abc.tld),该域似乎是公司所有子公司的父级。
XYZ-2的域 (xyz.tld) 的域名 (xyz.tld),似乎负责处理和开发 的主要客户平台的所有 IT 事务。
ABC-1
ABC-1
JKL-3的域 (jkl.tld),该域似乎被 、 和它自己用于电子邮件作 (mail.jkl.tld)。
ABC-1
XYZ-2
JKL-3
下一步是开始搜索涉及 的电子邮件域 (mail.jkl.tld) 的泄漏,同时还要查找与 相关的信息。
JKL-3
XYZ-2
不是 不仅返回了五个泄露的结果,最后一个出现在 2022 年吗?是的,这是正确的。尽管只有五个泄露的结果,其中最后一个出现在 2022 年,但重要的是要记住,与 XYZ 的连接不仅与 URL 或用户名相关联,它们还可以链接到正在使用的密码/URL。
XYZ-2
XYZ-2
简而言之,我们发现了一个泄漏,当时大约有一年的历史。以下是此次泄漏的主要发现:
- 首先,此设备的用户有权访问该域上的电子邮件。
JKL-3 - 其次,设备用户的密码包含与 的公司名称相关的关键字。
XYZ-2 - 第三,设备用户还收到了一封包含域的电子邮件,该电子邮件使用的用户名包含 。
JKL-3
ABC-1 - 而最耐人寻味的是,泄漏中有一个高度唯一的 URL,恰好包含 的公司名称。
ABC-1
那么,结果如何呢?不幸的是,我们获得的任何证书都无效。
即使是似乎用作 UAT 的 URL 也返回了 403 Forbidden 消息。但是,重要的是要了解“禁止”消息可以有多种含义,例如:
-
访客可能仅被拒绝访问首页,而不允许下载/访问其中的文件。 -
这可能是由于白名单访问配置阻止从 Internet 访问门户,但允许从 Intranet 访问门户。
6.5. 由于证书透明性,通过存档中记录的站点访问数据
发现这种情况后,我们尝试检查此 URL 是否在 archive.org 上存档,无论是手动(故意)还是通过使用 SSL/TLS 证书自动存档。我们很幸运地发现,在特定日期,这个 URL 刚刚使用了 SSL/TLS 证书,并被记录在 archive.org 上。
要了解此记录发生的原因,我们需要了解证书透明度 (CT) 的工作原理。
当组织或个人购买 SSL/TLS 证书时,它首先由证书颁发机构 (CA) 颁发。颁发证书后,CA 会将证书记录在证书透明度 (CT) 日志中,该日志是所有已颁发证书的公共记录。此过程允许任何人监控和验证颁发的证书,确保不存在未经授权的证书。
这样,archive.org 可以使用 CT 日志中的数据来捕获和存储最近使用过数字证书的网站副本。我们发现 archive.org 确实有与 CT 日志中的信息相对应的日期的网站记录,这让我们有机会查看当时网站的快照。
回到主题,接下来,我们决定回顾一些以前的记录,并在 2023 年发现了一个有趣的情况,其中 UAT 接口以前是一个目录列表。这非常有趣,因为它表明界面中列出的文件可能仍然可以访问并可能更新。
结果如何?事实证明,我们的假设是正确的。我们能够顺利下载文件,没有任何问题。此外,我们发现应用程序管理员仅限制了对主目录的访问,而没有限制对子目录的访问。这使我们能够自由地浏览其中的文件。
您现在可能想知道,在那里发现了哪些类型的文件格式?我们发现了各种文件,例如文档、.zip 文件和一些似乎过时的 .dll 文件。然而,最值得注意的发现是,与界面中列出的文件相比,其中一个.zip文件实际上包含更新的.dll。
6.6. 尝试反编译已编译.dll。
经常犯的一个常见错误是 。基于 NET 的应用程序开发人员正在将其代码编译成 .dll,而无需实施混淆。这变得有问题,因为如果没有混淆,生成的 .dll 文件将变得更加容易反编译和分析,这为信息泄露或漏洞提供了利用的可能性。
在本例中,我们尝试反编译文件(可以使用 dnSpy 或 JetBrains 的 dotPeek 完成)。
简而言之,从此活动中,我们在文件中发现了大量凭据,包括用于登录电子邮件(连接到 Active Directory)、数据库、令牌等的凭据。
6.7. 从案例研究 #2 中吸取的教训
最后,我们到达了本文的结尾。像往常一样,我们将重点介绍从所讨论的案例研究中吸取的主要经验教训,即:
-
了解窃取者日志中的数据不仅仅是测试直接链接到目标的凭据,还包括分析与目标关联的其他 URL 的潜在相关性(标准子域枚举工具通常无法发现的见解)。这种更广泛的视角有助于进行更全面的风险评估。
在这种情况下,我们观察到目标使用三个单独的域(不是子域),每个域提供不同的作功能。 -
开发人员必须意识到,混淆代码对于使攻击者更难理解其内容至关重要。
在这种情况下,开发人员应避免将凭证直接放在代码中。使用 secret 管理工具安全地处理凭证可能是一种有效的方法。无论使用哪种方法,这里的关键要点是确保敏感值(如凭证)永远不会以明文形式公开。参考:为使用 Vault 的数据库连接提供 Secrets Management -
当敏感信息(如目录列表)意外公开并随后记录在 Archive.org 等网站上时,最佳解决方案不仅仅涉及禁用目录列表功能。请务必保护文件访问、限制公共访问,并考虑重命名或重新定位文件以确保无法再次访问它们。
引用
-
Y. Kho,“了解窃取日志及其在安全测试中的作用 — 第 1 部分”,2024 年 8 月 30 日。[在线]。可用:https://medium.com/@YoKoKho/understanding-log-stealer-and-its-role-in-security-testing-part-1-5f2223b47847。 -
digicert,“什么是证书透明度?”,[在线]。可用:https://www.digicert.com/faq/certificate-transparency/what-is-certificate-transparency。 -
证书透明度,“CT 的工作原理”,[在线]。可用:https://certificate.transparency.dev/howctworks/。 -
让我们加密,“证书透明度 (CT) 日志”,2023 年 9 月 25 日。[在线]。可用:https://letsencrypt.org/docs/ct-logs/。 -
digicert,“什么是 CT 日志?”,[在线]。可用:https://www.digicert.com/faq/public-trust-and-certificates/what-are-ct-logs。 -
M. Sharma,“为数据库与 Vault 的连接提供密钥管理 — 第 1 部分”,2019 年 1 月 28 日。[在线]。可用:https://faun.pub/delivering-secrets-management-for-database-connectivity-with-vault-part-1-1f1ca2dbfd8c。 - https://archive.org/
- https://github.com/dnSpy/dnSpy
- https://www.jetbrains.com/decompiler/
原文始发于微信公众号(安全狗的自我修养):了解窃取日志及其在安全测试中的作用:关注资产发现 — 第 2 部分
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论