（纯路人翻译）我是如何发现入侵iCloud账户的漏洞以及苹果对此是怎样做出回应的

译文来源：https://thezerohack.com/apple-vulnerability-bug-bounty。受个人知识所限及偏见影响，部分内容或存在过度曲解误解现象，望师傅们包含并提出建议，感谢。

本文主要讲述我是如何在苹果的忘记密码处发现一个允许我对iCloud账户实现接管的漏洞。目前该漏洞已由苹果安全团队完全修复且无法复现。作为漏洞赏金计划的一部分，苹果安全团队奖励给我$18,000，但是我却拒绝了这份赏金。 如果您愿意继续阅读本文的话就会明白我为什么拒绝了该奖励。

在我发现了Instagram的账户接管漏洞之后，我意识到，应该还会有许多其他的服务商也会存在这种基于条件竞争的暴力破解漏洞。因此，我便开始继续向诸如微软、苹果等其他受影响的服务提供商报告此类漏洞。

许多人可能会将该漏洞误以为是典型的暴力破解漏洞，但事实并非如此。我们实际的做法是通过向服务器发送大量的并发请求利用条件竞争漏洞来绕过其中的速率限制。

那现在就来告诉大家我在苹果的服务中到底发现了什么漏洞吧。

Apple ID的忘记密码功能要求我们分别输入发送到我们手机和邮箱中的OTP（一次性密码，验证码）后才能够进行修改密码的操作。只要我们输入了正确的验证码，我们就可以进行修改密码了。

出于安全原因，苹果首先会提示我们输入受信任的手机号和邮箱地址来请求发送验证码。

所以要想执行该漏洞的话，我们就需要知道用来请求验证码的受信任手机号和邮箱地址，并且我们还需要对6位数验证码的所有可能性进行尝试，这大概需要进行100万次的尝试（10的6次方）。

在测试的过程中，我发现忘记密码端点有着严格的速率限制。如果我们尝试的次数超过了5次，我们的账户就会被锁定若干小时，到了这一步的话就连尝试更换IP也都无济于事。

然后我试着向苹果服务器发送POST并发请求来实现基于条件竞争的暴力破解，但又发现了一些其他的限制。

令我感到惊讶的是，苹果是对来自单个IP地址的POST并发请求做了速率限制，不单单是在忘记密码端点处而是在苹果的整个服务器上都做了限制。我们无法发送超过6个的POST并发请求，如果这么做了，那么这些请求就会被服务器丢弃。而且除了将这些请求丢弃外还会将我们的IP地址拉黑，拉黑后的POST请求响应将会报503错误。

我天呐！限制太多了吧:(

然后我就怀疑它们可能不会容易受到此类漏洞的影响，不过还是有一线希望的，因为我发现这是对苹果整个服务器做的通用的速率限制，并不是针对验证码验证端点的。

在经过部分测试后，我得出以下几点：

1. 1.iforgot.apple.com解析到全球的6个IP地址分别是 -- (17.141.5.112, 17.32.194.36, 17.151.240.33, 17.151.240.1, 17.32.194.5, 17.111.105.243)。
2. 2.上面我们已经发现了两处速率限制，一个是当我们向忘记密码端点（http://iforgot.apple.com/password/verify/smscode）尝试操作的次数超过5次时触发的，另一个是当我们向服务器发送超过6个POST并发请求时触发的。
3. 3.这些速率限制都是针对当前IP的苹果服务器的，这也就意味着我们还是可以继续向其他IP的苹果服务器发送请求（尽管还是存在同样的限制）。
4. 4.受于这些服务器的速率限制，我们能够经由一个客户端IP向任意IP地址的苹果服务器发送的最大并发请求为6个（这一步可以通过将iforgot.apple.com与这些IP地址绑定来实现）。如上所述，我们现在有6个解析出的苹果的IP地址。所以，我们能够经由一个客户端IP地址向这6个IP地址最多发送36个请求（6*6=36）。
5. 5.也就是说，攻击者至少需要2万8千个IP地址才能完成发送100万个请求来进行验证码验证。

如果你能够借助于云服务提供商的话，28000个IP地址看上去并不难，但是最难的部分在于，当我们尝试经由像是AWS、谷歌云等云服务提供商那里发送POST请求时，苹果的服务器又出现了一个奇怪的行为。

它们甚至是没有对请求的URI或者请求主体进行检查，就直接返回502 Bad gateway 拒绝了这些POST请求。我尝试更换一批IP，但所有试过的IP也都返回了相同的响应代码，如果我没猜错的话，苹果可能已经将一些知名云服务提供商的所有ASN都列入了黑名单。

这也就让那些依赖于AWS等知名云服务提供商的人更难以实现这类攻击了。我开始不断尝试寻找其他的云服务提供商，最后终于找到了有几个提供商的网络IP还没有被苹果列入黑名单。

然后我尝试利用不同的IP地址发送多个POST并发请求以验证绕过效果。

终于是成功了！现在只要我有他们受信任的手机号就可以来修改任一Apple ID的密码了。

当然，要想执行这个攻击并不容易，我们还需要有一套完备的计划才能成功地利用这个漏洞。首先，我们需要绕过短信中的6位数验证码，然后再绕过电子邮件中的6位数验证码。这两种绕过都是基于相同的手法和环境，所以我们在尝试第二种绕过时不需要做任何的改动。即便是用户开启了双因素认证，我们也仍然可以访问到他们的账户，因为双因素验证端点也存在同样的速率限制和该漏洞。并且同样的漏洞还出现在了密码验证端点中。

我于2020年7月1日向苹果的安全团队报告了这一信息，并提供了详细的复现步骤和演示绕过的视频。苹果安全团队在接到报告的几分钟内就承认并处理了这个问题。

但是我随后的一段时间内并没有得到来自苹果公司有关该漏洞状态的任何更新，我便开始一直跟进漏洞更新状态，他们说他们正在努力于2020年9月9日对该问题进行修复。

同样的问题，在接下来的5个月里还是没有收到任何更新，我再次询问其有关动态，却收到了这份邮件

在邮件中他们说，他们正计划在接下来的安全更新中解决这个问题。但是我不禁会想，为什么他们会在如此关键的漏洞上花这么长的时间来进行响应呢。

我一直在对这个漏洞进行复测，想知道它是否已被修复，而不是再依靠与苹果团队进行沟通来获取漏洞状态。我于2021年4月1日进行了测试，发现该漏洞被修复了，但苹果公司却仍然没有更新我的漏洞状态。我再次询问他们该问题是否已被解决，但得到的答复是一样的，他们没有任何漏洞状态更新可以分配。

我非常耐心地等着他们的状态更新。一个月后，我写信给他们说，这个问题已经在4月1日的时候就已经修复完毕了，为什么漏洞状态还不更新，我还告诉他们，我有意在我的博客上将该报告对外披露。

于是苹果安全团队问我是否可以在发表前将文章的草稿分享给他们。但也就在这时，事情开始出现了意外。

在分享了文章草稿之后，他们拒绝了我的要求，说这个漏洞并不满足对大多数的iCloud账户进行账户接管。以下是他们的回复：

正如你们在邮件截图中看到的那样，他们的分析表明，该漏洞只对那些在未受密码保护的苹果设备上所使用的iCloud账户起作用。

而我认为，不管要求输入的是目标设备的密码（4位到6位的样子）还是将6位数的验证码发送到账户邮箱中，它都会具有相同的速率限制，并且都将容易受到基于条件竞争的暴力破解攻击。而且我们也将能够发现账户相关苹果设备的密码。

此外，我还注意到他们的支持页面在忘记密码方面的一些改动。

详见链接：https://support.apple.com/en-in/HT201487

上面的截图显示了网页现在的样子，但在我上报此漏洞之前，它并非如此的。

在2020年10月份的时候，网页是下面这样：

相关链接来自archive网站的快照：

https://web.archive.org/web/20201005172245/https://support.apple.com/en-in/HT201487

“In some cases（在某些情况下）”是在2020年10月份对这段话的前缀，那也正是在我被告知他们将于2020年9月份修复该漏洞的时候。

看上去这好像是被特意安排过的，页面被修改成支持他们说法的样子，即只存在有限的用户是易受威胁的。那个网页已经很多年没有进行更新了，但就在我的报告之后却出现了一个小改动。这看起来并不像是一个巧合吧。

当我问及此事时，他们说这些更新是由于iOS 14的修改而进行的。我又问，使用受信任的邮箱地址/手机号码进行重置密码和iOS 14有什么关系？如果是你们说的那种情况，那在iOS 14之前，难道在重置密码的时候不是用的那些受信任的手机号码和电子邮件吗？如果我的说法没错，那我的报告将适用于所有的苹果账户。但就这一问题我并没有得到他们的任何答复。

我当时对他们的反馈还感到挺失望的，并且告知他们，我打算不经他们批准就直接将该漏洞的细节写博客披露出来。以下是他们给我的答复。

他们给我安排了与苹果团队工程师的一次通话，解释了他们在分析中发现的问题，也回答了我可能提出的所有问题。

在通话过程中，我问为什么它与我发现的漏洞不同。他们回答，密码并没有发送到任何的服务器端点，而是在设备本身进行的验证。我争辩说，如果不与苹果服务器进行交互的话，那么那些随机的苹果设备是不可能知道另一台设备的密码的。他们说，数据确实是被发送到了服务器，但它是通过某种加密手段来进行验证的，出于安全考虑，他们不能透露更多细节。

我又问，如果我们通过逆向找出加密过程并复制该方法，然后通过并发请求对苹果服务器进行暴力破解怎么办？对于这个问题，我没有得到任何明确的答案。他们的结论是，暴力破解密码的唯一方法是通过向苹果设备进行暴力破解，而由于本地系统的速率限制，这是不可能的。

我无法接受苹果工程师的说法，从逻辑上来讲，复制苹果设备在向服务器发送数据时的方法应该是可行的。

我想亲自验证一下来证明这些方法是否真的可行。如果他们说的是真的，密码验证端点应该是容易受到基于条件竞争的暴力破解攻击的。在经过若干小时的测试后，我发现他们还真的有专门针对密码验证端点的SSL接口，也正因如此，发往服务器的流量就不能被像是burp/charles这样的MITM代理软件读取到。

不过多亏了有checkra1n和SSL Kill Switch，利用这些工具我就能够绕过接口读取到发送给服务器的流量了。

后来我发现，苹果使用了SRP（安全远程密码），这是一个PAKE协议，用来验证用户是否知道正确的密码，而不需要真正的把它发送到服务器中。所以苹果工程师之前的说法是对的，他们并没有直接将密码发送到服务器上。相反，服务器和客户端之间都使用先前已知的一些数据进行数学计算，以推导出一个密钥（这种方法更像是diffie-hellman密钥交换算法）。

在不涉及到SRP具体内容的前提下，让我来简单说说在我们的环境中那些关键点。

• 1.苹果服务器中有两个预存储的值，即在设置或更新密码时就为每个用户创建了的 verifier 和 salt 。
• 2.每当用户凭借用户名和暂存值A发起SRP认证时，苹果服务器就会用相指定用户的 salt 和暂存值B做出回应。
• 3.客户端使用从服务器获得到的 salt 来对SRP-6a所规定的密钥进行计算。
• 4.服务器使用 salt 和 verifier 来计算SRP-6a所规定的密钥。最后，它们都向对方证明所得到的密钥是相同的即可。

此处了解有关更多关于SRP-6a计算的方法。

众所周知，SRP可以防止暴力破解攻击，因为它有针对不同用户的 salt 和 verifier ，所以即便是有人盗取了我们的数据库，他们仍然需要对每个用户进行CPU密集型的暴力破解，才能逐一发现密码。但这对于受影响的服务提供商来说，已经有了足够的时间来进行响应了。

但是，在我们的案例中，我们并不需要对大量的账户进行暴力破解，只需对单个用户进行暴力破解，就足以成功访问他们的iCloud账户，并发现他们的设备密码等。

正常来说，只有当你同时拥有目标用户的 salt 和 verifier时，暴力破解才有可能成功。不过当我们可以绕过短信验证码后，我们就能够很容易地冒充目标用户并获取到 salt 。但现在这里的问题是verifier。我们应该以某种方式从服务器上获取到verifier ，或者绕过密钥验证端点的速率限制。

如果绕过了该速率限制，我们可以不断尝试使用预先计算的密码值所获得的不同组合的密钥，直到我们碰上了匹配的密钥为止。显然，要推导出每个4位或6位数的密码（从0000/000000到9999/999999）的密钥，需要大量的计算工作。

当我们在重置密码时，需要在iPhone/iPad上输入密码，设备通过发送从短信成功验证中获得的用户会话令牌发起SRP认证请求。服务器回复相应用户的 salt 。通过对密码和 salt 进行散列计算，然后得出最终的密钥，并将其发送到https://p50-escrowproxy.icloud.com/escrowproxy/api/recover，以验证它是否与服务器中计算得出的密钥（使用暂存值、 salt 和 verifier 计算所得）相符。

而验证密钥发送的POST请求如下所示：

String标签中有上述提到的所有数据，但都是以DATA BLOB格式发送的。我想检查的第一件事就是在解码BLOB格式的值之前的是否存在速率限制。我同时发送了30次请求，来看看该端点是否存在漏洞。

出乎我意料的是，它并不存在漏洞，在30个请求中，有29个是以内部服务器错误作为响应被拒绝的。

速率限制或许是在苹果服务器本身上或是在HSM（硬件安全模块）中进行的。无论是以哪种方式，速率限制逻辑也都应该被设计成这样，以防止条件竞争的风险。在我的报告该漏洞之前，我还以为这个端点不受条件竞争风险影响的可能性是非常小的，因为我所测试的所有其他端点都是存在这个漏洞的--短信验证码验证、邮箱验证码验证、双因素验证、密码验证。

如果他们在我的报告之后确实打了补丁，那么这个漏洞就变得比我预想的要严重的多了。通过暴力破解密码，我们将能够通过区分不同的响应来识别出正确的密码。这样的话，我们不仅可以接管任意iCloud账户，还可以发现与之相关的苹果设备的密码。尽管攻击流程很复杂，但如果我的猜想正确的话，这个漏洞可以入侵任何受4位数/6位数密码保护的iPhone/iPad。

但由于之前的测试中它正确的验证了并发请求，我就没法进一步验证我的猜想了，我唯一能做的也就是写信给苹果公司，但他们在这方面也没有给予任何答复。

在2021年的6月4日，我收到来自苹果公司的赏金邮件。

在苹果官网中提到的iCloud账户接管漏洞的实际赏金是10万美金。从锁定的苹果设备中提取处敏感数据的漏洞赏金是25万美金。我的报告涵盖了这两种情况（假设密码验证端点在我的报告后打了补丁的话），所以实际的奖金应该是35万美金。即便他们选择授予这两种情况中影响最大的那一个，也应该是25万美金。

如果将这些漏洞卖给政府机构或是向zerodium这样的私人赏金项目，我可以赚到更多的钱，但我还是选择了更道德的方式，我并不期待有什么比苹果公司列出更高奖金的其他东西。

https://developer.apple.com/security-bounty/payouts/

但1万8千块美元的赏金与实际的赏金确实相差甚远。假设我所有的假设都是错误的，而且在我的报告之前，有关苹果的密码验证端点并没有漏洞。即便如此，从漏洞的影响程度来看，给出的赏金也是不公平的，评判标准如下所示：

• 1.绕过了双因素验证。 在该绕过方式下，双因素验证简直就像是不存在一样。那些依赖于双因素验证的用户本身就非常容易收到攻击。这本身就是一个重大的漏洞。
• 2.绕过了密码验证速率的限制。所有使用常见/脆弱/已被黑密码的Apple ID的账户都是脆弱的，即便是他们开启了双因素验证也于事无补。一旦被黑，攻击者可以跟踪设备的位置，以及远程擦除设备。2014年名人iCloud被黑的事件主要就是由弱口令导致的。
• 3.绕过了短信验证。如果我们知道了与iCloud账户相关联设备的密码，就会发现这个漏洞了。假设你的朋友或家人知道了你的设备密码，利用该漏洞，他们就可以接管你的iCloud账户，也可以通过互联网远程删除你的整个设备，而无需对其进行物理接触。
• 4.由于短信和邮箱验证码验证都被绕过，我们可以接管所有未与受密码保护苹果设备绑定的Apple ID，具体指：
• 1.任何没有密码的苹果设备，像是关闭或没有设置密码功能的那些人。
• 2.任何在没有苹果设备的情况下创建的Apple ID，像是那些在浏览器或是安卓应用中创建的，并且没有在受密码保护的苹果设备中使用的Apple ID。
• 3.比方说，有5000多万的安卓用户已经下载了Apple Music应用。虽然在这些人中，大多数人可能并没有使用苹果设备。但他们仍然是苹果用户，他们的信息，如信用卡、账单地址、订阅细节等都有可能被暴露。

我认为苹果公司就算不给出iCloud账户接管赏金的上限（10万美金），但考虑到它所造成的影响，至少应该接近这个上限吧。

在我所有的努力和近一年的等待之后，由于苹果的不公正判断，我没有得到我应得的东西。所以我拒绝接收该赏金，并告诉他们这种做法是不公平的。我要求他们重新考虑赏金的决定，或者让我发表包含该漏洞所有信息的报告。但我的邮件没有得到任何回复。所以我决定将该文章披露出来，不再无限期的等待他们的回应。

因此，我以无偿的方式而不是不公平的价格与苹果公司分享了我的研究。

我要求苹果公司的安全团队至少在未来要更加的透明和公平。我也非常感谢苹果公司对此漏洞的修复。最后重申，该漏洞已完全修复，上述复现场景不再有效。