我和Omar发现了一个次要上下文漏洞，使我们能够接管整个公司。以下是我们在目标系统中发现的内容及我们的测试方法。这项研究包含所有的漏洞分析，总共耗时约三周。
首先，我们将解释如何发现这一漏洞。
在测试目标系统时，我们发现一个端点在请求被修改后返回了异常响应。当在路径末尾添加特殊字符时，系统抛出了错误，这引起了我们的注意……
img正如你所看到的，在响应中返回了一个看起来很有趣的路径。当你观察请求和响应中的路径时，它们似乎有些相似，但响应中的路径显得更长。起初，我们推测响应中的路径是后台 API。下面这张图片可以更清楚地解释这一点。
img我们首先想到的，也是你可能会想到的，就是我们是否可以以某种方式访问这个后台 API？
我们立即尝试使用路径遍历来访问后台 API。
img并检查了 JS 文件，发现了一个未使用 WAF 的生产环境域名。这个域名对我们来说至关重要。
img经过检查，我们发现该域名使用的 API 和数据库与我们测试的主域名相同。
当我们意识到这一点后，立即尝试使用路径遍历来获取目标的次要上下文，但过程中遇到了一个有趣的 404 请求。
img你可能会问，为什么一个 404 错误响应会有趣？但如果我们在目标上不使用路径遍历直接触发 404 请求，就会发现其中的不同之处。
img这清楚地表明，当 404 错误响应与前端 API 不同时，我们成功访问到了后台 API。
此时，我们确认已经获取了目标后台 API，但仍然面临一个问题：虽然返回了 404 响应，我们却不知道如何访问内部端点，感觉有些迷失方向。
当然，我们尝试了 Fuzzing，结果出乎意料——它竟然奏效了！
我们在内部发现了一个 application.wadl 端点，它包含了该微服务的所有内部端点，而这个微服务正是负责后台 API 中支付系统的文档管理。
一个重要的细节是，这些微服务运行在不同的内部域名上，而它们的映射由前端 API 决定。例如，前端 API 中的路径 /b2cSRV_NewSim/ 对应后台 API 的路径 /company/new/sim。然而，该微服务的内部域名是不同的，使用的是一个内部域名 [http://uat-satellite.redacted.com/]。需要注意的是，这仍然属于我们发现的生产环境域名。
img这些图表展示了前端 API 如何将请求路由到内部后台 API，揭示了内部域名和端点结构。
img我之所以解释这一点，是因为我们在一个微服务中发现的 application.wadl 仅存在于负责支付系统的微服务中。
img我们找到的 API 端点文件包含了该微服务的所有端点。
其中有一个有趣的端点是 /extractOrderDocument/{id}/。
我们显然尝试请求该 PDF 文件，结果返回了一个巨大的文件。
img让我们看看这个 PDF 文件包含了什么？
img员工的指纹信息
img正如你所看到的，我们访问到了泄露个人身份信息（PII）和真实指纹的内部员工文件。
在深入研究 application.wadl 时，我们发现了一个路径，它通过后台 API 根据手机号码获取所有客户的发票。
img该请求通过手机号码获取一个链接。响应是一个加密链接，其中包含发票。
img它通过客户的手机号码获取个人身份信息（PII）。
我们是如何访问到该公司控制下的3000多家公司？
在研究的第二周，我们尝试访问更多端点，但没有找到任何有用的内容。如我上面所解释的，前端路径 /soa_b2b_billGen/v1 只列出了所有微服务的端点。
我们完全迷失在其中，但我们没有放弃，继续深入挖掘并进行 Fuzzing！
img这些资源帮助我们找到了一个超级管理员面板。
img但我们遇到了一个问题，响应返回了 405 Method Not Allowed 错误。我们将其更改为 POST 方法，但前端仍然返回 405 Method Not Allowed 错误。
img这意味着前端 API 只接受 GET 方法来通过后台 API 进行处理。也意味着超级管理员登录只会通过后台接受 POST 方法。
img因此，我们需要找到一个易受次要上下文路径遍历攻击的 POST 请求。
经过长时间的搜索，我们终于找到了！
img我们访问到了内部管理员登录页面。这一刻既充满了喜悦，也让人沮丧，因为它要求输入账户。
然而，在响应中，我们找到了一个 JavaScript 文件，我们进行了检查，发现它包含了内部端点。
但页面上有验证机制，这意味着我们需要获取登录凭据，否则什么都做不了。
我们想，为什么不尝试一些默认凭据呢？或许我们能运气好一下？但遗憾的是，没能成功。
后来，我们意识到我们可以进行用户名枚举，因为错误消息会揭示用户名是否错误，或者只是密码问题。
img当我们达到了这一点时，我们希望能够以某种方式获得访问权限。我们尝试使用常规密码字典进行暴力破解，但没有成功。
我们开始失去希望，几乎决定放弃，转而做其他事情。但随后，我们决定再尝试一次。
我们想，为什么不创建一个自定义字典呢？于是，我们回到我们共享的笔记中，继续工作，试图收集任何与公司相关的单词，看看是否能帮到我们。我们使用 Burp Suite 的 GAP 插件来帮助我们收集所有的单词/参数。
在 ChatGPT 的帮助下，我们收集了大约 70,000 个自定义密码，并去重了其中的重复词汇。
我们再次尝试暴力破解，使用我们自己制作的字典，结果成功了！
那一刻，我们超级兴奋，因为我们获得了超级管理员的访问令牌。
img现在我们完全控制了公司的超级管理员面板，这意味着我们控制着超过 3000 家公司，包括公司所有的分支机构。
img我们可以更改密码以及任何敏感信息。
img绕过 KYC 检查进行号码转移，导致账户和号码接管
这是一家电信公司，这意味着如果我们接管了号码，用户将无法再访问该号码。
它涉及验证客户身份，以确保他们请求的合法性，从而防止诸如未经授权的 SIM 卡交换或身份盗窃等欺诈活动。
该过程的一个关键方面是 文件验证，客户需要提供官方身份证明以证明其身份。
这可能包括政府颁发的身份证件，如护照、国家身份证或驾照。
在我们的测试中，当我们尝试在不与后台交互的情况下发起原始请求时，系统返回了 417 Expectation Failed 错误。
这表明请求未通过系统的 KYC 检查，阻止了我们将受害者的号码转移到我们的文档和另一个电信运营商。
img在尝试通过后台 API 发起请求后，请求成功通过，并将号码与我的文件一起转移到了另一家运营商！
img我们成功绕过了 KYC 验证过程，并成功将任何电话号码转移到攻击者的文件和选择的电信运营商。
这是一个图示，可以完美地解释这一过程。
img我们是如何访问所有用户和公司数据并绕过之前所有漏洞的？
在测试公司时，我们报告了许多访问控制漏洞，并且这些漏洞已经被修复。
img然而，我们想，为什么不尝试访问后台 API 并绕过我们之前的报告呢？
img通过这项技术，我们绕过了之前提交的 20 多个报告，对于那些想知道后台 API 路径的人来说，它是通过在路径中生成错误来获得的。
让我们深入探讨一下为什么会发生这种情况。
身份验证和授权检查仅在 前端 API 中执行，这使我们能够通过直接请求 后台 API 完全绕过这些检查。
img
img我们没有发送正常的请求，而是使用路径遍历 [../../] 来打破预期的请求流程，直接访问了一个敏感的后台端点。
前端 API 看到了一个正常的请求并转发了它，没有进行阻止。然而，后台 API 以不同的方式解释了这个请求，并在不需要身份验证的情况下返回了用户数据。
之所以有效，是因为前端 API 没有执行适当的请求清理，而后台 API 以不同的方式规范化路径，导致请求的解释出现不匹配。
为什么会有效？
我们发送的请求对 前端 API 来说看起来是正常的，因此没有被阻止。但一旦到达 后台 API，它以不同的方式被解析。
声明：⽂中所涉及的技术、思路和⼯具仅供以安全为⽬的的学习交流使⽤，任何⼈不得将其⽤于⾮法⽤途以及盈利等⽬的，否则后果⾃⾏承担。
原文始发于微信公众号（白帽子左一）：从400状态码到接管整个组织控制台
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论