账户数据操纵的意外主 ID0

一个简单的故事，真主允许我使用意外的主 ID“0”通过损坏的访问控制问题成功实现 P1。

奉至仁至慈的真主之名。

与往常一样，我将尝试采用两种不同的方式来发布这篇文章，它们是： 

• 对于那些只需要了解这一发现要点的人（如果读者已经理解了每一个流程，InshaAllah 可以节省大量的时间）——请参阅 TL;DR 部分，并且
• 对于那些需要了解这一发现的执行流程或历程的人来说，InshaAllah，它可以告诉读者一些思维模式，并希望能够帮助人们丰富他们的见解。

请尽情欣赏这个故事。

注意：这篇文章可能很短，因为这篇文章中执行的大多数方法都已在另一篇文章中根据真主的意愿进行了解释。

一、TL;DR

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

• 应用程序中的更新功能有一个 POST 请求，由 ID、UUID、电子邮件和数据参数组成。
• 删除 UUID 参数中的值。
• 使用值 0 填充 ID 参数——该值似乎充当所有帐户的主值。
• 使用目标的电子邮件填写电子邮件参数。
• 向服务器发送请求，目标的数据就会按照攻击者的意愿发生变化。
• 感谢真主，它被标记为 P1 并获得 2,500 美元的奖励。

二、幕后

有一次，我收到一条通知，关于在我参与的其中一个项目中以 API 的形式添加一个范围内的目标（赏金计划）。这一次，范围的添加非常独特，因为没有提供 API 文档，并且直接访问 API URL 时没有任何可用信息。

我尝试了几种基本方法，例如文件/目录爬取、通过 Google Dork、Wayback Machine 和 urlscan 搜索信息。然而，我并没有找到任何有用的结果（没有可见的端点，也没有获取到任何敏感文件）。

对于那些不熟悉的人，这里有一些简单的信息可以解释我的意思：

• 文件/目录爬取可以使用dirsearch、ffuf等工具来完成。例如，使用 dirsearch 时，我们可以使用常用命令并添加一些扩展名，如下所示：python3 dirsearch.py -e apk,bak,conf,config,csv,doc,docx,git,ipa,jar,js,json,old,pdf,ppt,pptx,rar,sql,svn,tar,tar.gz,xls,xlsx,xml,zip -u target_url_here

• 对于 Google Dork，您可以参考我关于此主题的一篇文章：PayPal 和 Xoom 的信息披露（通过 Google Dork）

• 有关使用 URLScan 的示例，您可以查看h4x0r_dz 的一条推文。

• 最后，关于使用 Wayback Machine 作为搜索端点甚至子域的工具，您可以参考Internet Archive 在其官方 GitHub 页面上发布的综合文档。

至于如何使用 Wayback Machine，我们只需使用以下关键词：https://web.archive.org/cdx/search/cdx?url =*.target.tld/*&output=text&fl=original，即可搜索已被互联网档案馆“收录”的 target.tld 子域名和端点信息。如果要搜索特定的子域名，只需将开头的星号替换为目标子域名即可。

总之，我立刻就暂时放弃了这个目标（因为当时确实只想大致看看）。

III. 在赏金计划中使用 API 的 VDP 目标

几个月后，我决定重新审视一下我之前在他们的 VDP 计划（没错，就是 VDP，不是赏金计划）中测试过的一个目标，进行一些更新。当我尝试登录并观察 Burp Suite 记录的流量时，我发现该应用程序正在使用一个 API（几个月前我就弃用了它）来实现数据更新功能。这引起了我的注意，因为他们之前从未集成过这个 API。

从这一点开始，我决定测试该 API。

四、旅程

在应用程序的数据更新功能中，我发现了一个详细的 POST 请求，其中包含“id”和“uuid”的值，这些值似乎与某个帐户相关联。为了澄清起见，该请求如下所示：

id=<number_here>&uuid=<uuid_here>&email=<email_here>&Parameter1=<data1_here>&Parameter2=<date2_here> and so on

另外需要注意的是：

• 参数 1、参数 2 等——表示执行更新时与用户关联的“数据”值。
• UUID（通用唯一标识符）是一个长字符串，通常用于为应用程序内的实体提供唯一的“身份”（不限于应用程序，但为了本次讨论的目的，让我们关注应用程序级别）。
• UUID 的示例格式为：e40011c0-fa88-4e6e-8e3e-205dacc594c1（从 uuidgenerator.net - 版本 4 获取的值）。
• 使用 uuid 的好处之一通常是避免轻易“猜测” id 值 - 从而能够“最小化”应用程序中“可能”存在的访问控制中断的执行。

基于这种情况，我决定先测试一下应用程序的逻辑。总而言之，我创建了另一个账户，并执行了一些基本步骤，正如我之前在另一篇文章“2.2.1 我有两个不同类型的账户，我该怎么办？”小节中解释的那样，具体步骤如下：

• 将一个账户的 ID 值（不更改 UUID 值）更改为另一个账户。然而，正如预期的那样，这种方法效果不佳，因为 POST 请求中存在三个身份信息：ID、UUID 和电子邮件。
• 更改 UUID、电子邮件和目标的 ID 值，以便使用攻击者的会话执行。虽然这个实现很复杂，但当时我认为可能有机会从另一个端点的电子邮件中获取 ID 和 UUID 值（如果该场景成功运行）。然而，这也失败了，因为所有这些值都与活动用户会话绑定。
• 同时删除 ID 和 UUID 值，只保留电子邮件值。然而，应用程序并未显示任何成功。
• 将方法从 POST 更改为 GET（并执行前面提到的场景），但应用程序仅接受 POST 作为此数据更新功能的方法。

由于这些步骤都没有成功，我决定休息一段时间。

还记得我之前提到过，我尝试删除请求中的 ID 和 UUID 值，但失败了吗？有一次，我把 ID 参数的值设为“0”（UUID 值留空）。没想到，这次执行竟然成功修改了另一个用户的数据。 

概括来说，请求如下：

id=0&uuid=&email=<email_target_here>&Parameter1=<data1_here>&Parameter2=<date2_here> and so on

在这种情况下，ID 参数中的值 0 似乎充当主 ID，可用于修改所有用户的数据。 

发现这一点后，我立即进行了举报，不久之后，项目所有者就为这一发现悬赏了 1 比索。

这个案例问题间接地让我想起了 2018 年底发表的一篇文章，其中一名漏洞猎人使用OTP 参数中值为 000000 的“主代码”成功执行了帐户接管。

尽管已经过去了将近 6 年，但像这样的测试模型似乎仍然值得继续。

五、经验教训

在这一节的经验教训中，我没什么可写的。大部分内容在之前的文章中已经讲过了。目前想到的有：

• 一切都按照真主的旨意发生。即使我测试了 VDP 中的一个目标，该目标使用了在赏金计划范围内注册的 API，也是如此。
• 似乎没有哪个 bug 是老到无法测试的。在这种情况下，乍一看，我们可能会认为这些 bug 已经不存在了，但事实并非如此——bi'idznillah。我们永远无法知道背后的开发过程。也许是开发人员迫于时间压力，采取了额外的措施来简化某些操作（无意中造成了负面影响），又或许有其他原因。

六、参考文献

• Instagram OTP 令牌通过短链接泄露– 作者：H4x0r_DZ
• Wayback CDX 服务器 API – 来自互联网档案馆
• Dirsearch – 作者：Maurosoria
• Fuzz Faster U Fool – 作者：ffuf
• Tokopedia 账户接管漏洞，价值 800 万印尼盾– 作者：Mukul Lohar
• 在线 UUID 生成器
• Akhii  Tomi Ashari 和 Akhii  Widyanto Ardy Prabowo
• Mario Sahertian – 他是第一个向我介绍 dirsearch（以及它的一些用法）的人之一。

bilibili:haidragonx