聚焦源代码安全，网罗国内外最新资讯！
编译：奇安信代码卫士
作者详述了自己如何从苹果“忘记密码”端点上找到漏洞从而接管 iCloud 账户的过程。该漏洞已由苹果公司修复且不再起作用。虽然苹果安全团队奖励了1.8万美元的奖金但作者认为不公因此并未接受。在文中他也详细说明了自己做出这一决定的理由。以下为博客原文编译。
发现漏洞
我找到 Instagram 账户接管漏洞后，意识到其它很多服务也易受基于竞争危险的暴力攻击，因此我将同样的问题告知微软、苹果等公司。
很多人认为这个漏洞是典型的暴力攻击，但实际上并非如此。我们是向服务器发送多个并发请求以利用存在于速率限制中的竞争条件漏洞并绕过。
如下是从苹果公司中发现的情况。
Apple ID 的 “忘记密码“选项可使我们使用分别发送到手机和邮件的6位数 OTP 更改密码。输入正确的 OTP 后我们就可以更改密码。
出于安全考虑，苹果将提示我们需要输入受信任电话号码和邮件地址才能请求 OTP。
因此，为利用该漏洞，我们需要知道受信任电话号码及其邮件地址来获取 OTP 且必须尝试所有的6位数代码的可能性，而这种可能的尝试次数大约为100万次。
在测试过程中发现，“忘记密码“端点的速率限制较强。如果我们的输入尝试次数超过5次，则账户会被锁定几个小时，甚至改变 IP 也无济于事。
之后我尝试基于竞争危险的暴力攻击，向苹果服务器发送同步 POST 请求并找到更多的一些限制。
令人惊讶的是，苹果对单个 IP 地址的并发 POST 请求具有速率限制，不仅对“忘记密码”端点而且对整个苹果服务器具有限制。我们无法发送超过6个 POST 请求，否则会被释放。另外，我们的IP 地址也会在之后的 POST 请求中被列入黑名单，出现 503 错误消息。
我的天，这也太多了吧！
因此，我原以为这些速率限制不易受这种攻击，不过仍然心存希望，因为它们是整个服务器中的速率限制而不仅仅针对具体的代码验证端点。
经过一些测试后，我发现几点。
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、我们看到上面的两种速率限制，其中一个是当我们向“忘记密码”端点 (http://iforgot.apple.com/password/verify/smscode) 发送超过5个请求时触发的，另外一个当我们发送超过6个并发 POST 请求时在整个苹果服务器触发的。
3、这两种速率限制仅限于苹果服务器 IP，这意味着我们仍然可向另外一个苹果服务器 IP 发送请求（当然在限制范围内）。
4、我们可以从单个客户端 IP 地址向苹果服务器IP 发送最多6个并发请求（绑定 iforgot.apple.com 和 IP）作为其限制。如上所示共解析了6个苹果 IP 地址。因此我们可以通过单个 IP 地址在6个苹果 IP 地址中共发送36个请求。
5、因此，要求攻击者通过28K 个 IP 地址发送最多100万个请求，成功验证6位数代码。
如果使用云服务器的话，28K 个IP 地址似乎并不难，不过最难的部分在于，当我们从云服务提供商如 AWS、谷歌云等发送 POST 请求时，苹果服务器会呈现一种奇怪的行为。
他们在甚至不会检查请求 URI 或主体的情况下就会拒绝502 Bad 网关的 POST 请求。我尝试更改 IP，但所有的IP 都返回相同的响应代码，这意味着某些云服务提供商的整个 ASN 均被列入黑名单。
这就使想通过声誉良好的云服务如 AWS 实施攻击的人更难。我继续尝试多种提供商，最终找到网络IP地址未被列入黑名单的一些服务提供商。
之后我尝试从不同的 IP 地址发送多个POST 并发请求以验证该绕过。
结果成了！现在我只要通过受信任的电话号码就能更改任意 Apple ID 的密码。
当然攻击执行并不容易，我们必须设置正确才能成功利用该漏洞。首先，需要绕过短信6位代码以及邮件地址中收到的6位数代码。这两种绕过均基于同样的方法和环境，因此在尝试第二次绕过时我们并不需要改变任何内容。即使用户启用了双因素认证机制，但我们仍然可以访问他们的账户，因为2FA 端点也共享速率限制并易受攻击。这个漏洞还存在于密码验证端点中。
2020年7月1日，我将该漏洞连同详细的复现步骤以及绕过视频验证告知苹果安全团队，后者证实漏洞存在并在收到报告的几分钟内进行诊断。
漫长等待
之后我没有从苹果收到任何反馈，因此继续更近状态更新。2020年9月9日，他们表示正在推出修复方案。
而在未来5个月内还是没有任何反馈。
他们表示计划在下次安全更新中修复该漏洞。我在思考是什么阻止他们对严重漏洞的响应如此之慢。
于是我开始重新测试漏洞，检查是否已修复，而不是被动等待。2021年4月1日，我测试后发现该漏洞补丁已发布到生产环境中但苹果仍然没有进行任何更新。我要求他们说明漏洞是否已修复，答复还是一样：没有更新状态提供。
我耐着性子等待他们更新状态。1个月之后，我给他们发邮件询问为何漏洞已在4月1日修复但并未告知我，并指出我想要发布博客文章说明该漏洞。
意外接踵而至
苹果安全团队表示能否在发布前先和他们分享。而这也是事情出现意外的时候。
分享文章后，苹果公司否认了我的观点，指出该漏洞无法用于接管大部分 iCloud 账户。他们的回复如下：
从邮件截图可看到，他们分析认为该漏洞仅针对未用于受通过码/密码保护的苹果设备的 iCloud 账户。
我认为即使要求提供设备通过码（4位或6位）而不是通过邮件发送的6位码，它仍然共享相同的速率限制而且易受基于竞争条件的暴力攻击。我们也将能够发现相关联苹果设备的通过码。
我还在他们关于“忘记密码”的支持页面中发现了一些变化。
以上截图展示的是页面当前的情况而不是提交漏洞报告时的样子。
2020年10月，该页面如下：
截图中标黄部分“在某些情况下 (in some cases)”在2020年10月添加到段落开头，恰好是他们在2020年9月告诉我正在推出补丁之后。
一切好像都是准备好的，更新页面声称仅有数量有限的用户易受攻击。多年来该页面并未更新，在我提交漏洞报告后才做出些微更新。这似乎并非巧合。
当我询问此事时，苹果安全团队表示更新是因为 iOS 14 的变化导致的。我又问使用受信任邮件/电话号码重置密码和iOS 14 又有什么关系？如果真是这样，那么 iOS 14 之前，重置密码时使用了受信任电话号码和邮件吗？如果使用了，那么我的漏洞报告就适用于所有苹果账户。但我并未收到任何答复。
我很失望并表示，会在不通过他们许可的情况下披露所有的漏洞详情。于是，我收到了回复。
他们和苹果团队的工程师安排了电话会议，解释他们在分析中发现的问题并解释我的问题。
在会议过程中，我问到这个漏洞为何不是我发现的那个。他们指出该通过码并未发送至任何服务器端点而且已在设备本身验证。我指出在不联系苹果服务器的情况下，随机苹果设备无法了解另外一台设备的通过码。他们指出数据确实发送给了服务器但是通过加密操作验证的，另外他们表示出于安全考虑无法透露更多信息。
我询问如果我们通过逆向工程找到加密过程并复制，通过并发请求暴力攻击苹果服务器会怎么样？他们并没有给出明确的答复。他们给出的结论是，暴力攻击通过码的唯一方法是通过暴力破解苹果设备，但由于本地系统速率的限制不可能做到。
从逻辑上讲我无法接受苹果工程师的说法，将通过码数据发送给服务器的同时复制苹果设备所做事情应该是有可能的。
我打算亲自验证。如果他们说的是真的，那么通过码验证应该易受基于条件竞争的暴力攻击。经过几小时的测试后我发现他们对通过码验证端点设置了 SSL 固定，因此发送到服务器的流量无法由 MITM 代理如 burp/charles 读取。
得益于 checkra1n 和 SSL Kill Switch，通过他们的工具我绕过了固定并读取到发送到服务器的流量。
我发现苹果使用了 SRP (Secure Remote Password) 或 PAKE 协议验证用户已经知道正确的通过码而不会真的将其发送到服务器。因此工程师说的是对的，他们并不会将通过码直接发送到服务器。实际情况是，服务器和客户端都会用之前已知的数据做一些数学计算来推算密钥（更像 diffie-hellman 密钥交换）。
在此不会说明 SRP 详情，直接说明在我们上下文中所需的必要知识。
苹果服务器具有两个存储值，即在设置或更新通过码时为每个用户创建的校验器和 salt
当用户以用户名和临时值 A 初始化 SRP 认证时，苹果服务器会以具体用户和临时值B响应
客户端使用源自服务器的 salt 来计算 SRP-6a 指定的密钥
服务器使用 salt 和校验器计算由 SRP-6a 指定的密钥
最后它们互相证明所推算的密钥是一样的。
由于拥有用户指定的 salt 和校验器，因此 SRP 能够阻止暴力攻击，因此即使有人窃取了数据库，但仍然需要为每名用户执行 CPU 密集型暴力攻击以发现密码。这样受影响厂商就足以进行应对。
但在我们的案例中，我们不必暴力破解大量账户。暴力攻击单个用户就足以入侵其 iCloud 账户并找到通过码。
只有当你同时拥有特定于目标用户的 salt 和校验器时，暴力攻击才是有可能的。绕过短信通过码后，我们能够轻松伪造成目标用户并获取 salt。但问题在于校验器。我们应该通过某种方式从服务器获得该校验器或者绕过针对密钥验证端点的速率限制。
如果速率遭绕过，我们就可继续尝试通过通过码的预先计算的值获取不同的组合，直至找到匹配的密钥。显然，需要很多计算才能推算出每个4位或6位数字通过码的密钥（从0000/000000 到 9999/999999）。
当我们在重置密码过程中在 iPhone/iPad 中输入通过码时，设备通过发送成功的短信认证获取到的用户会话令牌，初始化 SRP 认证。服务器以各个用户的 salt 进行响应。通过码和 salt 被哈希，之后推算出发送至 https://p50-escrowproxy.icloud.com/escrowproxy/api/recover 的最终密钥，检查是否匹配服务器上计算的密钥。
用于验证密钥的 POST 请求如下：
字符串标记拥有上述提到的所有数据，但以 DATA BLOB 格式发送。在解码 BLOB 的值之前，我想要检查的是速率限制。我并发了30次请求以检查端点是否易遭攻击。
令人惊讶的是，它并不易受攻击。在30次请求中，29次被以内部服务器错误拒绝。
速率限制将在苹果服务器本身或 HSM（硬件安全模块）中执行。不管哪种方式，速率限制逻辑应当进行规划以阻止条件竞争。在我提交漏洞报告之前，该端点不受竞争条件影响的可能性较低，因为我测试的其它所有端点均易受攻击——短信代码验证、邮件代码验证、双因素认证、密码验证均易受攻击。
如果他们不是在我发送漏洞报告后修复的，则漏洞要比我原来想象得更严重。通过暴力破解该通过码，我们将通过区别这些响应来识别正确的通过码。因此我们不仅能接管任何 iCloud 账户，而且还能发现与其相关联的苹果设备的通过码。即使攻击较复杂，但如果我的假设正确的话，该漏洞能够hack 任何具有4位/6位数字通过码的 iPhone/iPad。
由于目前正在验证这些并发请求，因此我无法验证自己的观点，而我能够证实的唯一方式是写信给苹果公司，但后者并未给出任何回应。
难以接受的奖金
2021年6月4日，我收到了苹果公司的漏洞奖励邮件。
苹果网站上指出 iCloud 账户接管漏洞的实际奖金是10万美元。从被锁苹果设备中提取敏感数据的奖励是25万美元。我的漏洞报告同时说明了两种场景（假设通过码端点在我发送报告后得到修复），因此实际的奖金应该是35万美元。即使他们决定只奖励其中更高的情况，那应该是25万美元。
将这类漏洞卖给政府部门或私有漏洞奖励计划 Zerodium 应该能得到更高的奖励。但我选择了以道德方式处理，我也并未奢求能得到高于苹果规定的奖金额。
但1.8万美元的奖金实在差太远了。假设我的所有假设都是错误的，苹果通过码验证端点在我提交漏洞报告之前不易受攻击。即使这样，从该漏洞造成的影响来看（如下），奖励金额也不公平。
绕过双因素认证。这就像由于绕过的原因，双因素认证不存在一样。依赖于 2FA 的人均易受攻击。它本身就是一个重大漏洞。
绕过密码验证速率限制。使用常见/弱/被黑密码的苹果 ID 账户均易受攻击，即使它们启用了双因素认证也如此。一旦被黑，攻击者能够远程追踪设备位置并擦除设备。2014年名人的 iCloud 账户被黑基本是因为弱密码的原因。
绕过短信验证。如果我们知道与 iCloud 密码相关联的通过码或密码，比如朋友或亲戚知道设备通过码，那么利用这个漏洞他们就能接管你的 iCloud 账户并远程擦除整个设备，而无需物理访问。
由于绕过短信和邮件验证，我们能够接管所有未与受通过码保护的苹果设备的 Apple ID，这意味着：
不具有通过码或密码的任意苹果设备，就像关闭或并未设置通过码/密码的任何人
任意未通过苹果设备创建的 Apple ID，如在浏览器或任意安卓 app 中创建以及并未用于受密码保护的苹果设备
例如，5000多万名安卓用户下载了苹果音乐 app。其中多数可能并未使用苹果设备。他们仍然是苹果用户，而他们的信息如信用卡、账单地址、订阅详情等均可遭暴露。
苹果无需奖励 iCloud 账户接管漏洞的最高奖金（10万美元），但应该至少给出与影响匹配的奖金。
毕竟我的辛苦工作以及近一年的等待，结果换来的却是不公平的判断。因此，我拒绝接受奖金，告知他们这是不公平的。我请他们重新考虑奖金决定或允许我发布具有所有信息的报告。我未收到任何回复。因此我决定不再无限期地等待他们的回复，发布文章。
因此，我免费而不是以不公平的代价和苹果分享了自己的研究成果。
我请苹果安全团队至少在未来能够更加透明和公平。感谢苹果修复该漏洞。
重申一遍，漏洞已完全修复，上述场景不再有效。感谢阅读，欢迎交流。
推荐阅读
看我如何从 icloud.com 中发现存储型 XSS并获$5000奖金
研究员再次发现 Instagram 账户接管漏洞并获得1万美元赏金
原文链接
https://thezerohack.com/apple-vulnerability-bug-bounty
题图：Pixabay License
本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的
产品线。
觉得不错，就点个 “在看” 或 "赞” 吧~
351
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
