专栏首页FreeBuf浅析如何让你的Responder更强大之增强篇

浅析如何让你的Responder更强大之增强篇

一、前言

前几天写过一篇关于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(freebuf),作者:Wreck1t

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-01-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 空手套白狼?USDT 假充值逻辑缺陷漏洞利用分析

    6月28日,慢雾科技发布了一条针对 USDT 的预警和漏洞分析,提醒各大交易所尽快暂停 USDT 充值功能,并自查代码是否存在该逻辑缺陷。全文如下:

    FB客服
  • 一种被动的Tor网络去匿名化方法

    目前针对Tor的攻击检测方法都是采用主动攻击,本文将介绍一种被动攻击的去匿名化方法。 ? 一、当前Tor网络检测方法 当前对Tor网络的攻击检测一般有以下几种...

    FB客服
  • 浅析车联网安全技术要点

    现在的汽车变得越来越聪明了,启用泊车系统则汽车可以自主寻找停车位,启用自适应巡航系统则汽车可自动调速跟车行驶,然而我们在享受汽车智能化带给我们便捷和舒适的同时,...

    FB客服
  • 如果世界上只有一种数据结构,那么我选择哈希!

    来源:blog.csdn.net/liweisnake/article/details/104779497

    芋道源码
  • djb2 hash算法

    Hash,一般翻译做“散列”,也有直接音译为“哈希”的,就是把任意长度的输入(又叫做预映射, pre-image),通过散列算法,变换成固定长度的输出,该输出就...

    李小白是一只喵
  • hash散列 introduction

    hash散列是在记录的存储位置与他的关键字之间建立的对应关系f, 使得每个key都对应一个存储位置, 查找时根据key的hash去查找.

    CoffeeLand
  • 面试题,如何在千万级的数据中判断一个值是否存在?

    当你看到这个标题的时候,你也许会想我可以使用hashmap之类的来存储值,然后get就是了。又或者把数据存在数据库里然后去判断就可以了。

    ImportSource
  • 纸上谈兵: 哈希表 (hash table)

    HASH 哈希表(hash table)是从一个集合A到另一个集合B的映射(mapping)。映射是一种对应关系,而且集合A的某个元素只能对应集合B中的一个元素...

    Vamei
  • 布隆过滤器(bloom filter)及php和redis实现布隆过滤器的方法

    在一个高并发的计数系统中,如果一个key没有计数,此时我们应该返回0,但是访问的key不存在,相当于每次访问缓存都不起作用了。那么如何避免频繁访问数量为0的ke...

    砸漏
  • Hash冲突和一致性

    在数据量很大的时候,就会出现hash之后的数值,指向相同的位置,也就是所谓的hash冲突。这个取决于hash算法的好坏,以及数据量的大小,hash算法越差,数据...

    灰子学技术

扫码关注云+社区

领取腾讯云代金券