NTLM重放攻击

NTLM重放攻击

Kerberos域网络中，默认NTLM协议是主要的替代认证协议，几乎伴随着Kerberos协议，NTLM协议的安全性会对域网络产生重要的冲击，所以我们单独成立一个独立的章节介绍与NTLM协议相关的漏洞和攻击手段。

NTLM Relay重放攻击(Replay Attacks)又称中间人攻击、回放攻击，是指攻击者截取认证相关的报文，对报文进行一定的篡改后，发送给目标主机，达到欺骗目标系统的目的，主要用于身份认证过程，破坏认证的正确性。重放攻击在任何网络通过程中都可能发生，是黑客常用的攻击方式之一。

NTLM重放攻击由最早由Dystic在2001年提出，用于攻击SMB协议的NTLM认证过程，作者发布了对应的SMBRelay攻击工具；2004年，发展为由HTTP协议重放至SMB协议的NTLM认证过程，即在HTTP协议中使用的NTLM认证信息重放至SMB协议的NTLM认证过程，该方式在Black Hat会议上发布，但是作者未公开发布对应的攻击工具，直到2007年，类似功能的工具才被集成到MetaSploit平台，可以进行跨应用层协议的重放攻击；2008年，HTTP重放至HTTP的NTLM重放攻击被实现（MS08-067，该补丁包含多个漏洞，也包含著名的远程攻击漏洞）；最近这些年关于NTLM的重放攻击在很多基于NTLM认证的协议中被验证，例如Exchange Web Service、IMAP、POP3、SMTP等，导致了不少重大漏洞，后面我们将对几个最新的典型漏洞进行介绍。

NTLM重放攻击概念

NTLM重放攻击，开始的时候比较好理解，随着微软安全措施的加强和漏洞的成因更复杂化，后面理解NTLM重放攻击更加困难，为了能让读者们能够清晰掌握，我们从最基本的应用场景开始，逐渐深入，层层分解剖析NTLM重放攻击。

NTLM重放攻击原理示意图

我们从图上最简单的场景开始。在内网中有一个客户端，有一个应用服务器，应用服务器在445端口开放了SMB服务；在客户端、应用服务器之间，存在一个中间人攻击者，在445端口开放了伪造的SMB服务。中间人攻击者通过ARP、NETBIOS等欺骗手段，使得客户端认为中间人就是应用服务器，开始连接中间人的445端口SMB服务，并发起NTLM认证，中间人攻击者将NTLM认证重放至真正的应用服务器，从而获取访问真正应用服务器SMB服务的权限。具体步骤如下：

1、客户端与中间人攻击者建立了SMB服务的TCP连接会话（会话A），在会话A的基础上，客户端以eviluser的身份向中间人攻击者发送NTLM认证协商报文NTLM_NEGOTIATE；

2、中间人攻击者与应用服务器建立SMB服务的TCP连接会话（会话B），在会话B基础上，将收到的NTLM_NEGOTIATE报文重放转发至应用服务器；

3、应用服务器在会话B中发送NTLM_CHALLENGE挑战报文给中间人攻击者，中间人攻击者将在会话B中收到的NTLM_CHALLENGE挑战报文通过会话A转发给客户端；

4、客户端使用eviluser的口令NTLM值加密挑战报文得到NTLM_AUTHENTICATE认证报文，通过会话A发送给中间人，中间人攻击者将在会话A中收到的认证报文通过会话B转发给应用服务器；

5、应用服务器依托认证服务器（本书中等同于域服务器）通过认证后，认为中间人攻击者是合法eviluser客户端，真正的客户端收到认证通过的消息后，认为中间人攻击者是合法的应用服务器。

在这个场景中，从客户端的角度看，中间人攻击者开放了服务，并且在认证后能够提供正常的服务，所以中间人攻击者就是应用服务器；从应用服务器的角度看，中间人攻击者发起了服务请求，并进行了eviluser账号的合法认证，所以中间人攻击者就是客户端。这种重放攻击导致的结果是中间人重放eviluser账号的认证信息至应用服务器，获取了在应用服务器的访问权限，这也是NTLM重放攻击和NTLM中间人攻击概念等同的原因。在2005年左右，这个应用场景非常普遍，在现在的Windows操作系统中，读者可能认为这个场景不大可能以这么漏洞百出的直白方式出现，读者可以携带这个疑问进入后面的分析。

将上述的NTLM重放攻击应用场景进行提炼，概括为基本模式，可以表述为在攻击主机上开放伪造的SMB、HTTP等服务，通过ARP、NETBIOS或者社会工程学的方式诱骗高权限账号访问这些伪造的服务，一旦有来访者，便要来访者提供NTLM认证信息，攻击者将这些认证信息重放至重要的目标服务器，从而获取目标服务器的高访问权限。

上图中，有一个地方需要注意，客户端先发起服务请求，例如SMB、HTTP等，在服务请求的过程中需要有认证，认证发生在服务请求的会话中，认证完成后，才可以开始后续的访问行为，可以将服务请求的会话分作2个阶段，即认证阶段和访问阶段。前文提到，微软为了方便不同的应用层协议调用NTLM协议进行认证，提供了NTLM SSPI统一接口供应用层协议调用。

HTTP、POP3、SMTP、LDAP、SMB等应用层服务，不仅仅支持NTLM协议，还支持其他众多认证协议，例如Kerberos、NTLM、BASIC、MD等，这就注定应用层协议不能集成认证协议。为了解决这个问题，IETF小组设定了GSSAPI标准，用于封装认证协议，应用层协议通过简单调用GSSAPI接口即可实现认证功能，微软参照GSSAPI为Windows系统实现了一套对应的接口SSPI。在上面的例子中，SMB协议调用NTLMSSPI实现NTLM认证，认证完成后，SMB才开始后续的访问操作，HTTP、LDAP等协议类似。

注意，认证协议的具体信息和流程，与应用层协议无关，即HTTP协议中的NTLM认证、与SMB协议中的NTLM认证完全相同，这是后续跨应用层协议NTLM重放攻击的基础，例如由HTTP->SMB的重放攻击，上图中是SMB->SMB的重放攻击。

为了对抗NTLM重放攻击，微软已经推出多个安全举措，主要包括如下几个：

1、强制SMB签名和通信会话签名，防止攻击者重放NTLM身份验证消息以建立SMB和DCE/RPC会话；

2、启用消息完整性代码（MIC），防止攻击者篡改NTLM认证消息本身；

3、启用增强型身份验证保护（EPA），防止攻击者将NTLM认证消息重放至TLS会话，例如连接到各种HTTPS Web服务，访问用户电子邮件（通过中继到OWA服务器）、连接到云资源（通过中继到ADFS服务器）等各种操作；

4、强制LDAPS签名，在域服务器上强制启用LDAP签名和LDAPS安全通道绑定，使得LDAP协议转为LDAPS协议，符合第3点的满足要求。

我们以SMB签名为例说明微软的安全措施是如何发挥保护作用的。签名保护最重要的是签名密钥，算法、内容公开。上图中，中间人攻击者可以获取客户端和应用服务器之间的所有交换报文，签名机制为了对抗这种模式，就不能让中间人拿到或者解开密钥。有2种方式可以实现，一是不交换签名密钥，而采用事先约定的密钥；二是采用公私钥的方式交换密钥。目前，在基于NTLM认证的模式下，采用第1种方式。密钥生成的具体流程如下：

1、客户端基于eviluser账号的口令NTLM值，使用固定的算法对固定的内容进行加密计算，得到SessionKey，作为应用层协议会话的会话签名密钥，SessionKey的具体算法如下；

// NTLMv1版本下

Key = MD4(NT Hash)



// NTLMv2版本下

NTLMv2_Hash = HMAC_MD5(NT Hash, Uppercase(Username) + UserDomain)

Key = HMAC_MD5(NTLMv2_Hash, HMAC_MD5(NTLMv2_Hash, NTLMv2_Response + Challenge))

2、认证服务器基于eviluser账号的口令NTLM值，使用固定的算法对固定的内容进行加密计算，得到相同的SessionKey，并将SessionKey通过安全会话返回给应用服务器（应用服务器会依托域服务器进行认证）。

在上述过程中，客户端和应用服务器分别拿到了相同的会话密钥SessionKey，并使用SessionKey进行签名。由于没有交换，中间人攻击者无法获取SessionKey。因此，即使中间人攻击者已经认证到应用服务器，但是由于无法进行签名，不能与应用服务器进行后续的会话操作，即使通过重放攻击完成认证也没有实际意义，这就是微软采用签名对抗NTLM重放攻击的原理。

会话签名的安全措施会产生几个细节问题，一是并不是所有的系统都支持签名，尤其是老版本的Windows操作系统，因此是否签名需要协商，NTLM协议的NTLM_NEGOTIATE阶段会协商是否需要签名；二是并不是所有的应用层协议都支持签名，例如HTTP几乎不支持，或者应用层协议本身已经加密，所以不再需要签名，例如LDAPS等。第1种情况，后续导致了几个典型的漏洞；第2种情况，攻击者只需将认证信息重放至不需要签名的应用层协议，可继续完成NTLM重放攻击，例如CVE-2017-8563漏洞，就是将认证信息重放至LDAPS协议，因为LDAPS协议拒绝采用签名模式。