nbns协议_Windows内网协议学习NTLM篇之漏洞概述

49093010f67c11b99a8d190faced335b.png

0x00 前言 这是NTLM篇的最后一篇文章了,在之前已经花了三篇文章阐述了跟NTLMRelay有关的方方面面的内容。 在这篇文章里面将要介绍下签名,他决定了NTLMRelay能不能利用成功。 以及我们将会介绍跟NTLMRelay相关的一些漏洞,MS08-068,MS16-074,CVE-2015-0005,CVE2019-1040,CVE-2019-1384,将整个NTLMRelay漏洞利用串起来。 在之后阐述NTLM_Relay漏洞利用链的时候,我们会主要从一下三方面阐述。
  1. 怎么发起ntlm请求
  2. 拿到ntlm 请求之后要做什么
  3. 服务端是否要求签名
 0x01 SMB签名 以及LDAP签名

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的命名,不可地方表述不同)
  1. exportedsessionkey
def get_random_export_session_key():return os.urandom(16)
这个key是随机数。 如果开启签名的话,客户端和服务端是用这个做为key进行签名的。
  1. keyexchangekey
这个key使用用户密码,Server Challenge,Client Challenge经过一定运算得到的。

df549aecdffcc4c1dc5c06526887983f.png

  1. encryptedrandomsession_key
前面说过开启签名的话,客户端是使用exportedsessionkey做为key进行加密解密的,而exportedsessionkey是客户端生成的随机数,那服务端不知道这个key。 这个时候就需要协商密钥。 encryptedrandomsessionkey的生成如下图所示,使用keyexchangekey做为Key,RC4加密算法加密exportedsessionkey。 4a06a96d37a29c0372a3f591c8e81726.png encryptedrandomsessionkey在流量显示是 Session Key.这个是公开的,在流量里面传输给服务端,服务端拿到这个的话,跟keyexchangekey一起运算得到exportedsessionkey,然后使用exportedsessionkey进行加解密。 2087baf8c726b0935df46a3f14d0d906.png 对于攻击者,由于没有用户hash,也就没办法生成keyexchangekey,虽然在流量里面能够拿到encryptedrandomsessionkey,但是没有keyexchangekey,也就没办法运算出exportedsession_key,也就没法对流量进行加解密。 从而进行Relay。

2. SMB 签名

有些地方表述为个人pc 默认没有开启smb签名,服务器计算机默认开启smb签名,在我实际测试中发现这个说法是不正确。 在域内的默认设置是仅在域控制器上启用,域成员机器并没有启用。

83fac178734d12a86e61ca637ab50f97.png

3. LDAP 签名

在默认情况底下,ldap服务器就在域控里面,而且默认策略就是协商签名。 而不是强制签名。 也就是说是否签名是有客户端决定的。 服务端跟客户端协商是否签名。 (客户端分情况,如果是smb协议的话,默认要求签名的,如果是webadv或者http协议,是不要求签名的)微软公司于 2019-09-11 日发布相关通告称微软计划于 2020 年 1 月发布安全更新。 为了提升域控制器的安全性,该安全更新将强制开启所有域控制器上 LDAP channel binding 与 LDAP signing 功能。

6ee0177d94c6dfbcce7529888977acef.png

 0x02 漏洞概览

1. MS08-068

在这之前,当拿到用户的smb请求之后,最直接的就是把请求Relay回用户本身,即Reflect。 从而控制机子本身。 漏洞危害特别高。 微软在kb957097补丁里面通过修改SMB身份验证答复的验证方式来防止凭据重播,从而解决了该漏洞。 防止凭据重播的做法如下:
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值