看雪论坛
发新帖
1

[原创]WannaCry勒索软件中“永恒之蓝”漏洞利用分析

展博 2017-5-19 15:23 2385

WannaCry勒索软件中,利用了NSA泄露工具中的“永恒之蓝”漏洞,关于这个漏洞,之前已经有一些分析,在我看的文章中,http://blogs.360.cn/360safe/2017/04/17/nsa-eternalblue-smb/说得最详细,该文章中针对win7 32位的系统的漏洞触发过程进行了分析。

但是在整个网络上,我没有看到关于64位系统的分析,因此我在该文章的基础上,对win7 64位的触发,以及触发后的shellcode的行为进行了分析整理成此文。

其中若有疏漏,还请大家指教。最后感谢武汉科锐,感谢钱老师的悉心教学,钱老师严谨的治学作风和渊博的知识深深的影响着我,使我受益终身。

 

搭建测试环境

因为样本的原有行为,是随机产生IP地址,并对目标进行发包。这非常不方便我们测试。因此,需要先在特定的位置断下,IP地址改为我们的测试目标,并拍快照记录。

具体步骤如下:

1. 0x00407982处下断,该处为拼接IP字符串,在此处将该字符串修改为自己的测试目标值。

2. 单步(如果不单步可能会因为多线程的原因造成测试不成功,因此推荐单步)至下方的线程创建函数,并在该线程回调处下断点。

 

3. 在上一步的线程回调函数中,有两处关键点,一处为该样本的第一波发包攻击,攻击结果为:在远程电脑上安装一个后门;第二处为第二波发包攻击,攻击结果为:利用第一波攻击安装的后门,在远程电脑上的系统进程中注入一个dll。他们的调用位置如下图所示:

    

漏洞的原理

Srv.sys中的SrvOs2FeaListToNt函数中,会有以下调用关系:

SrvOs2FeaListToNt

   call SrvOs2FeaListSizeToNt

   call SrvOs2FeaToNt

其中在SrvOs2FeaListSizeToNt中因为有一个DWORD*WORD*并赋值的bug,造成在SrvOs2FeaListToNt的一个循环中,SrvOs2FeaToNt被调用的次数会多于预期,而造成SrvOs2FeaToNt中的一个memmove拷贝越界。

   

可以看到,运行到下图时,对大小为0x11000

 

      

通过!pool指令查看:

 

      

而实际运行时:

    

不过,越界覆盖后,最终pool中的地址+0xa8处的数据,会作为一个指针被当作数据接受缓冲区,这是为什么,这其中的原理我没有完全搞明白,还请熟悉的朋友指教。

    

定位第一轮发包的shellcode触发点

尝试定位shellcode,要知道一个前提,这在其它报告中也已经提到,那就是

该样本的第一次发包,会安装一个后门,该后门的实现方式是在srv模块中,挂钩SrvTransaction2DispatchTable表中的一个表项,可以通过命令.

我之后就是利用这一点,来检验自己的测试机是否已经被触发漏洞,并一步步定位到触发点的(见下文分析).

kd> dps srv!SrvTransaction2DispatchTable查看:

挂钩前:

fffff880`0301e760  fffff880`03088780 srv!SrvSmbOpen2

fffff880`0301e768  fffff880`0304fb20 srv!SrvSmbFindFirst2

fffff880`0301e770  fffff880`03085f40 srv!SrvSmbFindNext2

fffff880`0301e778  fffff880`03051650 srv!SrvSmbQueryFsInformation

fffff880`0301e780  fffff880`0307ad20 srv!SrvSmbSetFsInformation

fffff880`0301e788  fffff880`0304f670 srv!SrvSmbQueryPathInformation

fffff880`0301e790  fffff880`03088cb0 srv!SrvSmbSetPathInformation

fffff880`0301e798  fffff880`0304d420 srv!SrvSmbQueryFileInformation

fffff880`0301e7a0  fffff880`0304e080 srv!SrvSmbSetFileInformation

fffff880`0301e7a8  fffff880`0306f660 srv!SrvSmbFsctl

fffff880`0301e7b0  fffff880`03088ae0 srv!SrvSmbIoctl2

fffff880`0301e7b8  fffff880`0306f660 srv!SrvSmbFsctl

fffff880`0301e7c0  fffff880`0306f660 srv!SrvSmbFsctl

fffff880`0301e7c8  fffff880`0307b4f0 srv!SrvSmbCreateDirectory2

fffff880`0301e7d0  fffff880`0306f460 srv!SrvTransactionNotImplemented

fffff880`0301e7d8  fffff880`0306f460 srv!SrvTransactionNotImplemented

 

挂钩后:

fffff880`0301e760  fffff880`03088780 srv!SrvSmbOpen2

fffff880`0301e768  fffff880`0304fb20 srv!SrvSmbFindFirst2

fffff880`0301e770  fffff880`03085f40 srv!SrvSmbFindNext2

fffff880`0301e778  fffff880`03051650 srv!SrvSmbQueryFsInformation

fffff880`0301e780  fffff880`0307ad20 srv!SrvSmbSetFsInformation

fffff880`0301e788  fffff880`0304f670 srv!SrvSmbQueryPathInformation

fffff880`0301e790  fffff880`03088cb0 srv!SrvSmbSetPathInformation

fffff880`0301e798  fffff880`0304d420 srv!SrvSmbQueryFileInformation

fffff880`0301e7a0  fffff880`0304e080 srv!SrvSmbSetFileInformation

fffff880`0301e7a8  fffff880`0306f660 srv!SrvSmbFsctl

fffff880`0301e7b0  fffff880`03088ae0 srv!SrvSmbIoctl2

fffff880`0301e7b8  fffff880`0306f660 srv!SrvSmbFsctl

fffff880`0301e7c0  fffff880`0306f660 srv!SrvSmbFsctl

fffff880`0301e7c8  fffff880`0307b4f0 srv!SrvSmbCreateDirectory2

fffff880`0301e7d0  fffff880`053e2060

fffff880`0301e7d8  fffff880`0306f460 srv!SrvTransactionNotImplemented

可以发现第0xe项会被hook。这个表项的hook是由一段shellcode代码所完成的,具体如何定位到shellcode的入口,见以下分析。

 

因为已知漏洞会在srvnet! SrvNetWskReceiveComplete中完成触发,只是不确认win 7 64位的shellcode写入点是否与前辈win 7 32位地址一样(通常不一样),因此一开始通过下断点并打印内存情况摸索规律:

kd> u

srvnet!SrvNetWskReceiveComplete+0x15:

fffff880`02d3cdc5 488bca          mov     rcx,rdx

fffff880`02d3cdc8 498bf8          mov     rdi,r8

kd> ba e1 srvnet!SrvNetWskReceiveComplete+0x15 "dq r8 r8+0x48;gc"

得到以下结果:

fffffa80`049236b0  00000000`00000003 fffffa80`042fd800

fffffa80`049236c0  fffffa80`042fd800 000059b4`918947fc

fffffa80`049236d0  fffffa80`049237f0 00000000`00000810

fffffa80`049236e0  fffffa80`04923710 fffffa80`00000000

fffffa80`049236f0  00000000`00000438 fffffa80`0568d730

……

fffffa80`04a9b010  00000000`0000ffff 00000000`0000ffff

fffffa80`04a9b020  00000000`00000000 00000000`00000000

fffffa80`04a9b030  00000000`ffdff100 ffdff020`00000000

fffffa80`04a9b040  ffffffff`ffdff100 00000000`10040060

fffffa80`04a9b050  00000000`ffdfef80 ffffffff`ffd00010

 

经过比对,发现以上标红内容特殊,是x86报告所记录的溢出时机断点。因此重启环境,下条件断点:

kd> ba e1 srvnet!SrvNetWskReceiveComplete+0x15 ".if(poi(@r8+0x48) == 0xffffffffffd00010){}.else{gc}"

结合以上所知的,SrvTransaction2DispatchTable会被shellcode挂钩,因此在该表项处下断点:

kd> ba w8 srv!SrvTransaction2DispatchTable+0x8*0xe

经过验证,在以上第一个断点触发后,继续运行,会触发第二个断点:

      

但是,当步入ffffffff`ffd00b77后,栈已经被破坏,难以定位到该段shellcode的触发点。

 

在我所看到的其它的分析文章中,均没有提及具体是个位置转移到shellcode的,因此只有自己定位。

 

考虑到shellcode一般均需要间接call,因此,通过寻找SrvNetWskReceiveComplete中的间接call,并下断点排查。最终,定位到shellcode触发点srvnet!SrvNetCommonReceiveHandler+0xb7

kd> u srvnet!SrvNetCommonReceiveHandler+0xb3

srvnet!SrvNetCommonReceiveHandler+0xb3:

fffff880`028017e3 89742420        mov     dword ptr [rsp+20h],esi

fffff880`028017e7 41ff5208        call    qword ptr [r10+8]

fffff880`028017eb 8be8            mov     ebp,eax

fffff880`028017ed 488b0d1cc90100  mov     rcx,qword ptr [fffff880`0281e110]

fffff880`028017f4 493bcf          cmp     rcx,r15

fffff880`028017f7 740b            je      srvnet!SrvNetCommonReceiveHandler+0xd4 (fffff880`02801804)

fffff880`028017f9 0fba612c09      bt      dword ptr [rcx+2Ch],9

fffff880`028017fe 0f82be840000    jb      srvnet! ?? ::FNODOBFM::`string'+0x1341 (fffff880`02809cc2)

在该处下断点验证:

kd> bp srvnet!SrvNetCommonReceiveHandler+0xb7

确实可以截取到shellcode的进入入口:

 


第一轮shellcode的行为分析

为了测试方便,可以下以下条件断点,这样运行win7测试机器后,断下的地点就是shellcode的入口:

 

ba e1 srvnet!SrvNetWskReceiveComplete+0x15 ".if(poi(@r8+0x48) == 0xffffffffffd00010){bp srvnet!SrvNetCommonReceiveHandler+0xb7;gc}.else{gc}"

 

进入shellcode后,该样本在进行奇怪的jnecall之后(我认为是防止静态分析以及弄乱栈),修改了第0C0000082hMSR

ffffffff`ffd00201 31c0            xor     eax,eax

ffffffff`ffd00203 4090            xchg    eax,eax

ffffffff`ffd00205 7408            je      ffffffff`ffd0020f

ffffffff`ffd0020f e8a7000000      call    ffffffff`ffd002bb

ffffffff`ffd002bb b9820000c0      mov     ecx,0C0000082h

ffffffff`ffd002c0 0f32            rdmsr

ffffffff`ffd002c2 48bbf80fd0ffffffffff mov rbx,0FFFFFFFFFFD00FF8h

ffffffff`ffd002cc 895304          mov     dword ptr [rbx+4],edx

ffffffff`ffd002cf 8903            mov     dword ptr [rbx],eax

ffffffff`ffd002d1 488d050a000000  lea     rax,[ffffffff`ffd002e2]

ffffffff`ffd002d8 4889c2          mov     rdx,rax

ffffffff`ffd002db 48c1ea20        shr     rdx,20h

ffffffff`ffd002df 0f30            wrmsr

ffffffff`ffd002e1 c3              ret

ffffffff`ffd00214 c3              ret

srvnet!SrvNetCommonReceiveHandler+0xbb:

fffff880`02cec7eb 8be8            mov     ebp,eax

这样,利用系统原有的系统调用,样本有机会时系统运行到其准备好的shellcodeffffffff`ffd002e2处,经实测,在该处下断点会系统崩溃,但是在其后1条指令处下断点,则不会崩溃:

kd> bp ffffffff`ffd002e5

此处开始的shellcode,会寻找内存中的PE格式、定位PE文件头、定位服务表项的位置,最终将服务表项进行hook,但是代码流程的细节需要亲自调试才能看清楚。在此我就不截图了。

 

病毒样本的第二轮发包攻击

先在后门处下断点:

kd> dps srv!SrvTransaction2DispatchTable

fffff880`03302760  fffff880`0336c780 srv!SrvSmbOpen2

fffff880`03302768  fffff880`03333b20 srv!SrvSmbFindFirst2

fffff880`03302770  fffff880`03369f40 srv!SrvSmbFindNext2

fffff880`03302778  fffff880`03335650 srv!SrvSmbQueryFsInformation

fffff880`03302780  fffff880`0335ed20 srv!SrvSmbSetFsInformation

fffff880`03302788  fffff880`03333670 srv!SrvSmbQueryPathInformation

fffff880`03302790  fffff880`0336ccb0 srv!SrvSmbSetPathInformation

fffff880`03302798  fffff880`03331420 srv!SrvSmbQueryFileInformation

fffff880`033027a0  fffff880`03332080 srv!SrvSmbSetFileInformation

fffff880`033027a8  fffff880`03353660 srv!SrvSmbFsctl

fffff880`033027b0  fffff880`0336cae0 srv!SrvSmbIoctl2

fffff880`033027b8  fffff880`03353660 srv!SrvSmbFsctl

fffff880`033027c0  fffff880`03353660 srv!SrvSmbFsctl

fffff880`033027c8  fffff880`0335f4f0 srv!SrvSmbCreateDirectory2

fffff880`033027d0  fffffa80`040a3060

fffff880`033027d8  fffff880`03353460 srv!SrvTransactionNotImplemented

 

kd> ba e1 fffffa80`040a3060

  接着,触发第二轮攻击,等待断点触发。以下是行为分析。

 

  shellcode的行为分析

  第二轮发送的包,为SMB2协议的包,其timeout项,被作为控制flag

   

  该域经过计算后,它只有三种值,分别对应了“检查”、“卸载”和“执行程序”,计算公式如下:

   

  域的解析判断部分如下:

     

  在经过ping包后,会执行exec包,执行的程序也包含在(拼接后并解码后的)SMB2包中。其行为为:

1. ntoskrnl的基址:

2. 通过hash,找出关键的系统调用

3. 通过遍历PID,获取EPROCESS,在通过比对进程EPROCESS中进程名的HASH值,获取指定的进程PID

 

 

 

最后,利用apc注入,将自带的dll注入到指定系统进程中,apc注入看雪中已有相关文章。

  

  Apc的回调函数地址是:

  

  也就是刚才拷贝的apc注入的shellcode,用于内存加载dll,并执行其唯一的导出函数PlayGame,该shellcodedll我均已经dump出,大家可以从附件下载:

  

  PlayGame运行后,会释放并执行母体,溢出攻击到此结束,但是悲剧将在新的机器上循环上演。

 


上传的附件:
本主题帖已收到 1 次赞赏,累计¥1.00
最新回复 (8)
jiaojcheng 2017-5-19 17:28
2
精彩!原来是这样触发漏洞的。
OnlyForU 2017-5-19 17:47
3
感谢分享!
冻妖 2017-5-19 19:03
4
感谢分析!
DegerYang 2017-5-19 20:52
5
木志本柯 2017-5-20 21:42
6
好帖
基督山伯爵 2017-5-21 22:38
7
学习
lzldhu 2017-5-23 15:30
8
smb传播是在服务部分的,可以指出下怎么启动调试这个服务吗
Remoter 2017-6-5 15:39
9
楼主可以加我QQ吗?9113979
有事情想找您谈
返回



©2000-2017 看雪学院 | Based on Xiuno BBS | 知道创宇带宽支持 | 微信公众号:ikanxue
Time: 0.016, SQL: 13 / 京ICP备10040895号-17