MS15-011 & MS15-014: 强化组策略
今天，我们发布MS15-011和MS15-014更新，强化组策略并解决域网络中可用于实现远程代码执行（RCE）的网络访问漏洞。MS15-014更新解决了组策略更新中的一个问题，该问题可用于禁用客户端全局SMB签名要求，绕过产品内置的现有安全功能。MS15-011增加了新功能，强化网络文件访问，以在客户端计算机上刷新组策略时阻止访问不受信任的攻击者控制共享。这两个更新是重要的改进，将有助于保护您的域网络。
风险是什么？即攻击场景是怎样的？
让我们看一个典型的攻击场景，如下所述。
这是一个“咖啡店”攻击场景的示例，攻击者试图在公共场所更改共享网络交换机，并可以将客户端流量导向攻击者控制的系统。
在此场景中，攻击者观察了交换机上的流量，发现特定机器正尝试下载位于UNC路径的文件：\\10.0.0.100\Share\Login.bat。
在攻击者机器上，设置了一个与受害者请求的文件UNC路径完全匹配的共享：\\*\Share\Login.bat。
攻击者将精心制作Login.bat的内容，以在目标系统上执行任意恶意代码。根据请求Login.bat的服务，这可能以本地用户或受害者机器上的SYSTEM账户身份执行。
然后，攻击者修改本地交换机中的ARP表，以确保原本指向目标服务器10.0.0.100的流量现在路由到攻击者的机器。
当受害者的机器下次请求该文件时，攻击者的机器将返回恶意版本的Login.bat。
此场景还说明，此攻击不能在互联网上广泛使用——攻击者需要针对特定系统或系统组，这些系统请求具有此唯一UNC路径的文件。
组策略漏洞是什么？
组策略在连接到域时接收和应用策略数据的方式存在RCE漏洞。同时，存在一个漏洞，组策略可能无法检索有效的安全策略，而是应用默认的、可能不太安全的组策略。这反过来可用于禁用域强制执行的SMB签名策略。
MS15-014下我们修复了什么？
通过纠正组策略在无法检索当前有效安全策略时的行为，修复了绕过SMB签名的风险。应用修复后，组策略将不再回退到默认值，而是在安全策略检索失败时使用最后一个已知的良好策略。
MS15-011下我们强化了什么？
虽然SMB签名保护免受中间人攻击，但通过组策略中的上述漏洞，可以禁用它。但更重要的是，SMB客户端默认不要求SMB签名，因此可以将域相关流量，尤其是未加密流量，导向攻击者控制的机器，并向受害者提供恶意内容。为了阻止此类攻击，我们增加了强化域网络内UNC路径访问的能力。
通用命名约定（UNC）是Windows用于访问文件资源的标准化表示法；在大多数情况下，这些资源位于远程服务器上。UNC允许系统使用标准路径格式访问文件：\\<主机名>\<共享名>\<对象名>，例如\\contoso.com\fileshare\passwords.txt，而无需应用程序或用户理解用于提供文件访问的底层传输技术。这样，Windows中的UNC客户端将网络文件技术（如SMB和WebDAV）抽象在熟悉的文件路径语法后面。UNC路径在Windows中用于从打印机到文件共享的一切，为攻击者提供了广泛的探索和攻击面。为了正确解决UNC中的这一弱点，我们必须改进UNC，允许服务器向客户端验证自身，从而使客户端机器信任来自目标系统的内容，并免受恶意文件共享的侵害。
我们如何强化它？
当应用程序或服务尝试访问UNC路径上的文件时，多UNC提供程序（MUP）负责枚举所有已安装的UNC提供程序，并选择其中一个来满足指定UNC路径的所有I/O请求。在典型的Windows客户端安装上，MUP会首先尝试服务器消息块（SMB）协议，但如果SMB UNC提供程序无法建立到服务器的SMB连接，则MUP会尝试下一个UNC提供程序，依此类推，直到其中一个能够建立连接（或者没有剩余的UNC提供程序，在这种情况下请求将失败）。
在大多数场景中，服务器的安全性至关重要：服务器存储敏感数据，因此文件传输协议的设计方式是服务器验证客户端身份并在允许客户端读取或写入文件之前执行适当的访问检查。当组策略应用计算机和/或用户策略时，信任边界完全反转：敏感数据是客户端的配置，远程服务器能够通过传输策略文件和/或脚本来更改客户端的配置。当组策略从策略服务器检索数据时，客户端执行安全检查以验证服务器身份并防止客户端和服务器之间的数据篡改（除了服务器为验证客户端凭据而执行的正常安全检查之外）非常重要。同样重要的是，MUP仅将组策略文件的请求发送到支持这些客户端检查的UNC提供程序，以防止在SMB UNC提供程序无法建立到服务器的连接时绕过检查。
组策略不一定是这些额外客户端安全检查重要的唯一服务。任何从UNC路径检索配置数据和/或自动运行位于UNC路径上的程序或脚本的应用程序或服务都可以从这些额外的安全检查中受益。因此，我们添加了新功能UNC加固访问，以及相应的组策略设置，其中可以配置MUP在访问配置的UNC路径时要求额外的安全属性。
当配置UNC加固访问时，MUP开始以稍有不同的方式处理UNC路径请求：
每次MUP收到在UNC路径上创建或打开文件的请求时，它会评估当前的UNC加固访问组策略设置，以确定请求的UNC路径需要哪些安全属性。此评估的结果用于两个目的：
- MUP仅考虑已指示支持所有必需安全属性的UNC提供程序。任何不支持通过UNC加固访问配置为请求的UNC路径所需的所有安全属性的UNC提供程序将被跳过。
- 一旦MUP选择了UNC提供程序，所需的安全属性通过额外创建参数（ECP）传递给该UNC提供程序。选择加入UNC加固访问的UNC提供程序必须尊重ECP中指示的所需安全属性；如果选定的UNC提供程序无法以满足这些要求的方式建立到服务器的连接（例如，由于缺乏服务器支持），则选定的UNC提供程序必须使请求失败。
即使是第三方应用程序和服务也可以利用此新功能，而无需额外的代码更改；只需在组策略中添加必要的配置详细信息。如果UNC提供程序能够建立到指定服务器的满足所需安全属性的连接，则应用程序/服务将能够正常打开句柄；如果不能，打开句柄将失败，从而防止对远程服务器的不安全访问。
请参阅http://support.microsoft.com/kb/3000483以获取有关配置UNC加固访问功能的详细信息。
考虑以下场景：
- Contoso维护一个名为corp.contoso.com的Active Directory域，其中有两个名为dc1.corp.contoso.com和dc2.corp.contoso.com的域控制器（DC）。
- 一台笔记本电脑加入上述域。
- 组策略配置为向笔记本电脑应用组策略对象（GPO），该GPO为路径
\\*\NETLOGON和\\*\SYSVOL配置UNC加固访问，以便所有对这些路径的访问都需要相互身份验证和完整性。 - 组策略配置为向笔记本电脑应用GPO，每次用户登录到机器时运行位于
\\corp.contoso.com\NETLOGON\logon.cmd的脚本。
使用上述配置，当用户成功登录到笔记本电脑且笔记本电脑具有任何网络访问时，组策略将尝试运行位于\\corp.contoso.com\NETLOGON\logon.cmd的脚本，但在幕后，MUP仅当文件可以安全打开和传输时才允许运行脚本：
- MUP收到打开
\\corp.contoso.com\NETLOGON\logon.cmd处文件的请求。 - MUP注意到请求的路径匹配
\\*\NETLOGON，并且匹配\\*\NETLOGON的路径配置为需要相互身份验证和完整性。不支持UNC加固访问或指示不支持相互身份验证和完整性的UNC提供程序被跳过。 - 分布式文件服务器命名空间（DFS-N）客户端检测到请求的UNC路径是域DFS-N命名空间，并开始其重写UNC路径的过程（所有DFS-N请求将受到MUP在第2步中识别的相同安全属性要求的约束）：
- DFS-N客户端使用DC定位器服务和/或DFS-N DC引用请求（取决于操作系统版本）来识别域上的DC名称（例如dc1.corp.contoso.com）。
- DFS使用选定的DC重写路径（例如
\\corp.contoso.com\NETLOGON\logon.cmd变为\\dc1.corp.contoso.com\NETLOGON\logon.cmd）。由于需要相互身份验证且目标是DC，DFS使用特殊的Kerberos服务主体名称（SPN）来验证上一步中检索的名称确实是DC的名称（如果名称不是DC，Kerberos身份验证将因未知SPN而失败）。 - 如果指定的UNC路径中有额外的DFS-N链接，DFS-N客户端继续迭代并将DFS-N链接的路径替换为可用目标的路径，直到它获得一个没有剩余DFS-N链接的UNC路径。
- 最终的UNC路径传递回MUP以选择UNC提供程序来处理请求。MUP选择SMB UNC提供程序，因为DC使用SMB共享NETLOGON和SYSVOL共享。
- SMB UNC提供程序与选定的SMB服务器建立身份验证会话（如果尚未存在身份验证会话）。如果身份验证会话不是相互身份验证的（例如，使用NTLM协议执行身份验证），则SMB UNC提供程序将失败打开logon.cmd的请求，因为无法满足第2步中识别的相互身份验证要求。
- SMB UNC提供程序在与logon.cmd相关的所有请求上启用SMB签名，因为MUP通知SMB此请求需要完整性。任何篡改SMB请求或响应的尝试都会使请求/响应上的签名无效，从而允许接收端检测未经授权的修改并使SMB请求失败。
在此场景中，端到端相互身份验证和完整性的客户端要求通过以下安全检查保护笔记本电脑免受运行位于恶意服务器上的登录脚本的侵害：
- 相互身份验证的要求确保当SMB客户端尝试建立到请求的UNC路径的连接时，连接不会重定向到意外（且可能恶意）的SMB服务器。
- 完整性的要求启用SMB签名，即使SMB客户端默认不要求所有路径的SMB签名。这保护系统免受在线篡改，这种篡改可用于在选定的DC和笔记本电脑之间传输时更改logon.cmd脚本的内容。
- 相互身份验证和完整性的组合要求确保DFS-N客户端选择的最终重写路径匹配DFS-N命名空间配置允许的路径，并且欺骗和/或篡改攻击不能导致DFS-N客户端将请求的UNC路径重写为由意外（且可能恶意）服务器托管的UNC路径。
没有这些客户端保护，通过组策略在不信任网络上发送的ARP、DNS、DFS-N或SMB请求可能导致组策略服务从错误的SMB服务器运行logon.cmd脚本。
如何配置以保护自己/我的用户？
安装作为公告MS15-011一部分的更新后，请按照http://support.microsoft.com/kb/3000483上的说明确保您的系统得到充分保护。MS15-014将安装并提供保护，无需任何额外配置。
请注意，离线文件功能在启用UNC加固访问功能的路径上不可用。
关于CVD和修复难题的说明
在许多方面，此安全“修复”更准确地描述为Windows中的全新功能。添加这种规模的东西对安全响应提出了独特的挑战。软件漏洞通常在调查和修复方面更受限制——大多数响应结构旨在解决该范围。协调漏洞披露（CVD）的好处之一是它提供了更大的灵活性和与研究人员的更深合作，以采取必要的时间和视角向客户提供最完整的安全解决方案。在这种情况下，我们解决了一个需要更大工程范围才能提供解决方案的漏洞。
报告给MSRC的大多数漏洞是单个组件中的错误，这些错误在行业接受的响应时间内被调查、理解和修复。然而，创建UNC加固的新功能需要全新的架构，这增加了开发时间并需要进行广泛测试。感谢CVD，以及与报告漏洞的热情安全研究人员的密切合作，微软有足够的时间为复杂问题构建正确的修复程序。如果安全研究人员不愿意在我们的修复程序准备好之前避免披露，客户将面临风险。
微软向CVD社区表示感谢，并特别感谢导致UNC加固的问题报告者：JAS Global Advisors的Jeff Schmidt、simMachines的Dr. Arnoldo Muller-Molina、互联网名称与数字地址分配机构（ICANN）和MWR Labs的Luke Jennings。
Geoffrey Antos（Windows）、Brandon Caldwell（MSRC）、Stephen Finnigan（MSRC）、Swamy Gangadhara（MSRC）
请注意，离线文件功能在启用UNC加固访问功能的路径上不可用。