在本文中，我们将介绍两种不同的方法：

• 对于对这一发现的简要概述感兴趣的读者（如果真主愿意，它可以为读者节省大量时间理解每个流程）——请参阅 TL;DR 部分，以及
• 对于那些想要了解这一发现的执行流程或历程的人来说，InshaAllah，它可以为读者提供一些思路，并希望能够帮助人们丰富他们的见解。

请欣赏这篇文章。

TL;DR

关于这个问题简单说一下几点：

• 该目标没有可自由访问的注册功能，换句话说，每个用户（员工）可能必须经过几个阶段才能获得访问权限。
• 通过使用数据泄露监控平台进行搜索，发现了一个可用的活跃凭证。
• 登录后，只发现一个相当简单的菜单——仅限于维护个人数据。
• 检查登录后获取的app.bundle.min.js文件，在dashboardroutes变量中发现有30多个端点信息。
• 通过URL访问各个端点，发现有一个端点可以直接访问（/invite-user），其中包含数万条用户数据。
• 从邀请用户功能创建一个新用户，并在请求中将 accessLevel 值更改为 99（此值也在 app.bundle.min.js 文件中找到）。
• 成功获得超级管理员访问权限。

1.访问https://url_1.xyz-company.com/

在与Fahad Alamri和Meshari Almalki一起进行漏洞搜寻时，我们再次遇到了一个仅有登录表单的目标。除了遵循上一篇文章中描述的一些初始步骤外，我们还尝试查找数据泄露监控平台上可能用于登录目标的凭证的其他信息。总而言之，我们找到了一个可用的有效账户，这使我们能够更好地了解应用程序内部的情况。

首次登录时，我们立即假设这是一个普通用户帐户（因为菜单非常简洁）。如果遇到这种情况，我们应该记住一条基本原则：“应用程序中有用户的地方，通常有一个更高权限的用户负责管理所有用户”。然而，问题在于我们缺乏关于这个高权限用户及其菜单（包括其终端）的信息，因为我们只有一个普通帐户。

2. 分析.js文件 — app.bundle.min.js

那么，当我们面临这种权限受限的情况时，我们该怎么办呢？考虑到我们只有一个账户，权限又有限。从技术上讲，有很多方法可以解决，其中一些如下：

• 尝试通过更改 ID 值或调整某些“看似”容易猜到的值（例如，具有常见名称的电子邮件地址，如 [email protected]、[email protected] 等）来检查可能存在的访问控制中断。
• 如果更改 ID 值或先前的值不起作用，我们可以尝试使用其他 HTTP 方法重新执行（例如，如果之前使用 POST 执行，则尝试使用 GET 执行）。反之亦然。
• 尝试观察和分析用户会话是如何创建的（创建的会话是否可预测）。
• 尝试一些注入测试（例如：SQL注入，XSS等）。
• 尝试直接从“低级”帐户访问受保护的 URL（但如果端点命名是唯一的，那么了解此端点信息肯定是强制性的）。
• 当然，还有很多其他方法可以尝试。我们建议读者访问Pentester Land 门户网站。他们收集了许多精彩的资源。

因此，从几次测试尝试来看，访问受保护的 URL 获得了积极的结果。

也许会出现一个问题：“我们难道不需要有关端点名称的信息吗，无论是通过从管理员帐户查看它们，还是通过猜测开发人员使用易于猜测的命名约定？”

一般来说，这是正确的。但是，我们也不能忽视开发人员“可能”将所有端点信息放在 JavaScript 中，而这些信息可以从客户端查看——而这正是发生的事情。因此，当我们退出时，我们发现了一个 .js 文件，其大小相对较大，为 9.354.560 字节（约 8.91 MB）。

在检查这些 .js 文件时，我们在dashboardroutes变量中发现了 30 多个端点信息。我们立即尝试再次登录，并立即尝试通过 URL 访问几个现有端点。最终，我们发现一个可以直接访问的端点 (/invite-user)，其中包含数万条用户数据。

3. /invite-user Endpoint — 拥有数万用户数据的端点

当我们访问 /invite-user 端点时，应用程序立即显示了一个相当大的用户列表。这无疑表明该端点存在访问控制问题。

一般来说，即使我们只查看姓名和电子邮件地址，攻击者获得的信息也远不止这些。基本上，当我们点击任何一个用户名时，我们都会找到电话号码、分支机构等等。

鉴于这种情况，我们急忙尝试创建新用户。原因无非是想看看我们刚刚创建的用户的权限是否有可能被提升。

4. 创建新用户并尝试提升其权限

当我们尝试创建用户时，应用程序基本上会向 /api/users 发送一个包含大量 json 数据的请求。

POST /api/users HTTP/2Host: api.url_1.xyz-company.comContent-Length: 340User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.5938.132 Safari/537.36Authorization: Bearer <bearer_data_here>Content-Type: application/jsonAccept: application/json, text/javascript, */*; q=0.01Fngprt: <Fngprt_data_here>Sec-Ch-Ua-Platform: “macOS”Origin: https://url_1.xyz-company.comReferer: https://url_1.xyz-company.com/Accept-Encoding: gzip, deflate, brAccept-Language: en-US,en;q=0.9{“name”:”Test Account”,”email”:”haktrak_test_account@haktrak-xyz.tld”,”userCountryCode”:”966",”contact”:”13374444",”designation”:””,”department”:””,”branch”:””,”country”:”Saudi Arabia”,”accessLevel”:”2",”userLimit”:””,”domains”:””,”organisationId”:”5f**********************”,”orgAdmin”:false,”twoFactor”:false}

如果我们尝试查看用户创建过程中发生的流程，我们将看到“accessLevel”参数。为了更加确定，我们尝试再次查看之前找到的.js文件的内容（希望其中有真实的信息，而不是仅仅猜测）。

简而言之，我们确定 accessLevel 99 是代表超级管理员的访问级别。由此开始。我们还尝试创建用户并研究现有需求。

以下是修改后的请求示例：

{“name”:”Test Account”,”email”:”haktrak_test_[email protected]”,”userCountryCode”:”966",”contact”:”13374444",”designation”:””,”department”:””,”branch”:””,”country”:”Saudi Arabia”,”accessLevel”:”99",”userLimit”:””,”domains”:””,”organisationId”:”5f**********************”,”orgAdmin”:false,”twoFactor”:false}

请注意，尽管参数很多，但我们的注意力只集中在 email 和 accessLevel 参数上。原因很简单，因为需要邮箱地址才能从应用程序接收密码，而 accessLevel 的修改是为了提升我们的权限。

在这种情况下，我们需要将accessLevel值从2改为99（即超级管理员），然后继续发送到服务器。

当我们尝试查找我们创建的帐户的状态时，我们会发现该帐户已经具有“超级管理员”状态（应该只能创建管理员/维护者帐户状态）。

请注意：有一次，我们发现在第一次创建用户时将访问级别更改为 99 无法正常工作（换句话说，角色被恢复为经理）。

如果出现这种情况，那么我们只需要编辑已经创建的用户，拦截请求，点击保存（POST请求），再次将accessLevel改为99即可。这样我们就成功的将该用户的权限提升为超级管理员了。

用户创建成功后，我们急忙查看电子邮件（因为找不到创建密码的表格）。

5. 使用超级管理员帐户登录

得到密码后，我们立即登录。登录后，门户要求我们更改之前创建的密码（当然，第一次使用后更改密码是一个非常好的做法）。

如果密码已更改，那么我们已成功以超级管理员身份登录并可以访问其中包含的所有数据。

6. 经验教训

在本文即将结束之际，我们计划在本节中提供一个简短的总结。本总结旨在提炼这段历程中的几个关键经验教训，使读者更容易理解：

• 有时，即使执行了上一篇文章中概述的几个初始步骤，我们仍可能难以找到访问应用程序的方法。面对这种情况，我们必须采取更广泛的方法，例如尝试通过凭证泄露监控平台查找可用的凭证。
  
  在这种情况下，我们可以利用相关工具（例如ThreatsTracker - HakTrak 的智能平台）来帮助我们获取应用程序的访问权限。

• 请记住，“侦察不应仅限于查找资产和过时的内容。它还涉及了解应用程序并查找不易访问的功能。为了取得成功，需要在侦察和传统的应用程序攻击之间取得平衡。 ”@NahamSec 在回复 @Mongobug 的一条推文时说道。
• 测试人员需要注意的是，他们还需要告知所有者，发现凭证泄漏是“需要解决的问题”（例如，凭证从何而来以及如何缓解泄漏）。对于用户凭证被恶意软件窃取的情况，仅仅更改凭证并非全面的解决方案。
• 对于测试人员来说，分析应用程序在登录期间、登录后以及注销时处理的 .js 文件至关重要。在此情况下，我们发现了一个 .js 文件，其中包含有关应用程序端点（以及访问级别）的详细信息，这导致我们发现了一个存在访问控制问题的端点。在其他情况下，我们有可能找到可用于进一步攻击场景的硬编码敏感信息（例如密钥）。
• 本文还强调了在系统内进行全面测试时拥有凭证的重要性。一个应用程序从外部来看可能没什么问题，但一旦以不同的权限登录，情况可能就完全不同了。

7. 参考文献/致谢

• https://github.com/BishopFox/jsluice — 作者：BishopFox
• 渗透测试人员的 JavaScript 分析— 作者：Konstantin
• https://socradar.io/how-is-threat-intelligence-used-to-monitor-criminal-activity-on-the-dark-web/

bilibili:haidragonx