NTLM重放攻击
2024-1-9 20:2:26 Author: Ms08067安全实验室(查看原文) 阅读量:2 收藏

点击星标,即时接收最新推文

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协议拒绝采用签名模式。

—  实验室旗下直播培训课程  —

和20000+位同学加入MS08067一起学习


文章来源: http://mp.weixin.qq.com/s?__biz=MzU1NjgzOTAyMg==&mid=2247517226&idx=1&sn=5d05302f1d34222b629d4cb89bd48444&chksm=fd1ff7636893e2cc2c2f47f229c27ff2a5e63ad20d5b463468e97e92c0d38c66d26e71152670&scene=0&xtrack=1#rd
如有侵权请联系:admin#unsafe.sh