我如何发现易受困难的易受伤害，以及苹果如何对其作出反应

本文是关于如何在Apple忘记密码端点上发现漏洞的漏洞允许我接管iCloud帐户。易受培训性完全由Apple Security团队修补，它不再有效。 Apple Security团队作为其赏金计划的一部分奖励我18,000美元，但我拒绝收到它。请阅读文章以了解为什么我拒绝赏金。

在我的Instagram帐户收购漏洞之后，我意识到许多其他服务易受争夺危险的蛮力。因此，我与Microsoft，Apple和其他一些类似的受影响服务提供商报告了同样的报告。

许多人将这种脆弱性误认为是典型的蛮力攻击，但它不是。在这里，我们正在向服务器发送多个并发请求，以利用速率限制中存在的竞争条件漏洞，使得可以绕过它。

Apple ID的忘记密码选项允许我们使用6位数OTP发送到我们的手机号码和电子邮件地址的密码更改我们的密码。我们输入正确的OTP后，我们将能够更改密码。

出于安全原因，Apple将提示我们输入可信电话号码以及电子邮件地址以请求OTP。

因此，为了利用此漏洞，我们需要了解可信电话号码以及他们的电子邮件地址来请求OTP，并且必须尝试6位数代码的所有可能性，这将是约100万次尝试（10 ^ 6）。

至于我的测试，忘记密码端点具有相当强的速率限制。如果我们输入超过5次尝试，我们的帐户将被锁定在接下来的几个小时内，甚至旋转IP没有帮助。

然后我试图通过向Apple服务器发送同时发布请求并找到更多限制来进行种族危险的野蛮强制。

令我惊讶的是，Apple具有来自单个IP地址的并发张贴请求的速率限制，而不仅仅是忘记密码端点，而是给整个Apple服务器。我们无法发送超过6个并发的邮政请求，它将被删除。它不仅仅被删除，但我们的IP地址将被列入未来的帖子请求，以503错误。

所以我认为他们并不容易受到这种类型的攻击😔，但仍有一些希望，因为这些是服务器上的通用速率限制，而不是特定于代码验证端点。

iforgot.apple.com解决全球的6个IP地址 - （17.141.5.112,17.32.194.36,17.151.240.3,17.151.240.1,17.32.194.5,17.311.105.243）。

我们上面看到了两个速率限制，当我们发送超过5个请求忘记密码端点时（http://iforgot.apple.com/password/verify/smscode），另一个是触发的，当时我们发送超过6个并发的发布请求。

这些速率限制都是特定于Apple Server IP的，这意味着我们仍然可以发送请求（虽然以限制）到另一个Apple服务器IP。

我们可以根据其限制将最多6个并发请求从单个客户端IP地址绑定到Apple Server IP（通过将iforgot.apple.com绑定到IP）。如上所述，有6个Apple IP地址已解决。因此，我们可以从单个IP地址发送6个Apple IP地址（6 x 6 = 36）的高达36个请求。

因此，攻击者需要28K个IP地址来发送多达100万的请求以成功验证6位数代码。

28K IP地址看起来很简单，如果您使用云服务提供商，但在这里最困难的部分，当我们尝试发送来自AWS，Google云等云服务提供商的发布请求时，Apple服务器具有奇怪的行为。

它们拒绝使用502个不良网关拒绝未经检查请求URI或Body的POST请求。我尝试改变IPS但是所有这些都返回了相同的响应代码，这意味着如果不是错误的话，他们已将整个ASN列入整个ASN的整个ASN

对于那些依赖于AWS​​等知识云服务的人来说，它会恢复剧烈。我一直在尝试各种提供商，最后发现了一些服务提供商，他们的网络IP没有黑名单。

然后我尝试从不同IP地址发送多个并发的帖子请求以验证旁路。

它的工作！ 🎉🎉🎉现在我可以只用他们可信电话号码更改任何Apple ID的密码😇

当然，攻击不容易做到，我们需要有一个正确的设置来成功利用此漏洞。首先，我们需要绕过SMS 6位数代码，然后在电子邮件地址中收到6位数代码。旁路都基于相同的方法和环境，因此我们在尝试第二旁路时无需更改任何内容。即使用户启用了两个因素身份验证，我们仍然能够访问其帐户，因为2FA端点也共享速率限制并易受攻击。密码验证端点中也存在相同的漏洞。

我向2020年7月1日向苹果安全团队向苹果安全团队展示了这个信息，并将其展示了旁路的视频。Apple安全团队在几分钟内承认并定制了这个问题。

在分类后我没有从Apple获得任何更新，以便我继续跟进状态更新，并表示他们在2020年9月9日的修复程序上工作。

再次，未来5个月没有更新，然后在我要求身份时发出此电子邮件

他们表示他们计划在即将到来的安全更新中解决问题。我想知道他们对他们来说是什么需要做出反应的脆弱性。

我一直在重新测试脆弱性，以知道它是否固定而不是依赖于它们。我于4月1日测试了2021年，并实现了漏洞的补丁被释放到生产，但仍然没有来自Apple的更新。我问他们是否正在修补问题，并且响应与它们没有共享的状态更新相同。

我耐心等待他们更新状态。一个月后，我写了他们在4月1日本身修补了这个问题，为什么我也没有更新它，我也告诉我想向我的博客发布该报告。

Apple Security团队向我询问了是否有可能在出版之前与他们分享文章草案。那是事情开始出乎意料的时候。

分享草案后，他们否认我的索赔称，此漏洞不允许收购icloud帐户的多数。这是他们的回应

正如您在电子邮件屏幕截图中看到的，他们的分析显示，它只针对缺消码/密码保护Apple设备中未使用的iCloud帐户工作。

我认为，即使被问到设备密码（4位或6位数）而不是发送给电子邮件的6位数代码，它仍将共享相同的速率限制，并且将容易受到基于Rach条件的Brute强制攻击。我们还将能够发现相关Apple设备的密码。

上面的屏幕截图显示了页面现在如何看待，但在报告之前它不一样。

“在某些情况下，”在2020年10月20日10月的段落上，这是我被告知他们在2020年9月的修复工作之后。

它看起来像一切计划，页面已更新，以支持他们只有有限的用户脆弱的索赔。该页面未更新多年，但在报告后获得次要更新。它看起来并不像巧合。

当我询问它时，他们表示由于iOS 14的变化，使用可信电子邮件/电话号码重置密码的更新与IOS 14提出。如果是真的，是可信电话号码和用于在iOS 14之前重置密码的电子邮件？如果是这种情况，我的报告适用于所有Apple帐户。我没有得到他们的任何答案。

我很失望，并告诉他们，我将在没有等待他们的批准的情况下用所有细节发布博客帖子。这是我从他们那里得到的回复。

他们安排了与Apple Team工程师的呼吁来解释他们在分析中发现的内容，也可以回答我可能拥有的任何问题。

在呼叫期间，我问为什么它与我发现的漏洞不同。他们说，密码未被发送到任何服务器端点，并在设备本身中验证。我认为随机苹果设备无法知道另一个设备的密码而无需联系Apple服务器。他们表示，数据是发送给服务器的，但是使用加密操作进行验证，并且由于安全问题，它们无法透露超过这一点。

如果我们通过逆向工程求出加密进程以复制它并使用并发请求的Apple Server来询问加密进程，请询问何您。我没有得到这个问题的明确答案。他们得出结论，蛮力的唯一方法是通过暴力强制苹果设备，这是由于本地系统速率限制不可能。

我无法接受Apple工程师逻辑地说的是什么，应该可以复制Apple设备在向服务器发送密码数据时正在进行的事情。

我想验证自己是否证明他们。如果他们所说的是真的，密码验证端点应该容易受到基于比赛条件的蛮力。经过几个小时的测试后，我发现它们具有特定于密码验证端点的SSL Pinning，因此MITM代理如Burp / Charles都无法读取发送到服务器的流量。

感谢Checkra1n和SSL杀死交换机，使用其工具我能够绕过钉扎并读取发送到服务器的流量。

我想出，Apple使用SRP（安全远程密码），探测用户知道右密码的州协议而不实际将其发送到服务器。所以工程师所说的是对的，它们没有直接向服务器发送密码。相反，两个服务器和客户端都使用先前已知的数据进行一些数学计算来派生在密钥（更像Diffie-Hellman密钥交换机）。

如果没有进入SRP的细节，让我直接到我们上下文中有必要的东西。

Apple服务器有两个存储的值，即验证者和特定于设置或更新密码时创建的每个用户的验证器和盐。

每当用户发起用户名和截阵短暂值A的SRP身份验证时，Apple Server会用特定用户的盐和短暂值B响应回来。

已知SRP可防止攻击具有特定于用户特定的盐和验证者，因此即使有人窃取我们的数据库，它们仍然需要为每个用户执行CPU密集型BruteForce，以逐个发现密码。这对受影响的供应商提供了足够的时间对其作出反应。

但是，在我们的案例中，我们不必让大量的帐户。 Bruteforcing Single User足以进入其iCloud帐户以及查找密码。

只有当您具有特定于目标用户的盐和验证程序时，才能强制迫使。在绕过SMS密码之后，我们可以轻松地作为目标用户模拟并获得盐。但这里的问题是验证者。我们应该以某种方式从服务器获取验证者或绕过键验证端点上的速率限制。

如果绕过速率限制，我们可以继续尝试使用密码的预先计算的键的不同组合，直到我们到达匹配键。显然，它需要大量的计算来导出每个4或6位数字密码（从0000/000000到9999/999999）的键）。

当我们在密码重置期间在iPhone / iPad中输入密码时，设备通过发送从成功的SMS验证获得的用户会话令牌来启动SRP身份验证。服务器随着各个用户的盐响应。密码和盐将被散列，然后派生将发送到https://p50-escrowproxy.icloud.com/escrowproxy/api/rocover的最终键，以检查它是否与计算的密钥（使用短信，盐和验证器）匹配在服务器上。

字符串标记具有上述所有数据，但以数据斑点格式发送。我想检查的第一件事是解码BLOB值之前的速率限制。我同时发送30次请求以检查端点是否易受攻击。

为了我的震惊，它并不脆弱。在30个请求中，其中29个被拒绝内部服务器错误。

速率限制将在Apple服务器本身或HSM（硬件安全模块）中执行。无论哪种方式，应编程速率限制逻辑，以防止竞争危险。在我的报告前没有易受争夺危险的机会很脆弱，因为我测试的所有其他端点是易受攻击的 - 短信代码验证，电子邮件代码验证，两个因子身份验证，密码验证都是脆弱的。

如果他们在报告后做了补丁，那么脆弱性比我最初想到的更严重。通过浏览密码，我们将通过区分响应来识别正确的密码。因此，我们不仅可以收购任何iCloud帐户，还可以发现与其关联的Apple设备的密码。即使攻击很复杂，如果我的假设是对的话，这个漏洞可能会破坏任何具有4位/ 6位数字密码的iPhone / iPad。

由于现在正常验证并发请求，因此我无法验证我的索赔，我可以通过写入Apple的唯一方法来证实这一点，但他们在这方面没有给出任何回应。

在Apple网站上提到的iCloud帐户收购的实际赏金是100,000美元。从锁定的Apple设备中提取敏感数据是250,000美元。我的报告涵盖了这种情况（假设PassCode端点在报告后修补），因此实际赏金应为350,0000美元。即使他们选择奖励两种情况的最大影响，它仍然应该是250,000美元。

将这些脆弱性销售给政府机构或私人赏金课程，如零化可能会让更多的资金赚更多。但我选择了道德方式，我没有想到任何苹果所概述的赏金数量。

但是18,000美元的USD甚至没有接近实际的赏金。让我们说出我的所有假设是错误的，Apple PassCode验证端点在报告前没有易受攻击。即便如此，给定的赏金也不公平地看待下面给出的脆弱性的影响。

绕过了两个因子认证。它真的像2FA，由于旁路而不存在。所有依赖2FA的人都很脆弱。这本身就是一个重大脆弱性。

绕过密码验证率限制。即使启用了两个因素身份验证，使用常用/弱/抖动密码的所有Apple ID帐户都是易受攻击的。一旦被黑攻击，攻击者可以跟踪设备的位置，并远程擦除设备。 2014年名人iCloud Hack主要是因为密码薄弱。

绕过短信验证。如果我们知道与iCloud帐户关联的设备的密码或密码。让我们说，任何朋友或亲戚都知道您的设备密码，使用此漏洞，他们可以接管iCloud帐户，并可以通过Internet远程擦除整个设备而不对其进行物理访问。

我们可以收取与密码保护的Apple设备无关的所有Apple ID，由于SMS和电子邮件验证码旁路，这意味着任何没有密码或密码的Apple设备，就像任何关闭或未设置密码/密码的任何人。

没有Apple设备创建的任何Apple ID，就像在浏览器中或Android应用程序中，而不是在密码受保护的Apple设备中使用

例如，5000万+ Android用户已下载Apple Music App。在那些中，他们中的大多数可能没有使用Apple设备。它们仍然是Apple用户及其信息，如信用卡，计费地址，订阅详细信息等。

他们不需要奖励iCloud账户收购的上限（$ 100k），但考虑到它创造的影响，它至少应该接近它。

毕竟我的辛勤工作和近一年的等待着，我没有得到我所应得的，因为苹果不公平的判断。所以我拒绝收到赏金并告诉他们它是不公平的。我要求他们重新考虑赏金决定或让我通过所有信息发布报告。没有任何对我的电子邮件的回复。所以我决定发布我的文章，而不无限期地等待他们的回应。

因此，我与Apple免费分享了我的研究，而不是不公平的价格。

我要求Apple安全团队至少在未来更加透明和公平。我要感谢Apple修补漏洞。

我重复，漏洞完全固定，上面描述的场景不再有效。谢谢阅读文章！请告诉我您的意见中的想法。

下次评论下，在此浏览器中保存我的姓名，电子邮件和网站。