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

前言

渗透圈内，Responder声名远扬。去年在使用中发现了一些异常，脑子抽筋，读了smb协议和Responder源码，进而发现了Responder在实现上存在的一些问题，然后进行了修复和完善，趁着这几天有时间，进行了简单整理和分析，分享出来，希望对大家有所帮助。

原标题：Make your Responder stronger

我们先看两张图片

图1

图2

图1是我从Responder官方（其实是非官方，你懂的）GitHub（ https://github.com/lgandx/Responder ）上找到的一段话，大致意思：支持抓去NTLMv1，NTLMv2 Hash，并成功的在Windows 95 到Server 2012 RC等机器上测试，而且内建并支持了SMBv2。

图2是我在responder的配置文件截的图，大致是说：开启CaptureMultipleCredentials，可让Responder发送ACCOUNT_DISABLED当客户端想向服务器认证时，然后尝试抓去多个hash值。（这个配置从源码上看只适用于SMB1）

大家看懂了吧，那就先别下，等我说完，然后去我GitHub上 https://github.com/wreck1t/Responder 下载，因为他在骗你：

1.内建的SMBv2实现存在缺陷，在与某些常用SMB客户端交互时无法正常工作，更别提捕获Hash了。

2.CaptureMultipleCredentials开启， 在与某些常用SMB客户端交互时， SMBv1也只能抓到一次Hash。

由于SMB客户端的多样性和不同客户端实现的复杂性，本文以net use客户端为例，对Responder实现的SMBv1和SMBv2存在的问题进行解析，并进行修复。

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

二.背景知识

1.Responder

由Laurent Gaffie撰写的Responder是迄今为止，在每个渗透测试人员用于窃取不同形式的凭证（包括Net-NTLM hash）的最受欢迎的工具。它通过污染LLMNR和NBT-NS等主机解析请求，从而欺骗目标主机与其实现的恶意服务器通信，从而达到设置恶意浏览器代理，窃取凭证等目的。当网络上的设备尝试用LLMNR和NBT-NS请求来解析目的地机器时，Responder就会伪装成目的地机器。当受害者机器尝试登陆攻击者机器，responder就可以获取受害者机器用户的Net-NTLM哈希值。

2.SMB工作流程

2.1.首先客户端发送一个SMB negotiate protocol request请求数据报，并列出它所支持的所有SMB协议版本，如图3中No 20所示：

2.2.服务器收到请求信息后响应请求SMB2 negotiate protocol response，并列出希望使用的协议版本。如图3中 No 24所示：（明眼的同学发现中间有几个包略过了，别急，咱一会再说）

2.3.协议确定后，客户端进程使用磋商好的版本向服务器发起认证以获得访问权限。

2.4.服务器发送一个Session setup response应答数据包允许或（附带拒绝的原因）拒绝本次连接。

注：2.3和2.4的认证涉4步（NTLM认证的内容），讲起来内容比较多，网上资料也比较多，我的任务是介绍流程，让大家对SMB不太陌生。

图3

3.NTLM认证（挑战响应机制）

三.实验环境：

Windows 7 （默认支持smb1 smb2）  ip：172.20.10.8
Windows XP （默认只支持smb1）      ip：172.20.10.7
kali （默认自带Responder）                ip：172.20.10.6

四.实验详情：

1.先说SMBv1：

1.1. 同时开启Windows XP和Kali，配置Kali中Responder配置文件，路径：/usr/share/responder/Responder.conf。设置CaptureMultipleCredentials=On，这也是responder的默认设置，设置完成后，在终端输入responder -I eth0，开启responder进行Hash捕获，

1.2. 来到XP，在cmd下输入net use \\cfca回车（当用户不输入账号密码时，windows会使用当前的用户的账号密码尝试NTLM认证，如果认证失败，客户端会要求用户输入账号密码重新认证—-这是正常流程，按照正常流程，我们是会认证两次，而responder也会捕获两次Hash。）

1.3 windows 提示：账户被禁用，然后终止，kali也只捕获到一次hash。如图4图5所示

图4

图5

说好的捕获多次呢，骗人。我们来看一下WireShake抓包的情况，如图6:

就像配置文件里说的，responder返回了ACCOUNT_DISABLED”\x72\x00\x00\xc0″的响应 ，没问题啊。

为什么会出现这种情况呢？

这要归咎于SMB客户端的复杂性，不同的SMB客户端可能是由不同的团队实现。 ACCOUNT_DISABLED”\x72\x00\x00\xc0″对于某些SMB客户端会导致客户端重新认证，而 net use实现SMB客户端收到ACCOUNT_DISABLED”\x72\x00\x00\xc0″的数据包，会将认证状态打印到屏幕上，然后中断正常的再次认证流程。

经过查阅资料和实验，我们可以将它改为PASSWORD_EXPIRED “\x71\x00\x00\xc0″，因为它有更好的兼容性（其实能改的值很多，比如LOGON_FAILURE “\x6d\x00\x00\xc0″，我们这里用PASSWORD_EXPIRED “\x71\x00\x00\xc0″），客户端会进行再次认证。

1.4 回到kali，打开终端，输入vi /usr/share/responder/servers/SMB.py.作如下图7更改

图7

1.5 删掉Responder.db， 重启Responder.回到windows xp重新认证。你会发现，哈哈哈，成功了！如图8图9

图8

图9

2.再来SMBv2:

2.1 同时开启Windows 7和Kali，启动Responder，然后windows 7 系统cmd下net use \\cfca.你会发现什么也抓不到，只进行了对LLMNR解析的响应。又要如图，，，如图10 图11

图10

图11

来，我们分析一下WireShark抓到的包。

图12

如图12所示，客户端正常进行了认证（No 2945，No 2946，No 2947），只是responder未对客户端进行响应，所以造成了客户端出现“system error 64 ”错误，但理论上，net-ntlm hash已经到达服务器了，最少也要解析一次吧，不然多浪费。

本着不浪费的与原则，我迅速在代码中定位到了该数据包（No 2947）的代码，如图13，而包含hash的包的MessageID抓包结果是3.如图14

图13

图14

是不是以为改为3，就完了？

那你就单纯了

我们应该做的是把’ and GrabMessageID(data)[0:1] == “\x02″删掉。

为什么这么做呢？来来来，协议的东西，还是让微软大大告诉你吧，如图15

图15

大致意思是说，SMB2支持两种Negotiate：Multi-Protocol Negotiate和SMB2-only Negotiate。他们的不同是： Multi-Protocol Negotiate支持多版本SMB，而 SMB2-only Negotiate只支持SMB2。

当使用 Multi-Protocol Negotiate时，包含hash的数据包ID为3；使用 MB2-only Negotiate时， 包含hash的数据包ID为2.

微软在实现在支持多版本的SMB客户端时，首先会用 Multi-Protocol Negotiate进行协商，一旦确定服务器和客户端共同支持的SMB版本（ 假设是SMB2） 后，后续认证才会用 SMB2-only Negotiate。为什么这样做？兼容性  兼容性 兼容性，重要的事情说三遍，愣头青才会上来就用 SMB2-only Negotiate。想想我微软大大也不会这么干。

所以无论是等于2还是等于3，都会有问题产生。删掉便成为我能想到的最好的策略。

我们来看看改后SMBv2的效果，该图16图17：

图16