浅析如何让你的Responder更强大之增强篇 – 作者:Wreck1t

一、前言

前几天写过一篇关于Responder的文章《浅析如何让你的Responder更强大》。在那篇文章中,我们修复了Responder 实现的SMBv1&SMBv2的问题:使其能够兼容net use客户端的多次Hash捕获,并修复了SMBv2实现存在的bug。

今天的主角依然是Responder,不过讨论的主题变成了NTLM 认证。这次我们要谈不是bug,而是功能的Enhancement。容我一点一点的跟各位大佬慢慢道来。

还是那句话:作为一名医学生——逻辑一般,文采不行,文章难免存在纰漏之处,欢迎大家批评指正。

二、思考

为了防止混淆,我们先把文章中出现的几个术语限定一下:

hash:没有特别指出,那就是用来代指Net-NTLM hash

凭证:没有特别指出,那就是代指用户密码或NTLM hash

现在我们先来思考几个问题:

1.Responder为什么要支持多次hash捕获?同样我们为什么要尽可能多的收集用户hash?

2.当用户多次输入密码进行认证时,处于暗处收集用户hash的我们,如何去区分那些hash是不同凭证产生的,那些是同一凭证产生的?以及区分它的意义在哪?

3.思考2分钟,然后再继续阅读。

我依次正对以上问题谈谈我的看法:

1.因为无论是个人还是企业都存在一个密码设置的套路:如办公区A区部分设置成ABC123,B区设置成ABC345,C区设置成ABC567.当A区一个用户想要访问B区的一个文件共享时,首先会在explorer下输入\\abc-001(位于B区的一台文件共享服务器),然后默认会用该用户的密码去认证,此时如果Responder响应的相对于abc-001更快或用户输入错误,我们就有机会捕获第一次(其实explorer实现的客户端默认用该账户和密码认证好多次),然后Responder返回PASSWORED_EXPIRED,要求用户重新输入密码,此时用户可能会陷入自我怀疑,然后尝试用C区或A区的密码进行认证(想想你忘记爱奇艺密码是的场景,你是不是会翻出自己所有的密码进行尝试),这样我们就有机会尽可能多的收集到该公司的凭证。用于后续渗透。

2.如何区分hash是由不同的凭证产生的?这是我们今天讨论的话题。我们先说一下成功区分的意义吧:节约破解的时间成本

三、Responder 捕获net-ntlmv1 hash的现状:

这里姑且先叫做net-ntlmv1 hash,但是它不是。在我遇见的好多做渗透的小伙子们都傻傻分不清什么是net-ntlmv1 hash和net-ntlmv1+ess hash,一会儿一边实验一边解释,好伐!

1.实验环境:

windows xp       

kali                         

2.实验

2.1 同时开启Windows XP 和Kali ,在Kali 控制台下输入Responder -I eth0 -v,启动Responder。然后回到windows xp,打开我的电脑,在explorer.exe下地址栏里输入\\cfca访问文件共享。我们看到,如图1,图2:

图 1

图 2

2.2 我们看到xp 返回不可访问错误,Responder 捕获了两次hash,是不是看似很完美,好像真的实现了多次hash捕获。

先冷静一下,这其实是同一个账户密码产生的Net-NTLMv1 hash,只是看起来好像两次不同的密码认证而已(是不是傻傻分不清)。先普及一下,当在explorer下输入\\cfca进行SMB访问时,客户端默认会用当前用户名密码进行4次认证尝试,如果都不成功,客户端会断开或不中断连接,然后返回一个用户密码认证框,要求用户输入新的账号密码进行认证(为什么和net use 不同,我只能说:可能是两中SMB客户端是由不同的团队实现的吧,毕竟我也没在微软)—–到这一步以后的操作,才能称得上是真正意义上的多次捕获。

现在我们来说说为什么会有一个现在这样的畸形的情况呢?因为Responder 在实现SMBv1时添加了一个很恶心的计数器ntry(为什么说恶心,因为net use 的SMB客户端默认尝试一次,认证失败后,要求用户输入用户名密码进行重新认证,共计2次,但是是两个不同连接,所以ntry会失效。而explorer默认尝试4次,然后才要求用户重新认证,天了个撸,他竟然生效了。该生效时不生效,不该生效时瞎JB捣乱),我们干脆然他永远不生效:

回到kali ,在控制台下输入vi /usr/share/responder/servers/SMB.py,定位到如下代码,如图3:

图 3

将self.ntry == 0 该为self.ntry != 10.这样就可以了,因为没有一个客户端会默认尝试10次。

2.3 我们再来抓包看一下,如图4 图5

图4

图 5 

终于回归正常了,经过4次的默认认证后,客户端弹出了要求用户输入账号密码的框框。这也算工能正常了。

到这儿,把上一篇文章的坑也算填了。

不过很可惜,上面的都不是重点:重点要来了——–我们这这篇文章的目的是说,在暗处收集hash的我们如何区分捕获的hash是由不同的用户凭证产生的。

单单从上面看,同一个用户名和密码产生的”Net-NTLMv1 hash”都区分不出来。用户哪怕重新认证了我也不知道啊,怎么办?我先帮大家回忆一下NTLM认证。

四、NTLM认证过程

Net-NTLMv1的加密流程如下:

1.客户端向服务器发送一个请求

2.服务器接收到请求后,生成一个8字节的Challenge,发送回客户端

3.客户端接收到Challenge后,使用登录用户的密码hash对Challenge加密,作为response发送给服务器

4.服务器校验response

对,就是这样子的。看完这些,我想应该有小哥哥要跳出来说了:“你去配置里面固定Challenge啊,SB,这都不懂,还写文章,咋不去死”,奥,我们来试一下。

五、Responder hash捕获增强版

5.1 同时打开xp 和kali ,vi /usr/share/responder/Responder.conf.  将Challenge设为1111111111111111(只是一个16进制数)。然后开启Responder。用xp进行文件访问\\cfca:得到如图6

如图6

惊不惊喜,意不意外,相同的密码,相同Challenge,竟然产生不同的”Net-NTLMv1 hash”。酸不酸爽。

是不是没有解决的办法了?

答案是:当然不是

填坑的时间到了。其实它上面的hash不叫”Net-NTLMv1 hash”,它是Net-NTLMv1+ESS hash,它是用在不支持NTLMv2认证的环境中的NTLMv1认证的安全增强版本,用于防止“预先计算的字典攻击”。特征是LM Response段的32个0,及16字节的\x00(NULL)。现在大家明白了吧。详细信息如图:

有兴趣的,自己了解。

看明白了吗?不明白也没关系,记住32个0就行,它叫Net-NTLMv1+ESS hash。它就是相同凭证产生不同hash,令我们傻傻分不清的元凶。

可能又有同学跳出了说:“我知道Responder有一个参数,可将Net-NTLMv1+ESS hash降级为Net-NTLMv1 hash”。但它只适用于XP以前的机器。一旦开启,就预示着你要放弃捕获同一网络环境中XP以后机器产生的Hash,这个参数成本高到只适用于演示和做实验。我们一起看一下

5.2 同时打开window 7和xp以及Kali,开启responder。使用命令:responder -I eth0 -v –lm:强制其降级,然后分别用在win7 和XP上使用\\hello1 和\\hello2访问文件共享:获得如图

XP降级成功。

无法与Windows 7 (高与XP的系统交互)

之所以会出现这种情况,是因为Responder 实现了一个单独实现了一个针对降级的SMB服务器SMB1LM(如图),一旦使用–lm,就会启用该服务器,进行交互。而XP以后的操作系统,默认不支持。

难道没有两全的办法?

当然有。

这次我们降的不是SMB服务器,而是通过在NTLM协商过程,告诉它:我不要你使用Net-NTLM + ESS hash跟我进行认证操作。进而通过NTLM协商将其降为Net-NTLMv1 hash。

如图7,Challenge包会带有一个Negotiate Flags的字段,它代表众多的协商标志位,Negotiate Extended Security标识位对我们的结果产生了巨大影响,我们要做的就是把Set改为Not Set,然后要求客户端使用Net-NTLMv1 Hash来向我们认证。

图7

5.3 现在我们改它一下:vi /usr/share/responder/packets.py 搜索这个Flags,然后将它替换为图8,即禁用Extended Security:

图8

5.3 重新实验:获得如下图9所示:

图9

开不开心,意不意外,而且在降级的同时,不影响更高版本的系统产生的hash抓取。

不幸运的是:你可能依然分不清Net-NTLMv2 相同用户名不同密码的情况。不多聊,有兴趣自己研究。

关于如何破解,我就不多说了,网上资料太多了。这里点一下而已

1.https://crack.sh/netntlm/

2.hashcat

六、总结

为什么我这么帅,却依然没有女朋友?(真等我给你们总结啊,天真……(^-^))

七、参考材料

1.http://davenport.sourceforge.net/ntlm.html

2.https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb/ee3e4254-083b-4230-9289-3ca0f969ac5a

3.https://github.com/lgandx/Responder

4.https://crack.sh/netntlm/

5.https://3gstudent.github.io/3gstudent.github.io/Windows%E4%B8%8B%E7%9A%84%E5%AF%86%E7%A0%81hash-NTLM-hash%E5%92%8CNet-NTLM-hash%E4%BB%8B%E7%BB%8D/

*本文原创作者:Wreck1t,本文属于FreeBuf原创奖励计划,未经许可禁止转载

来源:freebuf.com 2020-01-22 09:00:44 by: Wreck1t

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论