0x00 前言
在本周之前，微软发布了针对CVE-2019-1040的补丁，这是一个允许绕过NTLM身份验证中继攻击的漏洞。这个漏洞是由Marina Simakov和Yaron Zinar（以及微软咨询公司的其他几位成员）发现的，他们在这里发表了一篇关于该漏洞的漏洞细节。该漏洞允许绕过NTLM身份验证中的消息完整性。然而，如果与Lee Christensen发现的打印机Bug以及我自己的一些研究相结合，这些研究是建立在Elad Shamir的Kerberos研究基础之上，那么它的影响是相当大的。利用这些漏洞的组合，可以将SMB身份验证中继到LDAP。这允许在任何未打补丁的Windows服务器或工作站（甚至是位于不同Active Directory林中的服务器或工作站）上以SYSTEM身份执行远程代码，并通过任何未打补丁的Exchange服务器上可以将普通用户权限立即升级到域管理员（除非域中的Exchange权限减少）权限。
0x01 攻击方法
1.将SMB中继到LDAP
正如我以前在关于PrivExchange的博客中所讨论的那样，在过去一年中不同的人所做的研究，使我们距离控制Active Directory中的任何计算机权限只有一步之遥。如果您可以欺骗Windows服务器（如Exchange）与你进行身份验证，并通过LDAP将该身份验证中继到域控制器，那么可以使用被中继受害者的权限在Active Directory中执行操作。在有Exchange的情况下，这会导致足够高的权限授予自己dcsync权限，这也是priveExchange漏洞的问题。或者，通过滥用基于资源的受约束的Kerberos委托，可以在受害者服务器上授予攻击者模拟权限，这将导致在该服务器上拥有管理员访问权限（在我发布的最不好的帖子中有描述）。然而，问题在于，由于NTLM协议的工作方式，（或多或少偶然）无法将SMB流量中继到LDAP，因为这些标志将触发LDAP签名。这就阻止了由于滥用SpoolService错误而在SMB上触发的身份验证产生更多的影响.CVE-2019-1040漏洞可以修改NTLM身份验证数据包而不会使身份验证失效，从而使攻击者能够删除阻止从SMB中继到LDAP的标志。因为Active Directory已处于非常危险的状态（远离控制任何主机的一个漏洞），所以这个漏洞是使用spoolservice bug/功能来攻击任何系统的最后一个难题。这甚至可以跨林信任，因为SpoolService错误的唯一要求是任何经过身份验证的帐户。
2.攻击
目前我已准备了两种攻击途径：
- 使用任何AD帐户，通过SMB连接到受害者Exchange服务器，并触发SpoolService错误。攻击者服务器将通过SMB与您重新连接，可以使用修改后的ntlmrelayx来中继到LDAP。使用中继的LDAP身份验证，向攻击者帐户授予dcsync权限。攻击者帐户现在可以使用DCSync转储AD中的所有密码哈希值。
- 使用任何AD帐户，通过SMB连接到受害者服务器，并触发SpoolService错误。 攻击者服务器将通过SMB与您重新连接，可以使用修改后的ntlmrelayx中继到LDAP。 使用中继的LDAP身份验证，在受害者服务器上，将基于资源约束委派的权限授予攻击者控制下的计算机帐户。 攻击者现在可以以受害者服务器上的任何用户权限进行身份验证
关于这一点，有几个注意事项：
- 在第一次攻击中，Exchange服务器可以是任何版本（包括为PrivExchange已打补丁的版本）。唯一的要求是，在以共享权限或RBAC模式安装时，Exchange默认情况下具有高权限。在2019年2月12日之后安装的新Exchange部署，或者手动更新以减少此Microsoft博客中建议的安装方法而不易受到攻击（但仍可能受到第二次攻击）。
- 在第二次攻击中，服务器可以是任何未打补丁的Windows Server或工作站，包括域控制器。在以域控制器为目标时，至少需要一个易受攻击的域控制器来中继身份验证，同时在另一个域控制器上触发SpoolService错误（理论上可能会中继到同一主机，因为我们可以更改NTLM身份验证，我没有对此进行研究过）。
- 第二次攻击需要控制计算机帐户。这可能是攻击者从中获取密码的计算机帐户，因为他们已经是工作站上的管理员，或者是攻击者创建的计算机帐户，滥用了Active Directory中的任何帐户都可以默认创建这些帐户
2.1 攻击1 - Exchange上执行（再次）
在第一次攻击中，我们使用SpoolService 打印机错误来攻击Exchange服务器，并使用ntlmrelayx进行中继。可以使用krbrelayx repo中的printerbug.py，也可以使用dementor或原始的.NET代码
python printerbug.py testsegment.local/[email protected] <attacker ip/hostname>
这将使Exchange服务器连接到我们：
在使用Ntlmrelayx时，我们可以看到它的--remove mic标志：
ntlmrelayx.py --remove-mic --escalate-user ntu -t ldap://s2016dc.testsegment.local -smb2support
这授予我们的用户DCSync权限，我们可以使用它来转储所有密码哈希值：
2.2 攻击2 - Kerberos委派
第二次攻击主要是我之前博客中描述的过程。
我们使用--remove-mic和--delegate-accessflags ，启动ntlmrelayx.py，并通过tls（ldaps）将其中继到ldap，以便能够创建新的计算机帐户（我们还可以中继到普通ldap，但随后必须升级现有的计算机帐户）
ntlmrelayx.py -t ldaps://rlt-dc.relaytest.local --remove-mic --delegate-access -smb2support
然后针对辅助域控制器，再次运行printerbug.py脚本（我知道它在rlt-app-server下调用，但这是我在实验室中提升为DC的服务器）：
这使我们获得一个中继连接，创建了一个计算机帐户
我们可以使用它来模拟域管理员帐户：
我们可以使用这个模拟的票据直接对这个DC运行secretsdump并获取所有哈希值：
0x02 技巧 - 绕过森林
如果在完全不同（受信任）的Active Directory林中的用户，我们可以在relaytest.local域中执行完全相同的攻击，因为任何经过身份验证的用户都可以触发spoolservice 反向连接。因此，我建立了一个从relaytest.local到domainb.local的单向传出林信任（这意味着domainb的用户可以在relaytest林/域中进行身份验证）。这同样适用于双向信任
我们运行相同的命令，但现在触发来自domainb的用户的打印机错误：
我们看到了同样的结果：
0x03 删除MIC 标志 (CVE-2019-1040)
我已经更新了ntlmrelayx（impacket的一部分），使其具有一个--remove-mic标志，它是基于CVE-2019-1040的漏洞技术研究。
1.背景
正如我们在最近的安全通报中所宣布的那样，Preempt的研究人员发现了如何在NTLM身份验证上绕过MIC（消息完整性代码）保护，以及修改NTLM消息流中的任何字段，包括签名要求。此绕过允许攻击者将已经协商签名的身份验证尝试中继到另一台服务器上，同时完全删除签名要求。所有不强制签名的服务器都容易受到攻击
NTLM中继是对Active Directory环境最常见的攻击之一。针对这种攻击技术最显著的缓解措施是服务器签名。但是，默认情况下，只有域控制器强制执行SMB签名，这在许多情况下会使其他敏感服务器容易受到攻击。但是，为了攻击这样的服务器，攻击者需要捕获一个不协商签名的NTLM协商字段，在HTTP中是这样，但在SMB中不是这种情况，默认情况下，如果双方都支持签名，则必须对会话进行签名。为了确保NTLM协商阶段不被攻击者篡改，Microsoft在最终的NTLM身份验证消息中添加了一个附加字段--MIC。然而，我们发现，在微软最新的安全补丁之前，这个字段是无用的，它启用了所有最需要的中继场景——从SMB到SMB的中继
2.会话签名
当用户通过NTLM对目标进行身份验证时，他们可能容易受到中继攻击。为了保护服务器免受此类攻击，Microsoft引入了各种缓解措施，其中最重要的是会话签名。当用户针对服务器建立签名会话时，由于无法检索所需的会话密钥，攻击者无法劫持会话。在SMB中，通过在NTLM_NEGOTIATE消息中设置“NTLMSSP_NEGOTIATE_SIGN”标志来协商会话签名。客户端行为由多个组策略（“Microsoft网络客户端：数字签名通信”）来决定，默认配置是为其设置有问题的标志。如果攻击者试图中继这样的NTLM身份验证，他们将需要确保不协商签名。这样做的一种方法是中继到协议，其中NTLM消息不控制会话完整性，例如LDAPS或HTTPS。但是，这些协议并非在每台计算机上都被打开的，而是在所有Windows计算机上默认启用的SMB，在许多情况下，它允许远程执行代码。因此，NTLM中继攻击的技巧在于将SMB身份验证请求中继到其他SMB服务器。为了成功执行此类NTLM中继，攻击者需要修改NTLM_NEGOTIATE消息并取消设置“NTLMSSP_NEGOTIATE_SIGN”标志。但是，在新的NTLM版本中，可以防止这种被修改的保护 - MIC覆盖
NTLM_NEGOTIATE消息指示是否协商SMB签名
3.MIC概述
NTLM身份验证由3种消息类型组成：NTLM_NEGOTIATE，NTLM_CHALLENGE，NTLM_AUTHENTICATE。为了确保消息在传输过程中不会被恶意者进行篡改，在NTLM_AUTHENTICATE身份验证消息中添加了一个额外的MIC（消息完整性代码）字段。MIC是使用会话密钥应用于所有3条NTLM消息的串联的HMAC_MD5，该会话密钥仅对启动认证的帐户和目标服务器是已知的。因此，试图篡改其中一条消息的攻击者（例如，修改签名协商）将无法生成相应的MIC，这将导致攻击失败。
“MIC”字段可防止NTLM消息修改
MIC的存在在NTLM_AUTHENTICATE消息的‘msvAvFlag‘字段中（标志0x2表示该消息包括MIC），它应完全保护服务器免受试图删除MIC并执行NTLM中继的攻击者的攻击。但是，我们发现Microsoft服务器不利用此保护机制，并且允许未签名（无MIC））NTLM_AUTHENTICATE消息。
‘flags‘字段指示NTLM_AUTHENTICATE消息包括MIC
4.删除MIC
我们发现所有NTLM身份验证请求都容易受到中继攻击，无论哪个协议承载这些请求。如果协商请求包含签名要求，攻击者需要执行以下操作才能绕过MIC的保护：
- 取消设置NTLM_NEGOTIATE消息中的签名标志（NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN）
- 从NTLM_AUTHENTICATE消息中删除MIC
- 从NTLM_AUTHENTICATE消息中删除版本字段（删除MIC字段而不删除版本字段将导致错误）
- 在NTLM_AUTHENTICATE消息中取消设置以下标志：NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN，NEGOTIATE_KEY_EXCHANGE，NEGOTIATE_VERSION。
我们认为这是一个严重的攻击向量，它打破了MIC以任何方式保护NTLM身份验证的误解。我们认为问题在于，接受具有“msvAvFlag”值的认证的目标服务器实际上没有验证该字段的存在。这使得所有不强制执行服务器签名的服务器（在大多数组织中，这意味着绝大多数服务器，因为默认情况下只有域控制器强制执行SMB签名）都容易受到NTLM中继攻击。
此攻击不仅允许攻击者绕过会话签名协商，而且还使组织容易受到更复杂的中继攻击，这些中继攻击操纵传输中的NTLM消息以绕过各种安全设置，例如EPA（增强的身份验证保护）。有关此攻击的更多详细信息，请参阅以下博客。
为了真正保护您的服务器免受NTLM中继攻击，请在所有服务器上强制执行签名。如果此类配置对您的环境过于严格，请尝试在尽可能多的敏感服务器上配置此设置。
Microsoft已发布以下修复程序：https： //portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1040
0x04 绕过EPA攻击支持Windows集成身份验证Web服务器
正如我们最近的安全通报中所宣布的那样，Preempt的研究人员发现了如何绕过增强的身份验证保护（EPA）机制，成功地在任何支持WIA（Windows集成身份验证）的服务器上通过TLS发起NTLM中继攻击。
攻击者可以使用此攻击技术攻击关键服务器，例如：
- Exchange（OWA） - 对邮件服务器执行NTLM中继到邮件服务器并窃取用户电子邮件
- Active Directory联合身份验证服务（AD-FS） - 执行到HTTPS会话的NTLM中继，并模拟云资源上的用户
- Active Directory - 对LDAPS执行NTLM中继,并使用恶意设置配置目录。
可以在所有Windows版本上利用此漏洞。Preempt尚未发现任何缓解措施。
1. EPA - 背景
NTLM中继是对Active Directory环境最常见的攻击之一。微软提供了两种抵御NTLM中继攻击的技术 ， 一种是服务器签名，主要用于SMB和DCE/RPC，另一种是通道绑定，也称为EPA。EPA是一种机制，可确保通过TLS通道发送的所有数据包都由知道客户端密钥的一方发送（在NTLM情况下，NT是哈希）。这是通过将Windows身份验证过程与TLS会话绑定来实现的，方法是要求客户端使用GSSAPI安全性签署服务器证书的派生版本。在NTLM中，这是通过在NTLM_AUTHENTICATE消息中添加特定的通道绑定AV对来实现的。由于整个AV对结构都是在NTProofStr中签名的，攻击者无法在不知道用户的NT哈希的情况下来修改它。
带有通道绑定的NTLM_AUTHENTICATE消息
2. EPA bypass
在另一项发现中，Preempt研究人员找到了一种从NTLM身份验证中删除消息完整性代码（MIC）的方法。当MIC别删除时，攻击者可以篡改NTLMSSP_CHALLENGE消息。如何利用这些呢？
NTLMSSP_CHALLENGE消息包含TargetInfo字段，NTLM客户端通常回显TargetInfo中的所有AV对，并将这些AV对包含在NTLMSSP_AUTHENTICATE消息中的AV对中。这意味着任何攻击者（可以修改NTLM消息）都可以发送带有自己选择的通道绑定的恶意NTLM_CHALLENGE，以攻击受EPA保护的任何服务器。
带有通道绑定元素的恶意NTLM_CHALLENGE消息
我们认为这是一种严重的攻击手段，因为EPA实际上是保护关键服务器（如AD-FS或OWA）的唯一防线。在许多组织中，网络中占用空间较小的攻击者很可能会使用户通过NTLM进行身份验证并传递其凭据。事实上，由于AD-FS和OWA经常对互联网开放，在某些情况下，攻击者只需发送恶意电子邮件（例如，所描绘的攻击在这里），就可以在没有受感染的机器的情况下攻击这些服务器。
带有植入通道绑定的NTLM_AUTHENTICATE消息
0x05 防御和缓解措施
重要的是要了解补丁是不够的。为了完全保护您的服务器免受这些类型的NTLM中继攻击，您需要首先在所有服务器上强制执行通道绑定。此任务可能被证明是困难的，因为这需要在每个服务器上完成（没有管理此功能的组策略）。此外，此漏洞可用于针对域控制器发起LDAPS中继攻击，类似于2017年Preempt发现的攻击。要防止LDAPS中继攻击，必须在所有域控制器上强制执行通道绑定
通过滥用CVE-2019-1040，我们可以使用协议弱点和默认设置的组合来控制任何易受攻击的Windows主机。最重要的缓解措施是尽快安装2019年6月的汇总补丁。
除此之外，如果您还没有这样做，请按照PrivExchange博客（已发布更新部分）中所说的那样：降低Exchange的权限。
您可以通过在TLS上为LDAP强制LDAP签名和LDAP通道绑定来阻止NTLM中继到LDAP。然而，正如另一个博客中所描述的那样，当没有安装此问题的补丁时，也可能被绕过通道绑定
为防止攻击者触发SpoolService错误，您可以选择禁用Printer Spooler服务。另一种缓解方法是阻止主机上445端口的出站流量，或确保防火墙规则过滤来阻止服务器连接到客户端范围并尽可能地隔离各个客户端。一般来说，拥有精细分的分段网络是一项重要的防御措施。
总而言之，请记住，即使安装所有可用的补丁程序，您仍然可以将SMB从中继到LDAP，除非您应用进一步的纵深防御措施，否则它只是在等待下一个不可避免的NTLM攻击
0x06 其他
POC代码暂时出现在我的个人GitHub上，直到它被合并到impacket：https://github.com/dirkjanm/impacket/tree/micremove中。这实现了SMB和LDAP（s）中继客户端中的MIC删除。
原文地址：https://www.cnblogs.com/backlion/p/11025119.html