渗透实验故事:从CSV到CMD到qwerty

最近持续不断的针对性恶意email附件攻击,让我想起了今年1月份在都柏林举办的NCC会议上,笔者曾发表的一篇总结报告。

这场演讲基于一次综合的渗透实验,故事始于笔者对一个老旧容易被忽视的DDE(动态数据交换)进行攻击利用,从一个web应用的Excel导出功能,到用户工作站系统代码。随后我们将看到NTLMv2理论,过渡到域凭证的分析,接着了解hashcat的小bug,以及获悉新脚本“catflap”相关的信息。

从CSV到CMD

DDE是一款来自微软的古老技术,它用于帮助应用程序之间的数据进行传输,是IPC(进程间通信)的一种形式。

Web应用的安全风险的文章,我记得是由James Kettle进行首发的。这种技术貌似是在2014年前的,话说时间过得真快啊。

这里有个小tips,如果某web应用里的有一个导出功能,其中一些来自用户的输入(类似于存储XSS),比如存储下列参数值的应用:

对于导出请求的响应,应用会返回一个某字段带有这个值的文件。打开这个文件时,Excel知道DDE引用可能会出现威胁,于是向用户显示了warning信息。在这个案例里,眼尖的用户或许会看到cmd.exe。但是,正如原文指出的那样,如果用户请求了某个Excel文件,而且该文件还来自于信任域,不应该是很安全的么?而且,我们知道用户即使点击后,也还会出现warning提示。

1.png

2.png

当我们运行“cmd /kipconfig”时,“/k”会让命令窗口持续存在,以便黑客截图。

3.png

事实上,如果没有这个参数,该命令会在最小化窗口运行后直接退出,这对黑客来说似乎是不错的选择。毕竟对于一个黑客来讲,导出CSV比起导出XLS或者XLSX可能会更干净利落。后者需要用户进行对额外的操作才能激活恶意payload,比如点击进入恶意元,这显得更加不便。当然,这些行为也受到Excel版本和配置的影响。

从CMD到qwerty

下面涉及到一个可以进行DDE利用且存在漏洞的内置应用,我在这里会使用比ipconfig和calc更有意思的payload,下面是个简单的例子。

在这里,attacker_IP是属于一个锁定的工作站的,而不是渗透测试PC,但是上面装了Wireshark。受害者的电脑会对其使用net use命令(试验中这台“受害者”是一个测试机,我知道用户名密码)。

4.png

实际情况中,如果受害者访问了存在漏洞的web网站,ISP可能会阻断外出的SMB连接。

这里处理NTLMv2,提示我需要取出以下内容给John:

“NETNTLMv2”是一个常数,此外我可以填写域和用户名字段,因为它们在NTLMv2 exchange里明文有给出,这有助于取出上述混淆的数据包列表(以及下面的变形):

那么其他比特位呢?它们全都与NTLM认证相关,下面一个挑战握手(challenge-handshake)协议:
1. Client > Server (第一种:谈判)

客户端和被请求的服务端的特性。

2. Server > Client (第二种:挑战)

服务端+挑战支持和同意的特性。

3. Client > Server (Type 3, authentication)

关于客户端+响应的更多信息。

NTLM和NTLMv2的本质区别在于如何计算响应,NTLM采用了MD4和DES的弱加密方式(五个空字节),NTLMv2采用了基于HMAC-MD5的加密,这不仅仅只是密码和challenge,也是blob的由来。所以它覆盖了John hash中的“challenge”、“HMAC-MD5”和“blob”,我因此不得不重新创建。另外,我是没有工具的,Responder会让这变得很容易,下面是challenge:

5.png

这里是HMAC-MD5和blob(在“NTLM响应树”里HMAC之后的所有区域):

6.png

为了取得这个blob,你可以从Wireshark复制NTLM响应的比特流,去除最开始的16比特位(HMAC的值)就是了。Blob就像这样0×01010000***,现在我们有了:

上面就是最难的部分了?当然不是啦。

让我们开始破解

下面是John的响应包(我知道真实密码),经过适当修改hash格式,hashcat看起来有点问题:

7.png

大家看见skippingline错误没,这是hashcat出错了,但是oclhashcat 不会,为此我特地实验出了报告。Hashcat在blob长度超过224比特位后会出现问题。但是因为某些原因,它被认为是新特性而不是bug。不管怎样,我们回到John上来,记得格式是:

把hashcat格式改下:

需要公正的说,这表最初是基于john-1.7.8-jumbo-5,支持的hash或者hash格式的改变,可能在本文里不会反应出来。我这里用的是最新版本,不管怎样,结果好就意味着一切都好:

8.png

catflap

为了验证我发现的bug,我写了一个脚本(我称之为catflap),它的问世有两个目的:

1. 从Wireshark数据包文件里提取hashcat对NTLMv2所需求的东西。

2.它允许你创建一个更现实的测试用例,来检查你的NTLMv2 cracker是否有效。对于catflap来说,它会从普通文件(或者数据包文件)里接受一个普通的hash格式。Catflap会基于你提供的密码,重新计算NTLMv2的响应。这意味着所有测试hash里其他的变量(sername,domain, challenge,blob)将与你捕获的exchange相同,但是在这个测试案例里你知道密码,而且实验效果会比标准hash案例更好。当然,你也可以尝试其他输入,这里我是为了测试blob来发现bug。

使用方法是很简单的:

下面展示了catflap更改HMAC响应,并把密码设为“password”。

9.png

接着你可以运行你选择的cracker编辑hash,确保其提取的是“password”。如果出错了,提取结果会不一样。脚本地址在这里

输入验证和封锁

在我于web应用中找到一个Excel导出函数时,DDE的利用一般都会有效,因为用来启动payload的字符不是我们常用的。它不是一个主流的攻击向量(甚至是容易被忽略的那种),所以其值得进行检测。

那么我们应该如何修补呢?原文表示,最好的办法是在“=”前加双引号。上个月在公司集体讨论时,我曾扯到这个话题。同事Cara Marie指出,‘+’ 和‘-’也可以用来启用命令。感谢Michael Roberts(另一位NCC的小伙伴),Michael表示还可以在格式里使用“@”:

或者用引号包裹payload:

本文在上月更新了两次,除了对引号的使用外,其余内容大致没变。所以,据我所知有两个独立研究小组想出办法绕过了原来的限制。这里关键点在于,黑名单方法常常失败,我们需要尽可能地进行白名单字符验证。比如,如果某个字段是电话号码,“=”和“@”就不应该出现,但“+”是合理的(国际拨号前缀),但是之后却不应该出现任何非数字的字符。另外,我们还可以限制该字段的长度,有了这些限制,我们完全没必要创建维护一个黑名单。

测试

本文实验事件设定:存在一个web应用并允许进行导出,结合DDE特性能让渗透人员通过email执行恶意附件。这个原因是DDE的payload不是宏或者使用宏的文件,会绕过让宏文件停止运行的边界内容检查。

[via@Freebuf-dawner]