永恒之蓝漏洞分析

一、 EternalBlue简介

EternalBlue 漏洞利用工具于 2017 年 4 月 14 日被“影子经纪人”小组在他们的第五次泄密“迷失在翻译中”泄露。 泄漏包括许多利用工具，如永恒之蓝，它们基于 SMB 协议的 Windows 实现中的多个漏洞。

EternalBlue 适用于 Windows 8 之前的所有 Windows 版本。这些版本包含允许空会话的进程间通信共享 (IPC$)。 这意味着连接是通过匿名登录建立的，默认情况下默认情况下允许空会话。另外，空会话允许客户端向服务器发送不同的命令。

二、 测试环境及漏洞利用

2.1 测试环境

攻击机：192.168.19.138（kali 2021.2 x64位安装Metaploit工具）

靶机： 192.168.19.141（win7 x86 专业版,未打永恒之蓝补丁且防火墙关闭）

Wireshark版本:3.4.8

2.1 漏洞利用

由于Kali的msf只有64位的，所以攻击x86的机器需手动下载对应的攻击模块。

下载地址https://github.com/ElevenPaths/Eternalblue-Doublepulsar-Metasploit/

下载的文件夹改名为Eternalblue-Doublepulsar-metasploit 放在/root下，

然后将下载的eternalblue_doublepulsar.rb，拷贝到
/usr/share/metasploit-framework/modules/exploits/windows/smb目录下。

最后执行命令msf >reload_all更新攻击模块。

二、 漏洞原理分析

此次研究永恒之蓝漏洞，是通过提出问题并带着疑问去寻找答案的一个分析过程。

问题 1：shellcode如何被执行 ？

通过查阅网上资料以及调试分析，发现SrvTransaction2DispatchTable+
038被替换，对其下一个硬件写入断点，断下来可以看到此处的地址明显可疑

上网查找这段地址的作用，发现其是系统的预留出来的一块内存，保存一些系统配置信息，而且在win10后，这块地址是不能被访问的。

使用命令db 0xffdf0000 Lffff 查看这块内存，猜测shellcode很有可能是从0xffdff1f1开始的。因此在0xffdff1f1下一个硬件执行断点，找到它什么时候被执行的。

成功断下来后查看栈区，猜测栈顶的a3ed4290很可能就是转移到shellcode的call指令的返回地址。

通过模块以及其base，最后确定a3ed4290位于函数SrvNetCommonReceiveHandler的0x96处。查看堆栈后，发现几处比较可疑的传入参数。

因此，对照IDA进行分析， 下图为SrvNetCommonReceiveHandler+0x96，可以确定此处是shellcode启动的地方，第一参数v11是获取到结构体srvnet_recv 的0x16c偏移处的信息，回推得到srvnet_recv的地址为0xffdff020。

再通过IDA静态分析发现SrvNetCommonReceiveHandler中的srvnet_recv结构体最初是由SrvNetWskReceiveComplete函数的第三参数IRPContext的0x24处的结构体（Connection）传入到SrvNetIndicateData函数最后再到SrvNetCommonReceiveHandler。也就是说，SrvNetWskReceiveComplete中的connrection信息被恶意修改。

最后，IDA中SrvNetCommonReceiveHandler+0x96处和0xffdff020的内存信息做了一个比对，验证了上述分析。

找到shellcode如何被执行起来后，下一个问题就是结构体connrection的信息什么时候被修改的。

问题 2：SrvNetWskReceiveComplete中的结构体connrection何时被修改
？

在SrvNetWskReceiveComplete函数中下一个条件断点：

从堆栈中可以发现问题貌似出现在srv.sys模块中，并且是SrvOs2FeaToNt中的memmove。因此，在SrvOs2FeaToNt+0x4d的地方下条件断点去查看memmove的情况。

第一次拷贝，长度为0xf383，下断点查看内存池信息，从内存池可以看出，本次拷贝正常并没有异常情况。

第二次拷贝，长度为0xa8，通过下断点查看内存池信息。从下图也可以看出，本次拷贝存在异常，拷贝横跨srv.sys,srvnet.sys两个模块，memmove将向865f1ff9开始的0xa8 个字节里拷贝，即结束地址为865f20a1。这已经越过了分配的地址865f2000，从而产生越界拷贝。

下图可以确定结构体connection中的信息就是在srv模块在进行拷贝时，发生越界导致将其覆盖。

问题 3：为何会发生越界拷贝 ？

此处涉及到EternalBlue所用的到第一个漏洞CVE-2017-0144，核心原理，srv!SrvOs2FeaListToNt在将FEA从Os2结构转换为NT结构过程中，错误使用强转导致缓冲区溢出。

SrvOs2FeaListSizeToNt在计算NtFeaList Size时，错误使用WORD进行强制类型转换，导致换算后的Fea List的size大于真正的Fea List size。

Windbg进行验证，转换之前Fea List的大小为0x10000,转化之后变成0x1ff5d

正常在计算Fea List size 应该是0xff5d

可以错误使用word强转导致，size最后是由si寄存器交给eax,因此它并不能覆盖eax寄存器中ah中的值，导致最后size多出0x1000。

另外，eax最初就是SrvOs2FeaListSizeToNt的参数赋值的，所以想要成功触发漏洞，前提需要构造一个size大于0x10000的Fea List。

问题 4：如何构造size大于0x10000的Fea
List ？

通过查阅微软文档，了解到Fea List只存在于SMB_COM_TRANSACTION2的子命令中,但是通过下图发现SMB_COM_TRANSACTION2(SMB_COM_TRANSACTION2_SECONDARY)的成员TotalDataCount（数据包总长度）是USHOER（word）类型的，也就是发送的数据包最大不能超过0xFFFF，而SMB_COM_NT_TRANSACT（SMB_COM_NT_TRANSACT_SECONDARY）下的TotalDataCount是ULONG（dword）类型的。此时就可以利用SMB_COM_NT_TRANSACT发送一个size大于0x10000的SMB_COM_TRANSACTION2，从而可以产生拷贝溢出。

构造原理：

如果通过SMB_COM_TRANSACTION2 /SMB_COM_NT_TRANSACT 向服务器发送的数据超过会话建立期间建立的 MaxBufferSize，或者 total_data_to_send 大于transmitted_data，则客户端必须使用1个或者多个SMB_COM_TRANSACTION2_SECONDARY/SMB_COM_NT_TRANSACT_SECONDARY去向服务器发送余下的数据。另外，SMB_COM_TRANSACTION2_SECONDARY/SMB_COM_NT_TRANSACT_SECONDARY命令的TID,UID,PID,MID必须与他们的SMB_COM_TRANSACTION2 /SMB_COM_NT_TRANSACT保持一致。

由于在服务器中没有函数去判断transaction命令类型（SMB_COM_TRANSACTION2 或
SMB_COM_NT_TRANSACT），仅仅通过客户端发送过来的最后一个SMB_COM_TRANSACTION2_SECONDARY或SMB_COM_NT_TRANSACT_SECONDARY的类型，在根据其TID,UID,PID,MID一致就草率确定其命令类型。

因此，可以发送SMB_COM_NT_TRANSACT 后紧跟 SMB_COM_TRANSACTION2_SECONDARY的transaction就可以构造出一个size大于0x10000的SMB_COM_TRANSACTION2。

问题 5：如何进行内存布局
可以在发生越界拷贝时srv buffer恰好将srvnet buf覆盖？

通过调试windows的poc可以确定其大致流程：

第一步，采用heap spray技术，在Non-paged pool创建多个srvnet buf的缓冲区。

第二步，构建一个大小和srvnet buf相近的srv buf（紧跟在之前创建的srvnet buf后）

第三步，继续创建多个srvnet buf的缓冲区,尽可能将内存池占满。

第四步，断开SMB_COM_SESSION_SETUP_ANDX，在Non-paged
pool中出现一个hole。此时发送最后一个带有漏洞的SMB_COM_TRANSACTION2_SECONDARY，在触发拷贝溢出时恰好可以将他后面的第一个srvnet buf覆盖。

注意：在Heap Spray时，为了提高成功覆盖的几率
申请的srvnet
buf要尽可能的大（一般要大于1M）,Windows堆内存布局一般如下图所示，在申请堆内存时，系统会优先分配在低地址大小适合的内存块，EternalBlue利用这一特性，在Non-paged pool中申请多个大内存块，并且在靠后的位置构造溢出，这种方式会极大的提高执行shellcode的成功率。

问题 6：如何去构建一个大小由自己的控制的srv buf ？

这里就用到本次攻击涉及到的最后一个漏洞，存在于SMB_COM_SESSION_SETUP_ANDX中。此命令在向服务器发起请求时，共有以下两种请求格式。

具体的请求格式是由SMB_COM_SESSION_SETUP_ANDX中的WordCount去决定的。直接引用网上逆向简化后的一段代码:”如下所示：如果发送的代码中WordConut为12，包含CAP_EXTENDED_SECURITY字段，但却没有FLAGS2_EXTENDED_SECURITY字段，将会导致服务器将以处理13类型请求的方式去处理类型12的请求包，从而进入错误的函数GetNtSecurityParameters流程中。”

由于错误调用GetNtSecurityParameters去计算SMB_DATA,最终导致BlockingSessionSetupAndX错误地计算 ByteCount，从而导致在Non-paged pool中分配由攻击者控制大小的srv buf（大于数据包数据）。

问题 7：为什么一定要去覆盖srv buf ？

srvnet buffer包含两个重要的结构：

1.一个指向结构体srvnet_recv的指针，通过覆盖它可以将其指向一个伪造的结构，从而实现后续的代码执行。

2.一个接受MDL的缓冲区，通过覆盖它可以保证将后续发送的伪造结构及shellcode写到指定的区域。

另外，当客户端断开连接时，服务端会自动调用srvnet buf，从而会触发srvnet_recv中的shellcode。

至此，分析结束。

整体流程(引用)

通过SMB_COM_NT_TRANSACT发送一段FEA LIST长度满足0x10000的数据包

发送后续的SMB_COM_TRANSACTION2_SECONDARY，这将导致smb服务将SMB_COM_NT_TRANSACT当做SMB_COM_TRANSACTION2处理，但是最后一个SMB_COM_TRANSACTION2_SECONDARY留置最后。

通过smb 2协议进行srvnet对象的spray

通过SMB_COM_SESSION_SETUP_ANDX漏洞在srvnet对象之后分配一段大小和srv对象大小几乎一致的pool内存

通过smb 2协议继续进行srvnet对象的spray，以确保srvnet位于srv对象之后

断开连接导致第4步开辟的pool内存释放，生成一个hole

发送最后一个SMB_COM_TRANSACTION2_SECONDARY，由于大小一致，该数据包会填补生成的hole，并触发漏洞导致之后的srvnet对象buffer中的MDL和指针被修改，此时后续发送的数据将拷贝到ffdff000的位置。

断开所有连接，触发srvnet_recv指向的shellcode执行

参考：

https://research.checkpoint.com/2017/eternalblue-everything-know/

https://www.sohu.com/a/146947552_354899

https://blogs.360.cn/post/nsa-eternalblue-smb.html

相关推荐: Vulnerability Guide - 命令执行漏洞从入门到放弃（一）

0x0a、基础 一、危害：控制参数，进行系统命令执行 二、原因：在程序工作的时候可能会调用一些系统执行命令函数，将我们的恶意代码输入到函数中，就造成了命令执行漏洞 三、常见的php命令执行函数 四、命令执行可能存在的地方 web源码、中间件等等 五、防御 敏感…