影响某些 Akamai 服务的 SAML 实施漏洞
这篇博客文章概述了在 Akamai Enterprise Application Access (EAA) 产品中发现的一个漏洞，该漏洞已得到修补。在与使用安全断言标记语言版本 2（SAMLv2，本文中称为“SAML”）来对用户进行身份验证的应用程序进行交互时，该漏洞可能允许攻击者冒充授权用户。
在接到第三方的初始通知后，Akamai 的工程师发现该漏洞位于 Lasso中，Lasso 是一个实施 SAML v2.0 身份验证协议的第三方开源库。当客户向第三方身份提供商 (IdP) 配置 SAML 身份验证时，Akamai EAA 使用 Lasso 库来验证应用程序的 SAML 断言。对 Lasso 库的进一步调查表明，该漏洞对其他依赖 Lasso 的软件具有更广泛的影响。
从 2021 年 3 月 4 日开始，一套全面的修复方案已经部署到 EAA 网络中。EAA 连接器设备或 EAA 客户端不需要更新。Akamai 已经确定，SOGo 和 PacketFence 软件包（由 Inverse 维护，该公司最近已被 Akamai 收购）在使用 SAML 进行身份验证的部署中也依赖于 Lasso。SOGo 软件包也受另一个独立但相关的漏洞影响，该漏洞的 ID 为 CVE-2021-33054。如需了解对 SOGo 和 PacketFence 造成的影响，请访问此处。我们已经确认，由 Akamai 提供的其他所有面向外部的应用程序（包括 Akamai Control Center）都不会受此攻击媒介影响。
该 Lasso 漏洞已被分配了 CVE ID CVE-2021-28091。由于该漏洞的严重性，Akamai 敦促所有为应用程序使用 EAA 第三方 SAML 身份验证功能的客户审查他们的系统，以查找内部攻击者过去可能开展的冒充攻击。Akamai 还敦促所有使用 Lasso 库（或依赖 Lasso 的软件）的用户审查他们的公告并尽快完成修补，同时审查他们的应用程序是否存在模拟访问的情况。Lasso 2.7.0 中提供了修复方案。要查看关于如何对可能受影响的系统进行调查的建议，请参见下面的“需要采取的行动”一节。
该漏洞的详细信息记录在一篇配套技术博文中，该文章介绍了深入的技术细节，以及该漏洞的发现、分类、修补和通知过程。
作为修复方案的一部分，Akamai 针对签名错误的 SAML 响应添加了日志记录。在本文发布时，EAA 平台上记录的所有签名错误的 SAML 响应案例都不是入侵的迹象，而是与正在设置的配置（在这些配置中，预计会出现故障）和测试（用于验证漏洞已修复）有关。
漏洞的简要说明
当把 SAML 响应提供给 SAML 服务提供商 (SP) 且该提供商在 SAML 响应正文的末尾附加了一个额外的、没有签名的断言时，该漏洞就会被触发。当某个角色在 SAML 响应文档的末尾注入另一个用户的断言（没有签名，但在其他方面格式良好）时，则可能实现这种操作。
如果角色有权访问企业的格式良好的 SAML 响应，则此漏洞有可能允许此类角色（通常是经过身份验证的用户，但也有可能是遭到入侵的端点或恶意代理）修改他们的身份并冒充同一企业内的另一个用户。SAML 响应或它的个别断言可能具有签名，但攻击者插入的 SAML 响应部分不需要具有签名，就可以让攻击取得成功。为了利用此问题发起攻击，攻击者需要拥有身份提供商 (IdP) 的有效凭据，或者已经获得了相应的凭据，可以通过身份验证并取得有效用户身份。我们将潜在的影响分为四种 - 实现冒充网络访问（包括未经身份验证的访问和经过身份验证的访问）、冒充应用程序访问以及面向依赖 Lasso 库的应用程序的替代 Lasso 依赖组件 - 如下所述。
漏洞的影响
以下三个影响类别适用于 Akamai EAA：
在 EAA 配置中，如果使用 SAML 来与 Akamai 进行身份验证（以决定对于特定应用程序的访问权限），未经授权的用户可能会通过网络访问应用程序，包括绕过应用程序访问控制列表 (ACL) 或其他访问控制措施。从功能上来看，这相当于冒充者能够访问局域网上的目标系统，本报告将这种访问称为“冒充网络访问”。冒充网络访问带来的风险取决于访问的应用程序的类型：
(1) 没有身份验证的应用程序：相关风险与后面这类应用程序相同 - 最终用户因处于同一局域网内而拥有该应用程序的完全访问权限。
(2) 具有身份验证的应用程序：由于应用程序实施了自己的身份验证，此类应用程序的风险在本质上较低。
对于将凭据扩展到应用程序本身的 EAA 配置，通过使用面向应用程序的身份验证机制（比如 Kerberos 限制性委托、标头身份验证或 OpenID Connect），应用程序会话用户可以冒充其他用户，这在本报告中被称为 (3)“冒充应用程序访问”。
对于上述类别的应用程序，只有那些使用 SAML 与第三方 IdP（向 Akamai 提供断言）进行通信的应用程序才存在漏洞。使用其他身份验证机制（比如 OpenID Connect (OIDC) 或 OAuth）与第三方 IDP 进行通信的 EAA 应用程序没有使用 Lasso 中存在漏洞的内容。此外，使用 Akamai IDP 功能的应用程序配置也不容易受此漏洞影响。有关该库中的漏洞的更多详细信息将在我们的配套博文中讨论。
对我们的软件执行的审查表明，自 2014 年第一季度发布的 1.0 版本以来，EAA 服务中一直存在此漏洞。调查人员应假设，从客户配置中添加第三方 SAML 支持开始，到 2021 年 3 月 5 日 EAA 网络的修补完成，该漏洞一直存在。
最后一类风险适用于使用 Lasso 库的实体。大多数依靠 Lasso 库进行 SAML 身份验证的应用程序可能会受此用户冒充漏洞影响。在本报告中，这被称为 (4)“替代 Lasso 依赖组件”。
识别、修补和披露时间表
2021 年 2 月 23 日星期二晚上，Akamai 收到了 Best Buy 企业信息保护团队的一名工程师发来的关于此问题的通知。收到通知后不久，Akamai 的信息安全团队审查了报告，并启动了我们的事件管理流程。在处理过程中 - 从事件开始，到 2021 年 2 月 27 日 (UTC) 提早发出客户修补通知 - Akamai 工程师再现了报告中的问题，实施了修复方案，并开始调查客户影响。Akamai 在凌晨 1 点 (UTC) 后不久发布了关于补丁的客户通知 - 在我们将修复方案移交给我们的 QA 团队后大约一小时。随后，我们的 QA 团队开始验证修复方案，并确保新版本在执行计划部署前具备稳定性。部署于 3 月 2 日开始，于 3 月 4 日完成。
在响应流程的调查和修复阶段，我们确定我们平台上的漏洞与 Lasso 库有关。对 Lasso 库的进一步调查表明，该漏洞对其他依赖 Lasso 的软件可能具有更广泛的影响。在努力修补我们网络上的漏洞的同时，Akamai 工程师和 Akamai 信息安全团队开始了相关披露流程，以便负责任地向库的维护者和其他经过验证的 Lasso 用户披露此问题。
为了限制对该库的其他用户造成的影响，Akamai 只会将与该漏洞有关的信息分发给参与修补和协调漏洞披露的人员。我们采用的限制措施符合行业标准的负责任披露流程，旨在减少攻击者进一步利用该漏洞的可能性。
从我们全面部署补丁到发布本报告，在此期间，Akamai 与 Lasso 维护者、Lasso 的下游使用者以及 CERT/CC 合作，以便安全和及时地向尽可能多的受影响方修补漏洞并协调披露该问题。
需要采取的行动
鉴于上述影响，我们建议根据上面列出的影响类别采取以下行动。
对于当前或以前的客户（包括当前或以前部署了试用解决方案的客户），如果在任何时候使用了第三方 SAML IdP 来与 EAA 进行身份验证，则应根据影响类别采取以下行动：
没有身份验证的应用程序的冒充网络访问：如果用户冒充了不需要身份验证的系统的另一个用户，则这些用户可能已经成为了攻击目标，这些攻击尝试泄露或修改数据、系统进程或应用程序功能。在应对这些应用程序时，应视作攻击者可以访问有效的用户凭据，并且该攻击者可以直接通过局域网访问相关应用程序。如果在 EAA 门户中为应用程序设置了组限制或任何其他用户限制控制措施，应审查这些限制，并考虑违反该控制措施的用户可能能够采取什么行动，或通过该控制措施可实现哪些安全目标。
具有身份验证的应用程序的冒充网络访问：与之前的类别非常相似，这种方法允许一个用户在网络连接级别冒充另一个用户，但由于应用程序在 EAA 系统之外实施了自己的访问控制和授权，这些应用程序需要的审查可能更少。除非应用程序自身的身份验证和授权系统存在额外的漏洞或弱点，否则，直接网络访问本身并不意味着一个用户可以冒充另一个用户。应该考虑这些应用程序是否可能归类为具有替代 Lasso 依赖组件（如下所述）。
冒充应用程序访问：由于本报告中说明的漏洞的性质，此类别的应用程序应该受到更仔细的审查。此类别可能分为两种形式。
面向应用程序的身份验证机制将把经过错误验证、冒充的用户身份转发给源站应用程序，使得攻击者可以在目标应用程序中采取任何行动，仿佛他们就是被他们冒充的用户。这适用于没有实施自己的身份验证系统、而是依靠 EAA 平台提供的身份断言的 Web 应用程序。
RDP 应用程序的远程桌面协议 (RDP) 自动登录功能，它依赖管理员提供的凭据来访问源站 RDP 服务器。当用户对 RDP 应用程序的访问受到组成员资格限制时，一个用户可能会冒充授权组中的另一个用户，利用提供的凭据来访问 RDP 服务，仿佛他们就是被他们冒充的用户。
源站系统的管理员应密切检查这些系统，以排除任何可能被攻击者安装的意外软件或配置，包括恶意软件、rootkit 或内核扩展。管理员还应该考虑这些应用程序是否允许某人在其常规授权之外执行额外的访问。对于持续的、长期的会话，管理员应该考虑终止所有在 2021 年 3 月 5 日之前启动的此类长期连接。此外，对于管理用户帐户、访问控制列表、授权令牌、安全基础架构或任何其他敏感/高价值系统的应用程序，管理员应特别注意审查和验证是否存在任何意外变更。
对于任何使用 Lasso 库的软件的开发人员、维护者或管理员而言，考虑到上面列出的替代 Lasso 依赖组件类别，Akamai 建议您尽快升级到 2.7.0 版 Lasso。与上述类别一样，系统管理员应审查最终用户的行为，以了解异常使用模式，因为冒充企图不太可能被记录到日志中。对于依赖 Lasso 的软件包，如果该软件包具有一个既定的分发渠道，则应监测修补通知。更新后的 Debian、Ubuntu 和 RedHat 软件包预计将在本文发布后数小时内发布，当然，也有可能是在本报告发布之前发布。
说明攻击者如何利用漏洞的示例
没有身份验证的应用程序的冒充网络访问
使用 EAA 访问没有身份验证的应用程序时，EAA 充当的是身份验证方和授权方（以提供这些应用程序的访问权限），而不是代理接收任何身份验证信息。如果一个环境利用 EAA 来允许或拒绝对没有身份验证的应用程序的访问，这些内部应用程序将无法知道访问它们的用户是冒充的。
在这种情况下，管理员需要考虑允许无权访问应用程序的用户连接到该应用程序所产生的影响。例如，如果应用程序只处理公共信息，则影响会很小，但是，如果应用程序处理敏感数据或受管制的数据，则影响可能会很大。
此外，应用程序的管理员需要分析他们的应用程序级日志，以了解可能表明帐户遭到冒充的活动。日志分析可能会显示不符合一般正常使用模式的用户活动的示例，比如在不寻常的时间访问应用程序或访问应用程序中用户通常不会访问的数据或进程。
具有身份验证的应用程序的冒充网络访问
使用 EAA 访问自行提供身份验证的应用程序时，与没有身份验证的应用程序相比，此漏洞可能给该应用程序造成的风险更低。即使成功冒充了 EAA 会话，也不会影响应用程序执行的身份验证。
日志分析可能会显示这样的示例：有人通过 EAA 完成了身份验证，并获得了一个用户身份，而在应用程序中则通过身份验证获得了另一个用户身份。此分析将为管理员提供提示，表明是否有人试图利用该漏洞来执行未经授权的访问。
此类应用程序的管理员应审查应用程序本身执行的身份验证是否使用了 Lasso（因此也有可能属于“替代 Lasso 依赖组件”类别）。
冒充应用程序访问
当 EAA 将用于 EAA 会话的身份传递给应用程序时，应用程序会假定该身份已被验证。如果应用程序会话是用冒充用户创建的，应用程序会把冒充用户视为真实用户。在这种情况下，把身份信息转发给您的应用程序时，如果使用 Kerberos 限制性委托、标头身份验证或 OpenID Connect (OIDC)，就可能出现成功的冒充。
对于 RDP 应用程序自动登录功能，冒充另一个用户的攻击者将能够访问 RDP 服务，仿佛他们就是被他们冒充的用户，使用管理员提供的凭据来连接到源站服务。虽然管理员提供的凭据不会暴露给攻击者，但会向他们授予系统的访问权限，系统会将攻击者错认成他们冒充的用户。
与其他情形一样，日志分析可以帮助管理员根据活动的时间和性质，找到行为异常的会话。
替代 Lasso 依赖组件
除了 EAA 对 Lasso 的依赖之外，任何使用 Lasso 的应用程序都可能受此漏洞影响。开发人员应审查他们的代码库，以了解他们的应用程序是否使用了 Lasso 库，如果已使用，他们应尽快更新该库或减轻它的影响。如果您需要使用将 Lasso 作为依赖组件的应用程序，建议监控该应用程序的更新，使得管理员能够尽快进行修补。该漏洞已在 Lasso 2.7.0 版本中修复。
日志记录和取证
如上文介绍影响的章节所述，需要采取的行动范围相当广泛，这取决于多种因素：
此漏洞的潜在暴露窗口期至少可以追溯到 2016 年，也许更早。
在删除或取代配置后，EAA 平台只在随后的 90 天内对配置进行存档。因此，对于 90 天以前停用的配置，Akamai 无法确定 EAA 应用程序配置是否符合漏洞条件。
EAA 中的身份验证组件没有足够的日志记录来检测此漏洞是否遭到利用。在我们测试该漏洞的过程中，Akamai 多次尝试探索可用的日志记录信息，以确定是否可以识别对于该漏洞的利用，但记录的信息无法确认或排除攻击者对于该漏洞的潜在利用。为了限制最终用户身份验证令牌的潜在暴露，以及保护客户身份验证令牌的秘密和隐私，Akamai 也不会记录我们验证的 SAML 断言。
作为对该修复方案的回应，EAA 平台添加了新的日志记录，以检测异常的身份验证尝试（代表了应用补丁后此攻击在 EAA 上的表现形式）。在本文发布时，发生的所有欺诈性身份验证尝试都可归咎于如下原因：部署后的回归测试、报告方验证问题是否已解决、第三方 IdP 证书过期和 IdP 配置不正确。
鸣谢
在此向以下各方表示感谢：
Best Buy - 感谢他们的企业信息保护团队和 Sam Tinklenberg 向我们报告了 EAA 中的用户冒充漏洞。
Lasso 库的维护者 Entr'ouvert - 感谢他们在修补和披露该漏洞方面提供的帮助以及他们对该库的持续维护。
CERT/CC - 感谢他们帮助我们披露了这两个漏洞，同时也感谢我们联系的机构对此问题做出的快速应对。
其他信息
如有更多疑问，建议您查看我们的配套文章，如果 EAA 客户具有其他疑问，请联系 Akamai 技术支持。
