使用 Apple 登录 - 绕过身份验证 · 第 7 区

几周前，我们发现了一个漏洞，该漏洞可用于通过滥用允许 TouchID 登录网站的新功能来未经授权访问 iCloud 帐户。

在 iOS 13 和 macOS 10.15 中，Apple 增加了在包含所需生物识别硬件的设备上使用 Safari 中的 TouchID/FaceID 登录 Apple 自己网站的可能性。

当您使用 Apple 帐户的登录表单访问任何页面时，系统会显示提示以改为使用 TouchID 进行身份验证。如果您进行身份验证，您将立即登录。这会跳过使用密码登录时通常需要执行的 2 因素身份验证步骤。这是有道理的，因为可以认为该过程已经需要两个因素：您的生物识别技术和设备。您可以取消提示以正常登录，例如，如果您想使用与手机上登录的 AppleID 不同的 AppleID。

我们预计此功能的主要用例不是登录 iCloud（因为在手机上的 Safari 中使用 icloud.com 非常罕见），但我们预计主要动机是“使用 Apple 登录” ”在网络上，此功能也适用。对于这些网站，在创建新帐户时会显示其他选项，例如是否隐藏您的电子邮件地址。

尽管所有这些都适用于 macOS 和 iOS，使用 TouchID 和 FaceID 以及所有使用 AppleID 登录的网站，我们将使用 iOS、TouchID 和来解释漏洞，但请记住，影响更广泛。

使用 OAuth2 登录 Apple 域。在，这使用该web_message模式。正常登录时，其工作原理如下：

1. https://icloud.com 嵌入一个 iframe 指向 https://idmsa.apple.com/appleauth/auth/authorize/signin?client_id=d39ba9916b7251055b22c7f910e2ea796ee65e98b2ddecea8f5dde8d9d1a815d &redirect_uri=https%3A%2F%2Fwww.icloud.com&response_mode=web_message &response_type=code.
2. 用户在 iframe 内登录（包括输入 2FA 令牌等步骤）。
3. 如果身份验证成功，iframe 会向父窗口发送一条消息，其中包含用户window.parent.postMessage(<token>, "https://icloud.com")在 JavaScript 中使用的 grant_code 。
4. 在grant_code使用由icloud.com页面以继续登录过程。

iframe URL 中的两个参数非常重要：client_id和redirect_uri。idmsa.apple.com 服务器会跟踪已注册客户端的列表以及每个客户端允许的重定向 URI。在 的情况下web_message flow，重定向 URI 不用作真正的重定向，而是用作带有授权代码（ 的第二个参数postMessage）的已发布消息的必需页面来源。

对于所有 OAuth2 模式，身份验证服务器正确验证重定向 URI 非常重要。如果它不这样做，那么用户grant_code可能会被发送到恶意网页。登录网站时，idmsa.apple.com 会正确执行该检查：将 更改redirect_uri为其他任何内容都会导致错误页面。

当用户使用 TouchID 进行身份验证时，iframe 的处理方式不同，但外部页面保持不变。当 Safari 检测到一个新页面的 URL 与上面的示例 URL 匹配时，它不会下载该页面，而是调用该过程AKAppSSOExtension。此进程与 AuthKit 守护进程 ( akd)通信以处理生物特征身份验证并检索grant_code. 如果用户成功通过身份验证，则 Safari 会向挂起的 iframe 请求注入一个假响应，该请求将消息发回，就像身份验证成功时普通页面所做的那样。akd与 gsa.apple.com 上的 API 进行通信，向该 API 发送请求的详细信息并从该 API 接收grant_code.

我们发现 gsa.apple.com API 有一个错误：即使client_id和redirect_uri包含在由 提交给它的数据中akd，它也没有检查重定向 URI 是否与客户端 ID 匹配。相反，AKAppSSOExtension在域上只应用了一个白名单。允许所有以 apple.com、icloud.com 和 icloud.com.cn 结尾的域名。这听起来可能足够安全，但请记住，apple.com 有数百个（如果不是数千个）子域。如果这些子域中的任何一个可以以某种方式被诱骗运行恶意 JavaScript，那么它们可用于触发使用 iCloud 登录的提示，client_id如果用户通过身份验证，则允许该脚本检索用户的授权代码。然后页面可以将其发送回攻击者，攻击者可以使用它来获取 icloud.com 上的会话。

这可能发生的一些例子：

• 任何子域上的跨站点脚本漏洞。这些经常被发现，列出了 2019 年至少 30 个候选者，并且只涵盖了足够重要的域进行调查。
• 一个可以被攻击者接管的悬空子域。虽然我们不知道 Apple 发生这种情况，但最近有人发现 microsoft.com 的 670 个子域可供接管： :
• 用户通过 HTTP 访问任何子域上的页面。重要的子域将具有 HSTS 标头，但许多不会。域 apple.com 未预加载 HSTS includeSubdomains。

前两个要求攻击者诱骗用户访问恶意页面。第三个要求攻击者可以访问用户的本地网络。虽然这种攻击通常更难，但它确实允许一个非常有趣的例子：captive.apple.com。当 Apple 设备连接到 wifi 网络时，它会尝试访问. 如果响应与通常的响应不匹配，则系统假定存在一个强制门户，用户需要先在其中执行某些操作。为了允许用户这样做，响应页面被打开并显示。通常，这会将用户重定向到他们需要登录、接受条款和条件、付款等的另一个页面。但是，它不需要这样做。相反，该页面可以嵌入触发 TouchID 登录的 JavaScript，这将在 apple.com 子域中被允许。如果用户通过身份验证，则恶意 JavaScript 会收到用户的grant_code.

该页面可以包含各种内容以使用户更有可能通过身份验证，例如通过使页面看起来像是 iOS 本身的一部分或“使用 Apple 登录”按钮。“使用 Apple 登录”仍然很新，因此用户可能不会注意到提示与平时略有不同。此外，许多用户在看到 TouchID 提示时可能会自动进行身份验证，因为这些提示几乎总是关于他们对手机进行身份验证，用户还应该确定是否要对打开提示的页面进行身份验证这一事实并不明显。

通过在用户希望接收强制门户的位置（例如在机场、酒店或火车站）设置虚假热点，就可以访问大量 iCloud 帐户，这将允许访问图片备份、手机位置、文件等等。正如我所提到的，这也绕过了正常的 2FA 批准 + 6 位代码步骤。

我们向 Apple 报告了这个漏洞，他们在对它进行分类的当天就修复了它。该gsa.apple.com API现在可以正确地检查了redirect_uri相匹配的client_id。因此，这可以完全在服务器端修复。

对我们来说，如何错过这个漏洞很有意义：测试这个漏洞的人可能会专注于使用不受信任的域来访问redirect_uri. 例如，有时可以使用或。但是，在这种情况下，它们都失败了，如果只尝试那些，您将错过使用恶意子域的能力。

下面的视频说明了该漏洞。