SSO中的身份账户不一致漏洞

 

由于其良好的可用性和安全性，单点登录 (SSO) 已被广泛用于在线身份验证。但是，它也引入了单点故障，因为所有服务提供商都完全信任由 SSO 身份提供商创建的用户的身份。在本文中调查了身份帐户不一致威胁，这是一种新的 SSO 漏洞，可导致在线帐户遭到入侵。该漏洞的存在是因为当前的 SSO 系统高度依赖用户的电子邮件地址来绑定具有真实身份的帐户，而忽略了电子邮件地址可能被其他用户重复使用的事实在 SSO 身份验证下，这种不一致允许控制重复使用的电子邮件地址的攻击者在不知道任何凭据（如密码）的情况下接管关联的在线帐户。具体来说，首先对多个云电子邮件提供商的帐户管理策略进行了测量研究，展示了获取以前使用过的电子邮件帐户的可行性。进一步对 100 个使用 Google 商业电子邮件服务和自己的域地址的流行网站进行了系统研究，并证明大多数在线帐户都可以通过利用这种不一致漏洞而受到损害。为了阐明电子邮件在野外重复使用，分析了导致广泛存在的潜在电子邮件地址冲突的常用命名约定，并对美国大学的帐户政策进行了案例研究。最后，为终端用户、服务提供商和身份提供商提出了一些有用的做法，以防止这种身份帐户不一致的威胁。

 

0x01 Introduction

在过去的十年中，单点登录 (SSO) 因其良好的可用性和安全保证而被广泛使用，以减少密码疲劳和访问第三方网站的安全风险。许多电子邮件提供商和社交媒体服务，包括 Google、Microsoft 和 Facebook，都提供了免费的 Web SSO 解决方案。 SSO 的最初设计是允许用户使用联合身份进行跨域身份验证。许多工作都集中在联合身份及其管理系统的安全增强上，当今大多数在线服务提供商 (SP) 将帐户身份验证过程完全外包给可靠且受信任的身份提供商 (IdP) 。通常，一旦 IdP 端的身份验证成功，终端用户就可以访问关联的在线帐户，而无需进行额外的安全检查。

由于 SSO 作为用户身份和在线帐户之间的单一桥梁，它也不可避免地在整个身份验证过程中引入了单点故障。 SSO 中存在的漏洞可能允许攻击者破坏服务提供商的用户帐户，因此它一直是攻击者的一个有吸引力的目标。大量研究工作致力于自动披露漏洞并解决整个 SSO 身份验证系统中的逻辑缺陷。

在本文中提出了一个新的 SSO 漏洞，即身份帐户不一致威胁，它可能导致服务提供商的帐户承诺。现有的 SSO 系统严重依赖用户的电子邮件地址来绑定真实身份的帐户，许多服务提供商采用电子邮件地址作为主要的帐户标识。特别是，IdP 通常会为 SP 提供唯一的 ID，以通过检查用户帐户中的相应信息来验证用户身份。如果 ID 不匹配，SP 会默认匹配的电子邮件地址可以验证用户的身份，从而授予访问权限。但是，在很多场景下，邮件地址实际上可能被其他用户重复使用，导致用户的账号和身份不一致。鉴于现有的 SSO 身份验证系统，这种不一致可能进一步允许控制重复使用的电子邮件地址的攻击者接管服务提供商的相关帐户。

与传统的密码恢复攻击不同，SSO 身份验证不需要攻击者破解或恢复受害者的密码。一旦攻击者获得回收的电子邮件地址，IdP 就会将攻击者视为该电子邮件地址的唯一合法用户和所有者。问题在于 SP 不知道这种情况（即电子邮件地址被另一个用户重复使用）。因此，攻击者可以合法地使用 IdP 提供的 SSO 服务来劫持 SP（属于受害者）上的帐户，而无需知道任何凭据。结果，所有现有的针对密码恢复攻击的防御机制，例如双因素身份验证和附加知识，都变得徒劳无功。

为了全面了解普遍存在的身份帐户不一致威胁，对 100 个使用 Google 企业电子邮件服务并使用自己的域地址的热门网站进行了系统研究。考虑了可能发生不一致的三种不同场景，并观察到 100 个网站中有 80 个容易受到不一致威胁的影响，这意味着重复使用的电子邮件地址可以在不知道密码的情况下轻松破坏这些帐户。

为了证明电子邮件重用的可能性和可行性，调查了多个云电子邮件提供商的帐户管理策略，包括公共帐户和企业帐户。研究涵盖了美国三大电子邮件供应商，共占据了 85% 的市场份额和拥有超过 8 亿活跃用户的中国顶级电子邮件供应商之一。发现一旦电子邮件地址被放弃，大多数电子邮件提供商都允许重新注册电子邮件地址。还分析了几种广泛采用的电子邮件命名约定，以进一步了解电子邮件地址重用的可能性。根据纽约州大都会运输管理局 (MTA) 的员工历史，表明电子邮件命名冲突确实具有相对较高的发生概率。进一步对随机选择的 50 所美国大学进行了案例研究，观察到其中 32 所允许学生修改其电子邮件地址，其中 24 所在毕业后删除学生电子邮件帐户，这可能会导致电子邮件地址的重复使用。

最后提出了几种有用的做法来减轻身份帐户不一致的威胁。 SP 和 IdP 都应采取必要的机制来防止在线帐户因用户身份和帐户信息不一致而受到损害。 同时建议终端用户应该意识到电子邮件地址重用的存在，并比以前更加谨慎地使用 SSO 身份验证。

 

0x02 Background

A.单点登录系统概述

部署 SSO 身份验证的主要目的是允许使用联合用户身份登录各种在线服务。例如，谷歌允许用户使用单个 Gmail 帐户访问其相关服务。大学还使用横幅系统，使学生和员工能够以单一身份访问管理系统和在线资源。由于集中的用户身份识别和身份验证系统可以进一步提高帐户安全性，许多知名的身份管理服务鼓励用户将身份验证请求重定向到他们的服务器。虽然 SSO 被许多应用程序广泛使用，但在这项工作中，主要关注网站/应用程序登录框架（即 Web SSO）。

SSO 身份验证通常使用授权代码流，它涉及跨三个主要方的令牌访问和 URL 重定向：终端用户、服务提供商和身份提供商。终端用户是尝试登录在线服务或帐户的个人。 SP 是为终端用户提供服务的网站。 IdP 是负责向 SP 提供身份验证服务的身份管理系统。通常，终端用户首先向 SP 提交登录请求。然后，SP 重定向终端用户以访问 IdP 身份验证 URL。用户输入 IdP 账户凭证后，授权 IdP 服务器通过多个 SSO 令牌将用户身份和相应的属性下发给 SP。然后，SP 开始识别与接收到的用户身份和属性相关联的帐户。一旦识别出匹配的帐户，终端用户将被授予登录该帐户的权限。否则，SP 开始引导终端用户建立新帐户。

B.账户与身份

SSO 使终端用户能够使用他们的身份对在线帐户进行身份验证。特别是，身份是一种特殊类型的帐户，由 IdP 服务器管理和维护。在 SSO 中，用户身份用作 SP 中用户帐户的身份验证因素。

帐户是指在 SP 中持有的数字实体，用于为每个终端用户区分服务。终端用户需要为其帐户建立至少一个唯一标识符。传统上，此标识符是用户定义的，称为用户名或帐户 ID。自从基于电子邮件的识别和授权（EBIA）的提出以来，SP 开始采用电子邮件地址来代替传统的用户名。由于严格执行电子邮件地址的唯一性，因此可以确保每个帐户都收到一个唯一标识符。

身份是指由 IdP 管理的特定类型的帐户。在 SSO 中，它用于 SP 作为另一个帐户标识符。用户身份由 IdP 以 SSO 令牌的形式发布，身份中封装的信息应保密。身份首先包含几个用户属性作为有关终端用户的补充信息。流行的用户属性包括电子邮件地址（在“email”字段中）、用户的全名和首选用户名。 IdP 负责控制与 SP 共享的此类信息。此外，SSO 规范要求为每个身份分配一个唯一编号或一组字符（称为 UserID），这些字符存储在“sub”字段中。唯一的 UserID 是在终端用户在 IdP 中注册身份时创建的，并且只能分配给一个用户身份（即永远不会被回收）。

C.身份管理系统

在 SSO 中，身份管理系统 (IMS) 为使用单个用户身份的在线帐户提供通用身份验证方案。 IMS 集成了 IdP 服务来管理多个终端用户的身份。

电子邮件提供商：自 EBIA 提出以来，SP 开始认可电子邮件地址作为帐户的用户名。然后，电子邮件提供商不仅将其服务扩展为消息传输代理，还扩展为用户身份的 IMS。许多电子邮件提供商免费提供公共帐户，拥有注册帐户的终端用户可以同时接收电子邮件和身份服务。公共电子邮件帐户由电子邮件提供商管理，终端用户的管理和定制能力有限。

企业管理员还可以在许多电子邮件提供商处注册付费企业帐户。他们可以在一个域名中添加任意数量的电子邮件地址。企业帐户中的每个电子邮件地址代表组织中的一个用户，每个用户还会收到一个数字身份以及电子邮件地址。电子邮件提供商授予管理员更灵活的管理能力。管理员可以为组织的用户（例如，员工）设置电子邮件命名约定，以便在整个组织中统一电子邮件地址的格式。一些电子邮件提供商还允许用户在其主要电子邮件地址之上创建别名。这为用户提供了在不更改主地址的情况下获取另一个电子邮件地址的机会。别名和主电子邮件地址共享同一个电子邮件收件箱，外发电子邮件可以带有别名地址或主地址作为发件人。

身份和访问管理 (IAM) 系统：许多大型企业进一步投资于 IAM 以管理员工及其数字身份。 IAM 允许 IT 部门建立更复杂和灵活的管理策略。它还可以实现具有明确定义的管理流程的自动管理程序。此外，IAM 包括 IdP 服务，为员工提供访问许多内部资源的 SSO 功能。

IAM 的一个典型例子是许多大学采用的banner系统。学生、教职员工在成为附属成员时会被分配一个身份（通常称为 NetID）。凭借他们的数字身份，他们可以访问内部资源。除了 NetID，学生和员工还会收到教育电子邮件地址（通常以 .edu 结尾）。如果大学将其电子邮件服务外包给也提供 SSO 服务作为 IdP 的外部电子邮件提供商，则每个人都会收到电子邮件提供商分配的额外数字用户身份。

 

0x03 Vulnerability Overview

SSO 要求 SP 和 IdP 都遵循特定的实施规范，以便为终端用户提供安全的身份验证服务。 IdP 负责确保身份所有者获得独占访问权限，并向 SP 提供唯一的 UserID 和其他用户属性。 SP 应仅使用提供的身份识别关联帐户。只要 SP 确保每个身份都与特定帐户相关联，帐户识别过程就应该相当简单。

然而，即使 SSO 要求为 SP 和 IdP 指定了详细的身份验证流程和安全规范，实际实施和系统配置也可能与原始设计有所不同。特别是，当用户的部分信息更新时，可能会存在不一致。在本节中首先介绍威胁模型，然后介绍用户身份和帐户之间的不一致，这会产生潜在的漏洞并可能导致严重的安全后果。

A.威胁模型

由于大多数 SP 已广泛采用电子邮件地址来标识其在线服务的帐户，因此假设用户也使用其电子邮件地址在 SP 上注册帐户。此类电子邮件地址可能属于电子邮件提供商（例如 Gmail 和 Hotmail）中的公共电子邮件帐户，也可能属于用户所在组织在其自己的域中付费的企业帐户（例如 Google G Suite）。组织可以进一步使用 IAM 系统进行电子邮件和身份管理。电子邮件提供商提供电子邮件和身份服务，以便用户可以使用 SSO 对 SP 提供的帐户进行身份验证。 SP 上的帐户可以直接在 SP 上注册，也可以通过 SSO 注册。

在这两种情况下（即公共电子邮件和企业电子邮件），当用户以前拥有的电子邮件地址现在属于另一个用户时，电子邮件地址可能会重复使用。后文会详细分析了这种重用的可能性和可行性。对于公共电子邮件，电子邮件提供商可能会删除或回收未使用的电子邮件帐户，这些帐户以后可能会被其他用户注册。对于企业邮箱，由于企业经常在员工离职后删除相应的邮箱账号，所以这种情况发生的频率更高

电子邮件地址重用可能偶然发生： (1) 新用户仅根据电子邮件命名约定注册电子邮件地址。例如，它使用名字和姓氏的首字母作为邮箱的用户名（即@符号之前的部分）。 (2) 用户因离婚、结婚等特殊原因修改邮箱，可能会更改邮箱中的姓氏。 (3) 很多大学等机构允许用户自行设置别名邮箱地址，增加了邮箱地址复用的可能性。虽然别名电子邮件不能用于身份，但可用于在 SP 上注册帐户。别名更改后，过期地址可能会被其他用户重新用作主要电子邮件地址。

电子邮件地址的重用也可能是有意发生的：攻击者将他们的帐户注册或重命名为受害者留下的一个过期的电子邮件地址，以破坏 SP 上的相关帐户。例如，恶意员工或学生可能有动机恢复属于他们的同事或同学的过期电子邮件地址。攻击者还可以重用从公开可用的数据库泄漏中删除的电子邮件（即 Use-After FreeMail 问题）。

除了从受害者那里获得重复使用的电子邮件地址之外，威胁模型不要求攻击者具有特殊的技术技能。为了进一步验证与重复使用的电子邮件关联的在线帐户（在 SP 上），攻击者可以主动检查目标 SP，以检查是否存在与重复使用的电子邮件地址相关联的在线帐户，或者他们可以定期检查收件箱中是否有来自目标 SP 的任何已发送电子邮件。攻击者还可以利用现有工具提供列出与电子邮件地址关联的所有帐户的服务。例如，如果攻击者获得了由 Google 或 Microsoft 托管的重复使用的电子邮件地址，他们可以通过 Deseat.me轻松获得与重复使用的电子邮件地址相关联的帐户列表。一旦假设生效，攻击者就可以开始通过 SSO 对相关的在线帐户（属于受害者）进行身份验证。

与密码恢复攻击的区别：通过简单地重置或恢复帐户密码，重复使用的电子邮件地址可以直接用于劫持在线帐户 。虽然已经提出了许多有效的机制来防御密码恢复攻击，例如两因素身份验证和附加知识，但这些防御措施对于对抗身份帐户不一致威胁是无效的。通过 SSO 认证，攻击者不需要破解或恢复密码。攻击者可以合法地使用 IdP 提供的 SSO 服务来劫持 SP（属于受害者）上的帐户，而无需知道任何凭据。原因是一旦攻击者获得回收的电子邮件地址，IdP 就会将攻击者视为电子邮件地址的唯一合法用户和所有者，而这种情况（即电子邮件地址被另一个用户重复使用）对 SP 来说是未知的。根本原因是现有单点登录系统中的身份和账号不一致，具体如下。

B.不一致性

大多数 SP 采用电子邮件地址作为主要帐户标识符和用于 SSO 身份验证的可选用户 ID。当用户注册一个新的在线帐户时，SP 会将这两种信息的组合作为标识符存储在其数据库中。如下图所示，可能发生两种情况： (1) 用户 Alice 直接在 SP 网站上注册帐户。在这种情况下，由于不涉及SSO，SP无法访问UserID的信息。因此，SP 使用用户提供的有效电子邮件地址（例如 alice@example.com ）以及空的 UserID（如下图中的帐户 A）存储新帐户。 (2) 用户Bob第一次通过SSO注册账号，访问SP。然后，记录提供的身份中的用户 ID 和电子邮件地址（例如 bob@example.com ）（如下图中的帐户 B）。

另一方面，对于身份信息，UserID是IdP在建立身份时分配的一个不可回收的、唯一的编号（或一组字符）。当用户请求对在线帐户进行 SSO 身份验证时，它始终包含一个有效值（如上图中的 ID 令牌 1 的情况）。但是，根据 IdP 端实施的帐户管理策略，允许修改甚至重复使用电子邮件地址。特别是，如果用户更改了电子邮件地址，IdP 会更新电子邮件信息但保留相同的原始用户 ID（如上图中的 ID 令牌 2 的情况）。但是，如果电子邮件地址被删除，然后被另一个用户重新使用，IdP 会为该用户分配一个新的唯一用户 ID，用于新建立的身份（如上图中的 ID 令牌 3 的情况）。

当用户请求对在线帐户进行 SSO 身份验证时，就会出现不一致，因为电子邮件地址更改仅在 IdP 服务器内部发生，而 SP 并不知道该修改。 SP 搜索其帐户数据库以根据包含用户 ID 和来自 IdP 的电子邮件地址的用户身份查找具有匹配信息的特定帐户。一般而言，鉴于用户 ID 和电子邮件地址均匹配，SP 可以安全地允许访问已识别的帐户，而不会产生任何安全问题。但是，对于部分匹配（用户 ID 或电子邮件地址），根据系统配置，SP 可能会将访问权限授予错误的用户。

上图说明了四种可能的身份-帐户关系。情况❶代表一个正常情况，Bob 尝试通过 SSO 使用与 SSO 令牌中相同的“sub”（即用户 ID）和“email”字段作为他的在线帐户登录。在这种情况下，用户身份和在线帐户都保持一致。在情况❷，Bob 首先更改他在 IdP 中的电子邮件地址，并尝试使用他的新电子邮件地址登录。 SSO 令牌和在线帐户共享相同的“sub”但不同的“email”。在情况❸的情况下，Bob 碰巧将他的电子邮件地址更改为 Alice 的电子邮件地址。由于 Alice 在没有 SSO 的情况下注册了她的帐户，因此她的在线帐户持有与 SSO 令牌相同的“email”，但“sub”为空。相反，SSO 令牌包含有效但未知的用户 ID。另一种情况是 Alice 使用电子邮件别名 (alice@example.com ) 在 SP 上注册她的帐户。一旦 Bob 获得这个电子邮件地址作为他的主要电子邮件地址，就会出现不一致的情况。最后，在情况❹中，SSO 令牌和在线帐户具有相同的“email”但不同的“sub”。当 Bob 在 IdP 中删除他的电子邮件地址，而另一个用户获得此电子邮件地址（例如 bob@example.com ）并在 IdP 中再次使用它时，就会发生这种情况。

身份账户不一致发生在情况❷❸❹。在第❷情况下，虽然存在不一致，但它只影响身份所有者，因为 UserID 不能重新分配给其他人。但是，在❸和❹情况下，由于不一致，无法保证用户身份的所有者与帐户所有者相同。因此，在这两种情况下授予访问权限都会导致潜在的帐户泄露。接下来详细介绍现有的 SSO 系统如何处理这种不一致。

C.账户识别流程及问题

为了了解现有 SSO 系统中的帐户识别和身份帐户不一致的处理，描述了 OpenID Connect (OIDC) 模块的工作流程，这是一个支持 Drupal 平台的流行开源模块用于处理来自多个流行 IdP（包括 Facebook、Google 和 LinkedIn）的用户身份的表单。请注意，不同的系统在处理不一致时可能有不同的实现。

上图显示了帐户识别方法的详细过程。当 SP 从受信任的 IdP 收到用户身份时，SP 会尝试识别与给定身份相关联的现有帐户。如果不存在此类帐户，SP 将开始为用户身份创建新帐户的过程。此过程包括三个主要步骤：

第一步：第一步是识别与给定用户身份相关联的现有帐户。它首先检查用户 ID（存储在“sub”字段中）以搜索匹配的帐户。一旦识别出匹配的帐户（情况 ❶ 和 ❷），系统就会执行配置检查，以确定是否允许使用匹配的 UserID 更新用户属性。如果允许，SP 会修改存储在用户帐户中的信息并修改过时的信息以与用户身份保持一致。例如，在情况❷中，帐户数据库中的电子邮件地址可能会根据 SSO 令牌中的身份信息进行更新。最后，用户认证成功，无论用户信息是否可以更新，都允许用户访问匹配的帐户。

第二步：如果没有找到与给定用户 ID 匹配的帐户，系统会再次搜索“email”字段上的潜在匹配项。但是，由于 UserID 上没有匹配的帐户，因此任何具有匹配电子邮件地址的现有帐户都应包含空（情况❸）或不同的“sub”字段（情况❹）。根据系统配置，用户可能被授予或拒绝访问所识别的帐户。如果被授予，系统会在系统配置允许的情况下对用户属性执行另一次更新。如果拒绝，则用户身份验证失败，并且网站上会显示一条错误消息。

第三步：如果在步骤2 或步骤3 中都没有找到帐户，则系统开始建立新帐户的程序。系统使用用户身份中提供的“sub”和“email”创建一个新帐户。如果身份未提供，系统还会要求用户输入其他帐户信息。

处理不一致：虽然上面的帐户匹配程序乍一看似乎合乎逻辑，但更深入的分析表明，它可能会暴露帐户入侵攻击的漏洞。特别是，它忽略了电子邮件可能被不同的终端用户重复使用的事实。因此，作为用户属性元素的电子邮件地址无法充分代表终端用户的身份。授予对具有匹配“email”的帐户的访问权限可能最终会导致错误的用户甚至试图破坏受害者帐户的攻击者。此外，SP在进行用户信息更新时，也可能会覆盖匹配账户的“sub”字段。从 SSO 认证的角度来看，这个过程表明匹配的帐户正式更改其关联的用户身份。

安全与不安全：对于不一致的情况❷，OIDC 授予用户访问权限，因为用户身份中的 UserID 与帐户中的“sub”字段保持相同。其他一些系统会引导用户创建新帐户。在这两种情况下，它可能会给用户带来不便，但不会导致帐户泄露。因此，将情况❷视为安全策略。然而，对于情况❸和❹，如果电子邮件地址被另一个用户重复使用，这个不同的用户可以访问受害者的在线帐户。上图中的骷髅标记表示情况❸和❹都是不安全的实现。

SAML：安全断言标记语言 (SAML) 是一种广泛使用的开放标准，被 Google 等许多 IdP 采用，允许 IdP 将授权凭据传递给 SP。还调查了 Drupal 平台中的开源 SAML 实现。 SAML 协议允许将电子邮件地址用作有效的用户 ID。因此，诸如 Google 之类的 IdP 使用用户的主要电子邮件地址作为其默认用户 ID。这消除了情况❶和❷，但仍然留下了不一致的情况❸和❹，它们都是不安全的策略。

 

0x04 Feasibility of Email Reuse in IdP

由于 IdP 管理的每个身份都会收到一个唯一且不可重复使用的 UserID，因此身份帐户不一致的主要原因是用户属性的修改，尤其是用户的电子邮件地址。为了调查包含相同电子邮件地址的两个不同用户身份的可行性，检查了电子邮件提供商和 IAM 采用的帐户管理策略。

A.作为 IdP 的电子邮件提供商

大多数电子邮件提供商为两大客户群提供服务：一般公众和商业企业。这两个群体的账户管理策略有显着差异：公共账户主要由电子邮件提供商管理，但业务管理员拥有更多管理其业务账户的能力。在研究中，为公共和企业帐户选择了四个具有内置 SSO 功能的流行电子邮件提供商来研究他们的帐户管理政策。具体来说，Gmail、Hotmail 和 Yahoo!占美国电子邮件市场的 85%，QQ 邮箱在中国支持超过 8 亿活跃用户。结果列于下表中。

电子邮件创建：这四家公共电子邮件提供商都提供免费的电子邮件帐户服务，并且它们在用户身份和电子邮件地址之间采用一对一的关系。系统在注册新邮箱时生成用户身份，删除邮箱时删除对应的用户身份。注册电子邮件帐户时，Gmail、Hotmail 和 Yahoo!允许用户定义他们的首选电子邮件地址，只要这些地址不被其他人使用或违反他们的命名要求。相比之下，QQ为每个账号分配了一个唯一的号码，这个号码本身就是邮箱地址的用户名。

另一方面，企业账户获得更大的灵活性。通常，帐户管理员可以将任何电子邮件地址分配给其域中的用户帐户。一些电子邮件提供商还实施内置命名约定以简化帐户注册过程。与公共帐户相比，企业帐户还允许管理员暂时禁用用户帐户。如果电子邮件被禁用，用户将无法接收更多服务，但身份信息仍保留在数据库中。

更改电子邮件地址：终端用户请求修改他们的电子邮件地址是很常见的。例如，当人们更改他们的法定姓名时，他们更愿意在他们的电子邮件地址上反映这种变化。对于公共帐户，四个电子邮件提供商都不允许直接修改用户帐户上的电子邮件地址。唯一的方法是创建新的电子邮件帐户。但是，对于企业帐户，修改电子邮件地址是一个相当简单直接的过程。账户管理员可直接在用户设置页面修改邮箱地址，更改瞬间发生。

删除电子邮件地址：删除电子邮件帐户有两种可能的情况：由用户/管理员删除或由系统删除。大多数公共帐户提供商（实验中的 QQ 除外）都允许终端用户删除他们的帐户。 Gmail 和 Yahoo! 等提供商在删除之前进一步采用一个小的试用期，以防用户想要恢复它们。热邮件会立即删除电子邮件帐户以及所有相应的用户数据。由于不活动，公共电子邮件帐户也可能被提供商删除。 Hotmail、Yahoo!、QQ在其网站上都明确表示，他们会在一段时间内定期清理不活跃的帐户，被删除的电子邮件地址可以被其他人重新获取。

对于企业帐户，管理员全权负责删除任何未使用或冗余的帐户。由于企业为其域下的每个现有电子邮件地址付费，因此无论其状态如何（活动或禁用），电子邮件提供商都会维护帐户。至于试用期，只有微软365有30天恢复政策；其他电子邮件提供商会立即删除该帐户。

重复使用电子邮件地址：创建电子邮件和修改地址的过程还涉及重复使用以前拥有的电子邮件地址。研究表明 Hotmail 和 Yahoo!允许其他用户重新注册相同的电子邮件地址。虽然 QQ 分配了一个帐号作为电子邮件地址，但如果之前的帐号被删除，则仍然可以使用相同的号码。相比之下，Gmail 禁止重复使用公共电子邮件地址。对于企业帐户，电子邮件地址一旦被删除，就可以立即重新分配。值得注意的是，四个电子邮件提供商都没有提醒管理员该电子邮件地址以前曾被使用过。

总体而言，公共帐户和企业帐户采用的帐户管理策略可能会导致身份帐户不一致。终端用户和业务管理员都不知道其他人以前是否使用过某个电子邮件地址。因此，一旦多个人在电子邮件地址上共享相同的偏好，并且允许重复使用电子邮件地址，则终端用户完全有可能拥有以前为他人所有的电子邮件地址。尽管电子邮件系统可以为该用户确保新的身份和邮箱，但公共 SP 并不知道电子邮件地址重复使用导致的用户身份变化。同样，更改用户电子邮件地址的权限也可能导致问题：管理员可能会将以前使用的电子邮件地址分配给另一个用户，该用户可以进一步利用身份帐户不一致来控制受害者的在线帐户。

此外，某些策略可能会增加身份帐户不一致的发生率。例如，定期删除电子邮件帐户会污染用户可用的电子邮件地址池。由于每个企业帐户都需要支付基于用户的月度订阅费（每个用户 1 美元到 25 美元不等，包括残疾用户），因此这种计费方法会激励帐户管理员删除未使用的电子邮件帐户以降低成本。另一个关键因素是命名约定。系统的默认命名约定为一个业务域下的所有电子邮件地址建议了一种通用格式。因此，如果用户共享相同的属性（例如名字或姓氏），他们可能会争夺相同的电子邮件地址。

B.IAM

为了研究管理灵活性和能力，手动调查了五个开源 IAM 系统（即 OpenIAM、Keycloak、Gluu、Soffid 和 feKara），其中包括一个专门为教育机构设计的系统（即 feKara）。一般来说，IAM系统对账户管理策略没有任何限制，允许业务管理员根据自己的需求进行全面定制。具有基本用户信息和属性（例如，全名、职位和隶属关系）的身份最初是从 HR 系统或准入系统创建的。 IAM 根据账户创建策略生成用户身份，在内部资源上建立新账户。例如，IAM 系统在预定义的内部或外部电子邮件提供商上为用户注册一个电子邮件地址。电子邮件地址是根据管理员预定义的命名约定生成的。

首先以管理帐户的身份运行，以测试有关电子邮件重用的相关功能。例如删除一个现有帐户，然后立即尝试使用完全相同的电子邮件地址创建一个新帐户。还观察到管理员可以配置系统，允许个人用户修改他们的信息，包括电子邮件地址。因此，从用户的角度进一步测试电子邮件重用。总体而言，所有五个 IAM 系统都允许重复使用帐户（包括电子邮件地址），而无需通知以前曾使用过该电子邮件地址。与电子邮件提供商在删除电子邮件后可能采用较短的试用期不同，这五个 IAM 系统中的所有操作都会立即生效。如果启用，用户还可以将他们的电子邮件地址更改为任何可用地址。

 

0x05 Account Compromise In the Wild

为了进一步调查利用帐户身份不一致漏洞危害在线帐户的可能性，对 Alexa 前 1000 名网站中随机选择的 100 个流行 SP 进行了系统研究。首先使用自己的域名在 Google G Suite 上建立了一个企业电子邮件服务，这能够添加、修改和删除用户身份，而没有任何帐户管理限制。同时自己的域名从未被其他组织注册过，确保没有任何 SP 托管与测试电子邮件地址相关联的帐户。然后，使用具有自己域中的电子邮件地址的身份来测试不一致情况❷❸❹。

上图说明了整个过程。由于每个网站都包含其独特的用户帐户注册和 SSO 身份验证机制，因此在实验中，手动批量调查选定的 SP。首先测试情况❸，并使用相关账户进一步测试其他用例。在 Google G Suite 提供的企业电子邮件服务中创建了一个用户身份 Alice，电子邮件地址为 alice@example.com 。此步骤为 Alice 创建一个唯一的 UserID（例如，“sub”字段中的“111.222.333”）。然后，使用电子邮件地址通过 Web 界面（即没有 SSO）在目标 SP 上注册一个新帐户。通过 Web 界面注册将建立一个用户 ID 为空的帐户。但是，目标 SP 中的帐户和 IdP 中的身份共享相同的电子邮件地址。最后，尝试使用 IdP 中的身份 SSO 登录到目标 SP。如果登录成功，进一步检查目标 SP 是否根据 SSO 登录的身份更新存储的帐户信息。特别是登录A账户查看账户设置中的SSO配置。如果谷歌账户信息作为授权认证方式出现，认为“sub”字段更新成功。

进一步测试情况❷。在 IdP 端，将身份的电子邮件地址修改为 bob@example.com。用户 ID 保持不变（即仍为“111-222-333”）。在 SP 端，如果帐户信息在上一步中更新，则帐户应具有相同的 UserID，但电子邮件地址为 bob@example.com。否则，手动将SP中的帐户与身份绑定以更新相关信息。然后检查 SP 是否允许使用相同的用户 ID 但不同的电子邮件地址进行 SSO 登录。同样，如果成功，会检查帐户信息是否更新（通过检查电子邮件地址）。

最后，测试不一致的情况❹。删除 IdP 端的身份（即用户 ID 为“111-222-333”的身份），并注册另一个重复使用相同电子邮件地址的身份（即 bob@example.com）。这会生成具有新用户 ID（例如“999-888-777”）的另一个身份，但所有其他信息都与前一个相同。在 SP 方面，类似于测试情况❷，使帐户具有相同的电子邮件地址，但具有不同的用户 ID。通过 SSO 向同一个 SP 进行身份验证，并检查是否允许登录以及是否更新了任何用户信息。值得注意的是，这种情况可能会修改 SP 端的 UserID。如果 UserID 被修改，则很危险，因为该帐户现在属于新身份。如果没有，情况可能会更糟，因为两个身份可能能够 SSO 登录到同一个帐户。进一步进行实验以验证更新。

结果：如果 SP 允许 SSO 登录情况❸❹，他们很容易受到身份帐户不一致的威胁。否则，认为它们不是脆弱的，因为情况❶❷不会危及帐户。下表总结了结果。 100 个 SP 中只有 20 个能够从不一致威胁中幸存下来（列为策略类型 3、4 和 7）。 100 个 SP 中有 79 个容易受到情况❸的攻击，这意味着它们允许具有相同电子邮件地址的任何身份通过 SSO 登录到一个用户 ID 为空的帐户。一旦登录成功，所有这些 SP 都会更新空的 UserID 并将帐户绑定到身份。 52个SP允许SSO登录情况❹：即使使用不同的UserID，具有相同电子邮件地址的身份也可以SSO登录SP的帐户，这显然不符合SSO设计规范。此外，它们都没有更新 UserID 字段。

对于情况❷，30 个 SP 拒绝使用匹配的用户 ID 但不同的电子邮件地址的 SSO 登录访问。具体来说，SP 可能 (1) 只显示错误页面；或 (2) 要求用户用之前的账号登录，进一步修改 SSO 配置； (3) 引导用户注册新账号。这不符合 SSO 规范，会给在 IdP 中更改电子邮件地址的用户带来不便。对于其余 70 个允许使用匹配的 UserID 但使用不同的电子邮件地址进行 SSO 登录的 SP，其中只有 3 个更新了电子邮件地址信息。它可能会导致其他问题。例如，新用户重新使用已删除的电子邮件地址可能能够直接从 SP 恢复密码。

结果还揭示了由身份帐户不一致威胁引起的另一个安全问题：两个不同的用户身份竞争一个在线帐户。它存在于 SP 允许 SSO 登录两种情况❷和❹但不更新相关帐户信息时。在这种情况下，如上图所示，匹配UserID（即“sub”）或电子邮件地址的身份可以成功进行 SSO 登录。总的来说，发现 100 个 SP 中有 41 个（上表中的类型 1）受到影响。进一步对所有这 41 个 SP 进行了实验，并确认两个身份都可以 SSO 登录到该帐户。总而言之，观察到超过一半的流行 SP 容易受到威胁，这些威胁可能被利用来拥有重复使用的电子邮件，然后通过 SSO 身份验证破坏受害者的帐户。

道德披露：对 SP 的实验没有强加任何道德问题，因为实验是在一个受控环境中进行的，其中所有用户帐户都是由自己建立的。以正常和合法用户的身份使用 SP 提供的服务。然而，结果确实揭示了许多 SP 可能容易受到身份帐户不一致威胁的影响。此外，大部分实验都是手动进行的，除了选择的 SP 的批量调查。无意在实验中开发任何自动工具，因为攻击者可能会从这些工具中受益，以更高效和有效的方式探索身份帐户的不一致。

这种不一致很容易被具有原始技术技能的攻击者利用。因此，出于道德考虑，向受此威胁影响的 SP 披露了本研究发现。收到了他们承认存在漏洞的积极反馈，其中一些人正在积极致力于实施适当的解决方案。

 

0x06 Possibility of Email Address Reuse

在本节中调查了公众采用的流行命名约定，以揭示为什么用户会重复使用电子邮件地址。还提供了一个关于帐户管理政策的案例研究，包括许多美国大学采用的电子邮件命名约定。

a.电子邮件命名约定

命名约定是人们选择电子邮件地址的主要指南。 命名约定的设计应该考虑四个关键方面：可用性、安全性、管理和审计。特别是，可用性是终端用户最关心的问题。

基于名称的约定是实现出色可用性的流行电子邮件格式之一。一个典型的基于姓名的约定包括用户的姓名首字母、全名和几位任意或连续数字（如有必要）。许多网站发布了各种电子邮件命名约定，为公众和企业选择首选的电子邮件地址格式提供指导。根据这些报告，总结了最推荐的电子邮件命名约定（请注意，使用 {} 以获得更好的视觉效果）如下：

• {Firstname}@ example.com

• {Firstinitial}{Lastname}@ example.com

• {Firstname}.{Lastname}@ example.com

• {Firstinitial}.{Lastname}@ example.com

大型企业或组织通常对其员工和附属成员采用一致的命名约定，从而实现全自动管理系统。对 2012 年财富 1000 强企业名单中的 971 家企业认可的电子邮件约定数据库进行了分析，结果如下图所示。请注意，有些公司可能会采用多种命名约定。结果表明，前五个基于姓名的电子邮件约定占总格式的 89.6%。前两个最流行的命名约定，{Firstname}{Lastname} 和 {Firstname}.{Lastname}，被 661 个组织采用，占公司总数的 68.1%。

B.邮箱地址冲突

鉴于人口众多且命名约定很少，企业内的不同员工很可能会争夺同一个电子邮件地址。为了估计组织/企业级电子邮件地址冲突的概率，从纽约州大都会交通局 (MTA) 公布的员工工资记录中调查了其员工历史。该记录提供了2012年至2018年的员工名单。下表给出了该记录的统计信息，包括员工总数和每年退休或聘用的员工人数。例如，2018年，MTA拥有80147名员工（对于许多大型企业来说是合理的规模），公司退休4579人，招聘5329人。雇用/退休信息能够推断电子邮件地址重复使用的可能性。

假设 MTA 使用最推荐的电子邮件命名约定，如上所述。首先测量多个员工收到相同地址的概率，然后在下图中展示了 2018 年在不同命名约定下的可能性（其他年份的结果相似，差异小于 2%）。不出所料，{Firstname} 约定的概率最高：惊人的 31% 的分配电子邮件会与 87% 的员工发生冲突。例如，有 2,256 名员工的名字与 Michael 相同。对于 {Firstinitial}{Lastname} 情况，大约 18% 的电子邮件地址会发生冲突，影响 45% 的员工。即使对于 {Firstname}{Lastname} 同时使用 firstname 和 lastname 的情况，仍然很有可能发生电子邮件地址冲突：6% 的分配电子邮件地址会发生冲突，影响 12% 的员工。结果表明，鉴于当前的电子邮件命名约定，大型企业中的电子邮件地址冲突是不可避免的。

接下来调查由于退休/雇用程序而重复使用电子邮件地址的可能性。假设一个电子邮件地址在员工退休时被释放，然后可以在以后重新签名给新聘用的员工。 2013 年，有 4,592 名员工从 MTA 退休，这可能导致案例 {Firstname} 的 1,341 个电子邮件地址、案例 {Firstinitial}{Lastname} 的 4,301 个以及案例 {Firstname} {Lastname} 的 4,556 个电子邮件地址的释放。从 2014 年到 2018 年，每年有超过 5,000 名员工加入 MTA。然后研究了 2013 年发布的电子邮件地址被 2014 年到 2018 年新招聘的员工重复使用的概率。下图说明了结果。可以看到，在 2018 年底，48.14%、57.71% 和 65.77% 的电子邮件地址可能已被重新分配给案例 {Firstname}{Lastname}、{Firstinitial}{Lastname} 和 {Firstname }， 分别。即使对于涉及 {Firstname} 和 {Last name} 冲突可能性最小的命名约定，4,556 个电子邮件地址中的 2,193 个也可以在六年内重复使用。这些结果清楚地表明，在企业中重复使用电子邮件的可能性很大，而那些退休员工容易受到身份帐户不一致的威胁。

C.案例研究

进一步对美国大学学生的账户管理政策进行了案例研究，因为大多数大学都在线发布了他们的政策。随机选择了 50 所大学，包括公立/私立和国家/地区大学，学生人数从数千到数万不等。

上表总结了调查。在 50 所大学中，三所机构拥有自己的电子邮件服务器（列为 N/A）。由于没有关于他们的电子邮件服务器是否提供 IdP 服务的进一步信息，将这些机构排除在结果分析之外。其他大学使用 Google G Suite 或 Microsoft 365 作为他们的电子邮件提供商。观察到许多机构采用类似的做法，因此将它们分为不同的类型。

在其余 47 所大学中，其中 32 所（类型 1、2、3）允许学生通过更改 NetID 来更改电子邮件地址。尽管大多数大学强烈反对学生在没有明确理由的情况下修改电子邮件地址，但学生仍可能出于各种原因选择这样做，例如因结婚或离婚而更改法定姓名。因此，对于这些大学，学生可以重复使用其他人的电子邮件地址。特别是，其中 11 所（类型 2）在毕业后立即删除学生的电子邮件帐户，其中 2所（类型 6）保留他们的电子邮件帐户，除非帐户变为非活动状态。它进一步增加了电子邮件地址重复使用的可能性，因为那些以前使用过的电子邮件地址可供新入学的学生使用。由大学电子邮件提供商生成的学生身份包含一个不同的用户 ID 和一个回收的电子邮件地址。此外，八所大学（类型 3）允许用户在没有特定命名约定的情况下选择自己的电子邮件地址。这样的政策为学生提供了有意获得重复使用的电子邮件地址的机会。

还发现一些大学（类型 6）支持别名电子邮件地址。虽然他们不删除电子邮件帐户并且不允许更改电子邮件地址，但别名电子邮件使身份帐户不一致成为可能，因为学生可能使用别名电子邮件在 SP 中注册帐户。只有 13 所大学（类型 4、5）是安全的，因为它们既不允许学生修改他们的电子邮件地址，也不支持别名电子邮件，即使他们的学生毕业后，他们的电子邮件帐户仍然有效。

还检查了它们的命名约定。对于未明确提及该政策的大学，将格式列为“系统分配”。这些大学中的大多数都采用基于姓名的约定来为学生分配电子邮件地址。这一结果表明，基于美国大学现有的电子邮件账户管理政策，确实会出现身份账户不一致的情况。

 

0x07 Mitigation

为了减轻身份帐户不一致的威胁，本文提出了几种防御措施。这些方法旨在减少身份账户不一致的发生，并防止用户在出现不一致时泄露受害者的账户。

身份帐户不一致本身很复杂，涉及 IdP 和 SP。完全解决它可能需要在通常来自不同企业的 IdP 和 SP 之间进行协调。此外，SSO 身份验证和电子邮件管理系统没有通用的实现。因此，这里介绍的防御实践是原始的和初步的。受影响 SP 的管理/技术团队应执行最适合其系统架构和业务需求的适当防御策略/机制。

措施1：终端用户应仅使用长期身份来建立在线帐户。长期身份包括终端用户自己拥有的 IdP 帐户，并且应该在很长一段时间内保持使用，最好是终生使用。这可确保与其在线帐户相关联的身份不会过期并重新分配给其他人。终端用户可以避免使用组织的电子邮件地址在 SP 上注册在线帐户。他们还应特别注意帐户管理政策，以避免使用临时身份建立帐户。

措施2：当一个身份被安排删除时，终端用户应删除所有关联的帐户并删除在身份删除日期之前存储的所有私人数据。尽管在 SSO 中实施了许多高级安全功能，但身份帐户不一致的威胁可能会在用户不知情的情况下继续存在。一旦他们的帐户被盗用，他们的个人信息和私人数据就会暴露出来。用户应特别注意那些可能导致其身份被修改或删除的事件，并清除其私人数据并手动终止所有关联帐户。

由于 SP 负责识别与提供的身份相关联的帐户，因此帐户识别过程中的任何逻辑缺陷都可能引入潜在的漏洞。因此，确保用户对特定帐户的身份验证可以有效减少攻击者破坏在线帐户的攻击面。

措施3：当终端用户获得对具有匹配用户 ID 的帐户的访问权限时，SP 应更新用户属性，尤其是电子邮件地址。电子邮件地址被视为身份中用户属性的一个字段。 SP 还应反映用户帐户上用户属性的修改。因此，用户身份中修改后的电子邮件地址应该能够覆盖用户帐户中现有的主要帐户标识符。如果其他用户重新获取过时的电子邮件地址，这也可以防止潜在的密码恢复攻击。

IdP 负责为公共和企业帐户实施安全的管理策略基线。这个基线应该是公开可用的，以便 SP 系统有一个安全和健壮的实施。

措施4：IdP 不应允许重复使用电子邮件地址。身份帐户不一致威胁的主要原因之一是电子邮件地址的重新分配。减轻这种威胁的一种简单直接的方法是防止 IdP 中的任何不同身份接收相同的电子邮件地址。这种做法将增加电子邮件帐户的命名熵，同时可以通过允许更灵活的电子邮件命名约定来平衡可用性。

 

0x08 Conclusion

在本文中介绍了 SSO 系统中由电子邮件地址重用引起的身份帐户不一致威胁。证明通过重复使用电子邮件地址，攻击者可以在多种情况下通过 SSO 身份验证破坏受害者的在线帐户。首先通过研究帐户管理策略展示了终端用户获取以前使用过的电子邮件帐户的可行性被身份提供者采用。然后探索了 100 个流行服务提供商的潜在威胁，结果表明，大多数在线帐户都可以通过利用身份帐户不一致漏洞而受到损害。为了进一步证明电子邮件地址重用在现实生活中的可能性很高，基于几种常用的电子邮件命名约定分析了电子邮件地址冲突的概率。还对美国机构进行了案例研究，表明威胁确实存在。最后提出了有用的措施以减轻身份帐户不一致的威胁。