扩展认证保护 | MSRC博客

安全研究与防御

作者：swiat | 2009年12月08日 | 6分钟阅读

本月，微软发布了多个非安全更新，实现了认证扩展保护(Extended Protection for Authentication)机制，以增强Windows平台上的认证凭据安全性。这些更新虽非安全公告，但允许使用Windows HTTP服务的Web客户端、IIS Web服务器及基于HTTP协议栈(http.sys)的应用程序启用此功能（该功能最初于2009年8月发布）。发布后，开发人员和管理员仍需手动配置功能。更多信息请参阅安全公告973811。

认证扩展保护在使用集成Windows认证(Integrated Windows Authentication)时有助于保护认证凭据。具体而言，它能防止攻击者通过其他攻击手段（如通过社会工程学诱导客户端连接）获取这些凭据后，利用它们登录客户端有权访问的其他服务器。

这类攻击并非新出现，但在特定部署场景中可能构成风险。因此，本月我们还发布了安全公告974926，详细记录了这些攻击的工作原理，以及微软为帮助管理员防范攻击所采取的多项措施。这些措施包括我们与行业合作伙伴过去发布的各种更新，以及强化认证凭据的扩展保护功能。

本文旨在阐明这一新功能的实际作用，以及管理员如何开始使用它。

为什么需要认证扩展保护？

微软发布扩展保护是为了让应用程序在使用集成Windows认证(IWA)时更好地保护客户端和服务器之间传输的认证凭据。IWA允许客户端向服务器认证，而无需将用户密码暴露给任何潜在窃听者，通常通过NTLM或Kerberos认证协议实现。

在某些部署场景中，使用IWA时可能存在一种称为凭据中继(credential relaying)的攻击类型。如果攻击者成功诱导客户端连接到自身，攻击者可以利用认证机制，使用这些凭据向客户端拥有相同账户的第三方服务器进行认证。此外，攻击者甚至可以向客户端本身运行的服务进行认证。但攻击者无法获取用户密码。

认证扩展保护的作用是什么？

认证扩展保护旨在防止这类凭据中继攻击。它通过基于RFC 5056“使用通道绑定保护通道”实现的协议来实现。

EPA使客户端认证能够与外部安全通道绑定，从而确保客户端认证仅在同一外部通道的保护下发生。举例来说，假设客户端想要向网站认证。这里可以建立一个外部TLS通道。EPA以这样一种方式连接到该通道：除非外部TLS已成功建立，否则客户端认证不会发生。

为了理解这如何帮助阻止凭据中继攻击，我们来看一个例子。假设攻击者成功冒充服务器，并诱导客户端连接到自身。客户端会认为他正在连接到“webmail.contoso.com”。攻击者会获取凭据，建立与客户端拥有相同账户的另一台服务器（例如“fileserver.contoso.com”）的连接，然后向该服务器进行认证。

此时，如果服务器启用了认证扩展保护，它将验证认证请求是否真正意图发送给自己（实际上不是）。此外，如果存在TLS通道，它将验证凭据是否通过同一TLS通道传输。由于客户端与攻击者建立了TLS连接，而攻击者随后与“fileserver.contoso.com”建立了新的连接，这将不匹配，服务器将拒绝认证尝试。

如何部署认证扩展保护？

认证扩展保护的部署必须在客户端和服务器上同时进行，对于任何给定应用程序都是如此。如果只有一方支持该功能，连接将无法受益于额外的保护。

下面，我们将简要举例说明如何为涉及Internet Explorer和Internet Information Services (IIS) Web服务器的场景配置扩展保护。

以下前提条件适用：

• 在客户端上，必须安装KB968389，该更新在安全支持提供程序接口(SSPI)中启用扩展保护功能。该功能在Windows 7和Windows Server 2008 R2机器上自动存在；
• 在客户端上，必须安装Internet Explorer累积更新MS09-054，以使Internet Explorer能够使用该功能；
• 在服务器上，必须安装KB970430和KB973917，这些更新将功能部署到HTTP.sys和IIS Web服务器。

管理员现在必须启用这些更新提供的功能：

• 在客户端上，启用扩展保护是一个机器范围的设置。它将适用于所有选择加入保护机制并使用SSPI进行认证的应用程序。在Windows 7和Windows Server 2008 R2机器上，该功能默认启用。在旧平台上，安装KB968389后，必须通过将注册表项HKLM\System\CurrentControlSet\Control\LSA\SuppressExtendedProtection的值设置为0来启用扩展保护。此外，管理员应验证HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel项是否设置为3。这意味着客户端将仅使用NTLMv2认证，并在服务器支持时使用NTLMv2会话安全。这一点很重要，因为Windows认证的扩展保护仅保护NTLMv2和Kerberos认证，而不保护NTLMv1。

• 在服务器上，启用该功能是按应用程序设置的。为了保护IIS Web服务器，还必须启用扩展保护。配置说明因IIS版本而异，更详细的配置信息可在KB973917中找到。在Internet Information Services 7.5上，按照以下指南在IIS中启用认证扩展保护：

  1. 在任务栏上，单击“开始”，指向“管理工具”，然后单击“Internet Information Services (IIS)管理器”。

  2. 在“连接”窗格中，展开服务器名称，展开“站点”，然后展开要为其启用Windows认证扩展保护的站点、应用程序或Web服务。

  3. 在“主页”窗格中滚动到“安全”部分，然后双击“认证”。

  4. 在“认证”窗格中，选择“Windows认证”。

  5. 在“操作”窗格中单击“启用”。

  6. 在“操作”窗格中单击“高级设置”。

  7. 当“高级设置”对话框出现时，在“扩展保护”下拉菜单中选择以下选项之一： a. 选择“接受”将允许终止于IIS服务器的连接在客户端已配置支持扩展保护时受益于该功能。未启用该功能的客户端仍将被允许连接，但不会受益于额外保护。 b. 选择“要求”将要求客户端使用扩展保护。如果客户端不支持，任何使用IWA对IIS的认证尝试都将失败。

  单击“确定”关闭“高级设置”对话框。

如果用户启用了认证扩展保护，并尝试连接到不支持该功能的服务器，该认证尝试仍将成功。

我的应用程序可以支持扩展保护吗？

这取决于协议。许多协议可以受到保护，但有些不能。例如，RPC不支持认证扩展保护，但也可以通过启用保密性/完整性来保护。

实现其他协议（如HTTP）的应用程序肯定可以受益于该功能。我们鼓励开发人员实现此功能。如果您的应用程序使用WinHTTP或WinINET编程接口，那么您已经间接受益于这种保护，因为这两个API的更新现已可用。开发人员可以在此处找到扩展保护的SSPI头文件。

感谢Mark Novak、Larry Zhu、Paul Leach和Paul Miller对此功能的设计和实现工作。也感谢MSRC工程团队的Andrew Roths对本文的技术反馈。

-Maarten Van Horenbeeck, MSRC项目经理 发布内容“按原样”提供，不提供任何保证，也不授予任何权利。 09年12月8日更新：更新了安全公告973811和974926的链接。 21年7月28日更新：更新了安全公告973811和974926以及MS09-054的链接。