0x00 前言 这是NTLM篇的最后一篇文章了,在之前已经花了三篇文章阐述了跟NTLMRelay有关的方方面面的内容。 在这篇文章里面将要介绍下签名,他决定了NTLMRelay能不能利用成功。 以及我们将会介绍跟NTLMRelay相关的一些漏洞,MS08-068,MS16-074,CVE-2015-0005,CVE2019-1040,CVE-2019-1384,将整个NTLMRelay漏洞利用串起来。 在之后阐述NTLM_Relay漏洞利用链的时候,我们会主要从一下三方面阐述。
- 怎么发起ntlm请求
- 拿到ntlm 请求之后要做什么
- 服务端是否要求签名
1. 关于签名的一点细节
当认证完毕之后,使用一个客户端和服务端都知道的key 对后续所有的操作进行加密,攻击者由于没有key,也没法对内容进行加密解密,所以也就没办法进行Relay,最多只能将流量原封不动转发过去。 那这个key是什么呢。 之前在网上看到的一个说法就是这个key是sessionkey,需要使用用户hash去生成,攻击者没有用户hash(有也就不需要Relay了,直接pth多好),所以没有sessionkey,也就是没办法加解密,这个时候签名也就起到了防御Relay的效果。 这种解释也没错,都说得通。 直到有一天,我跟@xianyu师傅,在winrm的流量中发现了一个字段,sessionkey。 高兴了很久,以为是微软的疏忽泄漏了sessionkey,那不就可以跟CVE-2015-0005一样绕过了签名从而进行relay了嘛。 但是在进行一番研究之后,发现事情好像没有这么简单。 在整个签名环节并非只有一个key。 下面详细介绍下三个key,比较绕,大家大致理解下。 (对于3个key的命名,不可地方表述不同)- exportedsessionkey
def get_random_export_session_key():
return os.urandom(16)
这个key是随机数。 如果开启签名的话,客户端和服务端是用这个做为key进行签名的。
- keyexchangekey
- encryptedrandomsession_key