2019年6月11日，Microsoft发布了六月份安全补丁更新。在该安全更新补丁中，对CVE-2019-1040漏洞进行了修复。攻击者可以利用此漏洞绕过NTLM中的MIC（消息） 廉正 码）。攻击者可以修改已协商的已验证流量，然后在完全删除签名请求的同时转发到另一台服务器。此攻击模式允许攻击者仅使用一个公共域帐户控制域中的任何计算机（包括域控制器）。

漏洞背景 NTLM继电器用于激活 目录环境中最常见的攻击之一。这种攻击技术的一个重要缓解是服务器签名。当用户与服务器建立签名会话时，如果无法检索所需的会话密钥，则攻击者无法劫持会话。但是，默认情况下，只有域控制器强制执行SMB签名，这在许多情况下会使域中的其他敏感服务器容易受到攻击。   图1 NTLM继电器[1]    在SMB中，通过在NTLM_NEGOTIATE消息中设置“NTLMSSP_NEGOTIATE_SIGN”标志来执行协商会话签名。如果攻击者试图中继此类NTLM身份验证，则他们需要确保不协商签名。一种方法是将协议中继到不管理会话完整性的NTLM消息，例如LDAPS或HTTPS。但是这种协议并非每台机器都会打开。 SMB协议通常在局域网中打开，并且存在许多容易导致代码执行的漏洞。因此，NTLM中继攻击的重点是将SMB身份验证请求转发到其他SMB服务器。为了成功执行此类中继，攻击者需要修改NTLM_NEGOTIATE消息并取消设置“NTLMSSP_NEGOTIATE_SIGN”标志。  

图2 NTLM_NEGOTIATE消息指示是否协商SMB签名[2]   在SMB中，默认情况下，通信的两端都支持签名，并且必须执行会话签名。为确保攻击者在NTLM协商阶段篡改数据，Microsoft在最终的NTLM身份验证消息中添加了额外的字段—— MIC。但是，微软如何处理这个领域存在一个缺陷：允许没有MIC的身份验证消息。   MIC(Message Interity Code)消息完整性验证 NTLM身份验证由三种消息类型组成：NTLM_NEGOTIATIE，NTLM_CHALLENGE，NTLM_AUTHENTICATE。 NTLM_AUTHENTICATE消息中添加了一个额外的MIC字段，以确保它在传输过程中不会被恶意篡改。 MIC是串联HMAC_MD5，它使用会话密钥应用于所有三个NTLM消息，只有发起身份验证的帐户和目标服务器才知道。因此，任何篡改其中一条消息的企图都不会产生相应的MIC，从而确保了传输的安全性。   图3 “MIC”字段可以阻止NTLM消息修改[2]   MIC存在于NTLM_AUTHENTICATE消息的“msvAvFlag”字段中，而标志0x2表示该消息包括MIC。它应该保护MIC不被删除。但是，Microsoft Microsoft服务器无法完全实现此机制并允许没有MIC的NTLM_AUTHENTICATE消息。这为后续的NTLM中继攻击提供了条件。   图4  'flags'字段表示NTLM_AUTHENTICATE消息包含MIC [2]   漏洞分析
攻击思路 由于Microsoft允许没有MIC的NTLM_AUTHENTICATE消息，因此攻击者可以在获得有效身份验证后进行中继。主要是将SMB中继到LDAP。 首先，对Windows服务器（例如Exchange）启动身份验证。获得有效认证后，认证通过LDAP中继到域控制服务器，并且可以在具有中继的受害者许可的ActiveDirective中执行一系列操作。 在Exchange方案中，可以使用DCSync权限，这是PrivExchange漏洞利用的基础。 在基于资源的约束Kerberos方案中，您可以使用此机制获取受害主机的权限，然后使用管理员权限访问服务器。 需要中继认证的MIC处理流程如下： 1.取消设置NTLM_NEGOTIATE消息中的签名标志（NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN） 2.从NTLM_AUTHENTICATE消息中删除MIC 3.从NTLM_AUTHENTICATE消息中删除版本字段（删除MIC字段而不删除版本字段将导致错误） 4.在NTLM_AUTHENTICATE消息中取消设置以下标志：NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN，NEGOTIATE_KEY_EXCHANGE，NEGOTIATE_VERSION。攻击途径 1。 使用任何AD帐户通过SMB连接到受害者主机Exchange服务器，从而触发SpoolService中的错误。然后使用在线ntlmrelayx.py脚本中继到LDAP。使用中继的LDAP身份验证，攻击者可以获得DCSync权限，然后使用DCSync转储AD中的所有密码哈希值。 2。 使用任何AD帐户通过SMB连接到受害者主机Exchange服务器，从而触发SpoolService中的错误。然后使用在线ntlmrelayx.py脚本中继到LDAP。攻击者使用中继的LDAP身份验证来获取资源。 基于约束 Kerberos中的相关权限，然后攻击者对受害主机服务器上的任何用户进行身份验证。成功验证后，您可以进一步攻击下一步甚至控制整个Wshoindows域。 影响范围 目前受影响的Windows版本： 适用于32位系统的Windows 10 Windows 10 for x64-based Systems 用于32位系统的Windows 10版本1607 适用于基于x64的系统的Windows 10版本1607 适用于32位系统的Windows 10版本1703 适用于基于x64的系统的Windows 10版本1703 适用于32位系统的Windows 10版本1709 适用于基于ARM64的系统的Windows 10版本1709 适用于基于x64的系统的Windows 10版本1709 适用于32位系统的Windows 10版本1803 适用于基于ARM64的系统的Windows 10版本1803 适用于基于x64的系统的Windows 10版本1803 用于32位系统的Windows 10版本1809 适用于基于ARM64的系统的Windows 10版本1809 适用于基于x64的系统的Windows 10版本1809 用于32位系统的Windows 10版本1903 适用于基于ARM64的系统的Windows 10版本1903 适用于基于x64的系统的Windows 10版本1903 Windows 7 for 32位系统Service Pack 1 Windows 7（用于基于x64的系统）Service Pack 1 适用于32位系统的Windows 8.1 Windows 8.1 for x64系统 Windows RT 8.1 Windows Server 2008 for 32位系统Service Pack 2 Windows Server 2008（用于32位系统）Service Pack 2（服务器核心安装） Windows Server 2008（用于基于Itanium的系统）Service Pack 2 Windows Server 2008（用于基于x64的系统）Service Pack 2 Windows Server 2008（用于基于x64的系统）Service Pack 2（服务器核心安装） Windows Server 2008 R2（用于基于Itanium的系统）Service Pack 1 Windows Server 2008 R2（用于基于x64的系统）Service Pack 1 Windows Server 2008 R2（用于基于x64的系统）Service Pack 1（服务器核心安装） Windows Server 2012 Windows Server 2012（服务器核心安装） Windows Server 2012 R2 Windows Server 2012 R2（服务器核心安装） Windows Server 2016 Windows Server 2016（服务器核心安装） Windows Server 2019 Windows Server 2019（服务器核心安装） Windows Server，版本1803（服��器核心安装） Windows Server，版本1903（服务器核心安装） 修复建议 1. 由于此漏洞的poc已在Internet上传播，因此强烈建议用户及时为此漏洞安装Microsoft的安全更新修补程序： https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1040 2. 其他缓解措施 无法及时安装安全更新修补程序时，可以使用以下度量作为临时解决方案。为确保安全，如果条件允许，仍建议用户及时安装补丁： 1）。为域中的所有服务器启用强制SMB签名（在Windows域中，默认情况下只有域控制器服务器启用了强制SMB签名） 2）。通过TLS实施LDAP的LDAP签名和LDAP通道绑定，以防止NTLM中继到LDAP 3）。打开EPA并强制所有Web服务器（OWA，ADFS）仅接受EPA请求。 4）。为所有重要服务器（例如所有Exchange服务器）上的相关应用程序启用频道绑定 5）。减少使用NTLM 6）。如果没有特殊需要，请禁用Printer Spooler服务
参考链接 [1]。 https://blog.preempt.com/security-advisory-critical-vulnerabilities-in-ntlm [2]。 https://blog.preempt.com/drop-the-mic [3]。https://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegatio