安全路透社
当前位置:安全路透社 > 网络转载 > 正文

狄仁杰探案之“永恒之蓝”

* 本文作者:兰云科技银河实验室

本故事纯属虚构,如有雷同,实属巧合。

唐武周年间,利用了永恒之蓝漏洞(CVE-2017-0144)的WannaCry 蠕虫爆发。朝野之间,电脑屏幕尽呈一片血色,刚刚宁定不久的武周天下,又面临一场浩劫。狄仁杰,元芳,狄春三人奉旨研究此漏洞,寻求破解之计。

深夜,狄公交给管家狄春一手稿,命其按此准备。但见手稿上写道:

1) 靶机Win 7 SP1x86 虚拟机一台,无补丁

2) 攻击机器一台,虚拟机上安装NSA的EternalBlue 复现工具,详参http://www.freebuf.com/sectool/132076.html

3) Windbg 远程调试环境,

4) IDA

不出半个时辰,管家狄春已准备妥当。狄公唤上元芳一同开始查看。

狄公一如既往问道:“元芳,你怎么看。”

“大人,卑职查看发现,所有感染的电脑 srv!SrvTransaction2DispatchTable的0x0e项均被替换。我们只需顺着这个线索往回顺藤摸瓜,定能找到真相。” 元芳答道。

狄公赞许的点了点头,不错,一般来说,漏洞分析,第一步我们只需找到控制是如何转移的。第二步,便是往回顺藤摸瓜,看数据是如何被损坏,而导致控制转移的。狄公随即在windbg中敲下了如下命令。

111.png

运行fb.py,很快便见windbg断下在如下地址:

112.png

         狄公似乎想到了什么,紧接着

113.png

元芳道, 果然是这里,将SrvTransaction2DispatchTable+ 0×38 ,也便是0xe(0xe *4 = 0×38) 项,进行了替换。

狄仁杰道,然而这里并非凶案第一现场,这段代码应该是shellcode,我们尚需弄清控制是如何转移到这shellcode的。

元芳用.writemem命令将这段shellcode dump 了出来,仔细查看。”shellcode入口应该便是这里。” 元芳指着这段代码道。

114.png

狄仁杰不仅不慢重新启动调试,敲下如下命令。

115.png

“可是大人,这地址 –每次调试,不会变化吗?” 元芳有些疑惑道。

狄公笑笑,那就让我们来试试运气吧… …

“大人你看,真的断下来了。” 元芳看见断点真的命中了。

狄公捋了下胡子,微微一笑,看来我们的运气不错啊,他凝视了一下屏幕继续敲下

118.png

狄公道,栈顶的91a18290   很可能就是转移到shellcode的call指令的返回地址。

狄公随即打开Disassembly窗口

200.png

狄公道,应该就是这条call    dword ptr [eax+4]  指令,将控制转移到了shellcode,元芳你看,

222.png

元芳道:”大人,这第一步我们算是完成了,我们找到了控制是如何转移的。如果卑职没有猜错的话,ffdff190开始的数据,除了ffdff194,其余的地址都为0,像是伪造出来的。”

狄公点点头,我们现在需要做的就是,看看数据是从哪里来的,以及是如何被损坏的。

狄公查看了调用堆栈:

224.png

“是用IDA 分析代码的时候了。”狄公用 IDA 加载了 srvnet.sys文件,开始静态分析。

约莫一柱香的功夫,狄公缓缓说道,元芳啊,你看,数据可以追溯回到SrvNetWskReceiveComplete 这个函数。这个函数是个IRP的完成例程。这个函数的第三个参数Context是IRP的Context。而Context 偏移0×24 处,存放了一个指针,里面存放了连接信息,我们姑且称其为Connection吧。这个Connection 会被作为第一个参数,传入SrvNetIndicateData(),而紧接着又会被作为第一个参数传入到 SrvNetCommonReceiveHandler。也就是说,Contex 由SrvnetAllocateBuffer分配,类型为SRVNET_BUFFFER 定义见下图

225.png

该结构的0×24处的Connection被损坏了,于是便有了我们看到的一幕。你看,在调用SrvNetIndicateData()时,代码如下:

226.png

而我在查看堆栈发现了

227.png

于是我可以断定,

228.png

时,edi的值为ffdff020  压入了栈中。  于是我利用如下断点,重新调试一下,

SrvNetWskReceiveComplete+0×14

229.png

我发现esi,也就是CONTEXT 的地址为0x86acd010, 而其偏移0×24, 也就是地址0x86acd034的地方,被损坏,变成了0x ffdff020。我们不妨再来试试手气,说不定,这个0x86acd034地址每次也不变呢。

狄公又重启了调试,设置如下断点:

234.png

断点再次命中。狄公再次查看堆栈

235.png

狄公邹了下眉头,多年的办案经验,让他想到了问题似乎出在了srv.sys!SrvOs2FeaToNt 函数的memmove上:

3333.png

如果往常一样,他在这个函数上设置了如下断点,打印出每次调用的参数:

2344.png

打印出信息如下两条引起了狄公的注意:

23467.png

利用!pool命令验算是否越界,第一条,并没有问题。而第二条

9999.png

这个memmove调用将向86accff9  开始的0xa8 个字节里拷贝,即结束地址为86acd0a1。这已经越过了分配的地址 86acd000

元芳见此,立刻说道,大人我明白了,原来是memmove拷贝越界了导致内存损坏。

狄公却摆手示意:“不,目前我们还不能解释为什么拷贝会越界。元芳,这个看来就交给你了”。

元芳会意,即刻开始分析并调试SrvOs2FeaToNt 和调用函数SrvOs2FeaListToNt 的代码。一个多时辰后,元芳突然兴奋的说道:“大人,我找道了。”

狄公微微一笑,不妨说来听听。

元芳道:“是,大人。卑职看来,这段代码其实是用来将OS/2 的FEA转化成NT的扩展属性EA。而问题就出现在SrvOs2FeaListToNt这厮身上,这厮会修改FEALIST的大小。而问题恰恰出现在了这里。

33335.png

这里 v1 存放的是FEALIST 的大小,是个DWORD,本意是根据v3和v1的差值缩小FEALIST的大小。可是这里却用了WORD来计算。

我调试时发现,

66777.png

77899.png

这里,本来试图把FEALIST的大小从00010000   缩小到0000ff5d

然而,用了WORD来计算,

结果反倒变成了 0x1ff5d,一下变大了。

556767.png

如此一来,下面也都错了。其实破解之策异常简单,仅需改成

222222.png

即可。

狄公点点头,不错,元芳,一语中的啊。

元芳道,可是卑职尚有一事不明,

56456.png

v1 如果是WORD指针,还尚可理解。 可v1这里是DWORD指针,这行代码,转化成WORD再计算,甚是怪异,莫非作者喝醉了不成?

狄公微微一笑:“问得好啊,我其实也曾有过如此疑问。细细想来,如果作者没有喝醉,那还有一种可能… …”

“哦,还望大人明示。“ 元芳有些不解。

狄公说道,还有一种可能,便是代码中可能使用了StoreUnsignedShort 这样的宏来赋值,这样一来,错误便更加隐蔽而不易被人察觉。

“原来是这样!”元芳道,“这下卑职彻底明白了。”

狄公道:“元芳啊,分析漏洞不应放过每个细节。我且问你,“你有没有想过 0xffdff1f1地址中存放的shellcode是如何拷贝进去的啊?”

“这个。。。“元芳竟然一时语塞,”待卑职调试一下。“

9999999.png

元芳不由大吃一惊,大人,怎么会这样,好象—竟是TCP/IP协议栈拷贝进去的。

狄公微微一笑道:”你恰恰忽略了一点,在memmove拷贝的时候,覆盖掉的不仅仅是Context->Connection。他同时也覆盖了相邻SRVNET_BUFFER.MDL的内容(偏移0x2c起),从而使得TCP/IP协议栈拷贝到了ffdff1f1内存中。在x86上,ffdf1000开始到ffffffff地址,都是保留给HAL用的。你看下下面这张图便明白了。”

890.png

狄公道,我们可以复命了。

朝堂之上,狄公娓娓道来,整个攻击攻错大致是这样的。首先,歹人发送SMB 的 Session Setup AndX (0×73) 命令,跟据其响应中的 Native OS 获取 目标操作系统的版本信息。有图为证:

7777777777777777.png

紧接着,歹人的计划紧锣密鼓的展开。他利用了SMB.SMB_COM_NT_TRANSACT SMB_COM_TRANSACTION2_SECONDARY 在内存中精心布局,形成了一些连续的SRVNET_BUFFER内存区域。然后他关闭了一个链接,从而释放掉一个SRVNET_BUFFER,而这个释放掉的SRVNET_BUFFER空洞恰恰又会被FeaList 分配内存时重用(有图为证)。而SrvOs2FeaListToNt 中的Bug又导致了拷贝时越界,直接覆盖掉了其后的SRVNET_BUFFER,修改了MDL。于是后面的发送的数据就被错误的拷贝到了MDL 指定的内存中,也就是HAL保留的内存。而这时,歹人开始了致命的以一击,发送最后一个SMB_COM_TRANSACTION2_SECONDARY 分片,从而触发了控制转移。

334434444.png

奏毕,满朝皆惊。曾泰赞曰,大人真乃神人也!

退朝后,狄公却仍是心事重重,元芳便上前问道,大人似乎还有心事?

狄公叹道:“这永恒之蓝,犹如浩瀚的大海,深藏着诡谲与恐惧,吞噬着无辜和善良。虽然此案已结,可我始终却还有种不祥的预感,歹人不会就此罢休,总觉得似乎还有事情发生”。

不出所料,数日后,殿上急召狄仁杰觐见。  狄公缓缓叹道,该来的总会来的,不会是Samba服务真的也出问题了吧。但见一个微胖的身影在暮色中匆匆向大殿走去… …

参考文献

https://packetstormsecurity.com/files/142548/MS17-010-EternalBlue-SMB-Remote-Windows-Kernel-Pool-Corruption.html

http://blogs.360.cn/360safe/2017/04/17/nsa-eternalblue-smb/

https://www.exploit-db.com/exploits/42031/

 * 本文作者:兰云科技银河实验室

未经允许不得转载:安全路透社 » 狄仁杰探案之“永恒之蓝”

赞 (0)
分享到:更多 ()

评论 0

评论前必须登录!

登陆 注册