永恒之蓝漏洞简单分析

目录

前言

Shadow Brokers Group

测试环境

漏洞分析

漏洞1(CVE-2017-0144)

漏洞2 - SMB transactions

FEA_LIST格式转换

小结

漏洞3 - 构造内存布局

srvnet对象spray

srv对象spray

Exploit利用过程小结

漏洞复现

参考链接

---

前言

自从上次快把HEVD栈溢出的博客写完，不小心手贱点关了，结果菜鸡的我一顿操作都没找回来，就不想写博客了(后来大佬说使用windbg附加，找到那块内存，dump出来就可以还原了，自己还是太年轻呀)。隔了一个月没写博客，就感觉很多东西记不住，还是简单写写吧。

2017年，网络安全界充斥着有关声名狼藉的WannaCry勒索软件攻击的新闻。这项活动是在Shadow Brokers黑客组织披露了一系列国家安全局（NSA）漏洞后不久开始的。利用全球范围内未打补丁的系统，使用名为“ EternalBlue”的漏洞的WannaCry攻击遍及150个国家。自2016年以来，臭名昭著的Shadow Brokers黑客组织一直活跃，并负责泄漏一些NSA漏洞，零时差和黑客工具。根据Wikipedia的报道，影子经纪人组织迄今已报告了五次泄漏。第五次泄漏发生在2017年4月14日，被证明是最具破坏性的。当天，Microsoft发布了一篇博客文章，概述了可用的补丁程序，这些补丁程序已解决了Shadow Brokers泄露的漏洞。漏洞发生前一个月（2017年3月14日），Microsoft已发布安全公告MS17-010，该公告解决了一些未修补的漏洞，包括“ EternalBlue”漏洞所利用的漏洞。但是，许多用户未应用该补丁，并且在2017年5月12日遭到了历史上最大的勒索软件攻击– WannaCry攻击。WannaCry成功感染了150多个国家的23万多台计算机后，引起了全球关注。这次袭击的主要受害者是全球知名的组织，包括医院和电信，天然气，电力和其他公用事业提供商。WannaCry爆发后不久，发生了其他严重的攻击，这些攻击也被发现使用了EternalBlue以及来自同一NSA泄漏的其他漏洞利用和黑客工具。

Shadow Brokers Group

Shadow Brokers组织以NSA泄漏而闻名，其中包含漏洞利用，零时差和黑客工具。该小组的第一个已知泄漏发生在2016年8月。在最近一次泄漏之后，Shadow Brokers组改变了其业务模式并开始进行付费订阅。在该组织造成的所有公开泄漏中，第五次泄漏-包括许多网络攻击中使用的EternalBlue漏洞-创造了历史。

EternalBlue（永恒之蓝）据称是方程式组织在其漏洞利用框架中一个针对SMB服务进行攻击的模块，由于其涉及漏洞的影响广泛性及利用稳定性，在被公开以后为破坏性巨大的勒索蠕虫WannaCry所用而名噪一时。

测试环境

对于EternalBlue的分析是在一个相对简单的环境中进行的，使用Win7 32位系统进行调试，当然得没有安装EternalBlue相关的补丁，srv.sys文件的版本为6.1.7601.17514，srvnet.sys的版本为 6.1.7601.17514。

漏洞分析

EternalBlue利用Windows SMB中的一个远程执行代码漏洞。它利用了三个与SMB相关的漏洞以及一个ASLR绕过技术。它使用前两个漏洞来执行内核NonPagedPool缓冲区溢出，并使用第三个漏洞来设置内核池修饰，以协调另一个已知内核结构上的缓冲区覆盖。此溢出以及ASLR旁路有助于将Shellcode放置在预定义的可执行地址上。这使攻击者可以在易受攻击的受害者的计算机上启动远程代码执行。

EternalBlue通过在多个TCP连接上发送精心制作的SMB数据包来利用受害计算机的易受攻击的SMB。在第一个TCP连接中，它通过IPC $共享上的匿名登录打开一个空会话。如果受害者计算机的响应为STATUS_SUCCESS，则漏洞利用程序通过发送SMB NT Trans请求（其“ TotalDataCount” DWORD字段设置为66512）来开始其操作。NTTrans对应于SMB_COM_NT_TRANSACT事务子协议，并且是六种事务类型之一可用的子协议。

总结来说，EternalBlue达到其攻击目的事实上利用了3个独立的漏洞：第一个也就是CVE-2017-0144被用于引发越界内存写；第二个漏洞则用于绕过内存写的长度限制；第三个漏洞被用于攻击数据的内存布局。

漏洞1(CVE-2017-0144)

入口处理函数为SrvSmbOpen2，其中漏洞出现在函数SrvOs2FeaListToNt中，用IDA打开srv.sys进行分析：

如下所示为对应的漏洞函数SrvOs2FeaListToNt，当最后一个Trans2请求数据包中接收到整个结构，NtFea转换就会在srv!SrvOs2FeaListToNt函数中进行。SrvOs2FeaListToNt调用srv!SrvOs2FeaListSizeToNt来解析每个结构并计算新结构所需的总大小。它不会验证源列表的内容，但会检查每个FEA结构以确保其长度不超出最初在SizeOfListInBytes字段中定义的长度范围。

再来详细看看srv!SrvOs2FeaListSizeToNt函数，该函数会计算对应的FEA LIST的长度并随后对长度进行更新，该长度一开始为DWORD类型的，之后的长度更新代码中计算出的size拷贝回去的时候是按WORD进行的拷贝，此时只要原变量a中的初始值大于0xFFFF，即为0x10000+，该函数的计算结果就会增大。

上面是不是不好理解，举个例子，例如解析606个FEA结构后，解析的结构的总偏移长度变为0xff59字节。由于最后一个FEA的大小为0xad，相加之后超出SizeOfListInBytes(假设定义为0xFFFF)。因此，如下所示，它退出WHILE循环，丢弃第607条记录以及其余附加的垃圾数据，并最终以错误的形式更新Os2FeaList-> SizeOfListInBytes值，如图14所示。

反汇编看看，下面的赋值由esi变成了si，此时如果eax高位中的数据不为零，那么eax就会变大，则将返回的超长的size。

然后校正后的大小在DWORD变量的LOWORD字节中更新，从而增加了它的值而不是减小了它。SrvOs2FeaListToNt获取返回的最终计算得出的NtFea列表和更新的Os2Fea列表的大小，并在NonPagedPool中为NtFea列表分配内存。对于每个要转换的FEA记录，它调用srv!SrvOs2FeaToNt使用memmove()复制内容，该过程一直持续到最后一条FEA记录的末尾。

由于SMB会等待最后一个**SECOND数据包到来才生成最后的transaction，因此EternalBlue可以在此期间发包对目标设备的内存进行部署，之后再发送最后一个数据包从而触发漏洞越界写。那么就可以在等待发送最后一个数据包时，通过使用一些内核池修饰，可以确保在转换的NtFea列表分配结束之后立即放置srvnet块。因此，在溢出之后，预期将覆盖srvnet块的两个重要字段，从而允许ASLR绕过并最终使EIP指向shellcode。

调试图

EternalBlue打开多个新的TCP连接以发送SMBv2数据包，这使srvnet.sys在NonPagedPool池中分配SRVNET_BUFFER_HDR块。发送多个数据包以填充NonPagedPool中的碎片空间，从而增加在分配到所需位置后发送修饰数据包的机会。下面显示了一个覆盖的SRVNet块。

       调试图

SRVNET_BUFFER_HDR结构中覆盖的字段是：

pSrvNetWskStruct：位于距标头开始的偏移量0x58字节处，它指向SRVNetWskStruct对象，该对象的类型为SRVNET_RECV。

pMdl1：位于偏移量0x38处，这是指向MDL的指针。操作系统使用内存描述符列表（MDL）来描述虚拟内存缓冲区的物理页面布局。

这两个字段都被覆盖到相同的虚拟地址0xfffdf000，这是32位Windows 7中的HAL堆地址。该ASLR绕过技巧可确保将要接收的下一个SMB2标头放置在静态定义的HAL堆地址中，而不是通常的NonPagedPool中。因此，从所有NumGrooms连接中，只有SRVNet块被覆盖的分配才导致HAL堆中的分配。然后，将包含伪造的SRVNET_RECV结构并附加了shellcode的有效负载发送，并将SRVNET_RECV-> HandlerFunction字段值设置为shellcode地址。发送有效负载后，所有NumGrooms连接都立即关闭，从而导致目标处理程序函数被调用并触发shellcode执行。

调试图

 

然后，受害者的计算机将Trans2响应数据包发送到服务器，该数据包具有SrvOs2FeaListToNt函数返回的NT状态值，即0xC000000D，表示覆盖成功。

漏洞2 - SMB transactions

根据MSDN， Transaction SMB命令是通用操作。它们提供扩展子命令集的传输，这些子命令又允许CIFS客户端访问服务器上的高级功能。CIFS支持三种不同的事务消息(SMB的子命令中存在一个名为TRANSACTION系列的命令)，它们的构造仅稍有不同：

SMB_COM_TRANSACTION（或Trans、用于和邮槽、命名管道进行通信）

SMB_COM_TRANSACTION2（或Trans2、 用于打开或创建一个共享文件或文件夹，设置它们的扩展属性）

SMB_COM_NT_TRANSACT（或NT Trans、用于打开或创建一个文件或文件夹，并应用扩展属性EA或安全描述符SD）

       SMB_COM_NT_TRANSACT本身是不支持FEA LIST的，产生漏洞的为SMB_COM_TRANSACTION2命令。对于TRANSACTION系列的命令如果发送的长度过大，SMB会将该请求包拆分成**Second的形式进行发送，如下所示为其相应的**Second系列的命令：

SMB_COM_TRANSACTION

SMB_COM_TRANSACTION_SECONDARY

SMB_COM_TRANSACTION2

SMB_COM_TRANSACTION2_SECONDARY

SMB_COM_NT_TRANSACT

SMB_COM_NT_TRANSACT_SECONDARY

服务端根据SMB请求头部的TIP，PID，UID，MID确定哪一个**Second属于对应的transtion，而服务端根据最后一个**Second确定对应的transtion类型，即如果最后一个**Second为SMB_COM_TRANSACTION2_SECONDARY，就按SMB_COM_TRANSACTION2来处理。

在第一个NT Trans请求之后，漏洞利用程序会发送多个Trans2 Secondary（SMB_COM_TRANSACTION2_SECONDARY）请求，并将“ TotalDataCount”字字段设置为4096。当消息有效负载很大且必须在多个SMB事务之间拆分时，使用“_SECONDARY”子命令， 下面是我测试时截的图：

在理想情况下，如果payload不能容纳在一个SMB_COM_NT_TRANSACT数据包中，则其余的payload将通过SMB_COM_NT_TRANSACT_SECONDARY数据包发送。同样，当主请求数据包的类型为SMB_COM_TRANSACTION2时，将使用SMB_COM_TRANSACTION2_SECONDARY请求。EternalBlue使用错误的数据包顺序（SMB_COM_NT_TRANSACT -> SMB_COM_TRANSACTION2_SECONDARY）来利用srv.sys中的解析错误（漏洞2）。

为什么可以使用错误的数据包顺序？而不是一次发送完呢？因为先发送 Trans 类型的数据包，由于大小total data count字段 的值和data count字段的值不一致，SrvSmbTransaction 函数认为这个请求包含多个数据包所以会等待后续的数据包，而不是调用ExecuteTransaction 处理这次请求。

由于srv.sys按照序列的最后一个数据包中设置的SMB命令值错误地映射了接收到的多个事务数据包类型，因此存在此错误。因此，即使使用NT Trans请求启动事务，最后，整个事务也将映射为Trans2请求类型，因为这是在最后一个数据包中设置的值(上面说过了)。此外，如果比较这两种结构，我们会注意到“ TotalDataCount”值字段在NT Trans中为DWORD，在Trans2请求中为WORD。因此，此错误使得有可能在Trans2请求中发送大于65535（0xffff）限制的payload，由上图就可知，确实发送了大于65535（0xffff）限制的payload(65558->0x10016)。

 

FEA_LIST格式转换

上述事务请求数据包中存在的payload是一个大的SMB_FEA_LIST，它不过是OS2格式的SMB_FEA结构的串联列表。“ FEA”代表“完整扩展属性”，并以名称/值属性格式包含与文件有关的信息。在payload中，SizeOfListInBytes是列表结构的第一个字段，其值为列表的大小(通常定义为0x10000)。然后精心制作SMB_FEA结构一个接一个地附加，其总大小略大于0x10000字节。当FEA列表以OS2格式发送时，由于OS2是过时的格式，因此srv.sys驱动程序会将其转换为当前使用的NT格式。但是，在解析FEA列表以将其转换为NtFeaList时，存在一个错误（漏洞1），该错误由将WORD转换为DWORD的错误类型组成。下面是涉及的两个结构。

SMB_FEA
{
    UCHAR  ExtendedAttributeFlag;
    UCHAR  AttributeNameLengthInBytes;
    USHORT AttributeValueLengthInBytes;
    UCHAR  AttributeName[AttributeNameLengthInBytes + 1];
    UCHAR  AttributeValue[AttributeValueLengthInBytes];
}

NtFeaList //Undocumented
{
    ULONG  NextEntryOffset;
    UCHAR  Flags;
    UCHAR  NtFeaNameLength;
    USHORT NtFeaValueLength;
    CHAR   NtFeaName[NtFeaNameLength];
    CHAR   NtFeaValue[NtFeaValueLength];
}

如MSDN中所述：“在Transaction2子命令和NT_TRANSACT_CREATE子命令中使用SMB_FEA数据结构来编码扩展属性（EA）名称/值对”。因此，前面看到的解析错误可以允许以大于0xFFFF的大小发送SMB_FEA_LIST，但以常规的Transaction2子命令请求是不可能实现的。下面是微软文档的介绍：

小结

对于一个transaction，如果没有发送完，后续会跟上对应的**Second数据包，服务端不会检查对应的**Second类型，只要保证其TIP，PID，UID，MID匹配，服务端就会将这些数据重新组装还原成一个transaction，而类型由最后一个**Second决定。因此，为了发送一个长度为0x10000的SMB_COM_TRANSACTION2，首先发送一个长度大于0x10000的SMB_COM_NT_TRANSACT，之后发送一系列SMB_COM_TRANSACTION2_SECONDARY数据包，只要保证TIP，PID，UID，MID一致，服务端最后就会将其当做一个SMB_COM_TRANSACTION2来处理，而此时其长度就大于了0x10000。由于SMB会等待最后一个**SECOND数据包到来才生成最后的transaction，因此EternalBlue可以在此期间发包对目标设备的内存进行部署，之后再发送最后一个数据包从而触发漏洞越界写。

漏洞3 - 构造内存布局

通过上面的分析，利用漏洞1会触发溢出导致越界写，而EternalBlue中对于该漏洞的利用思路和大多数的pool越界写是一致的，整体流程应该是这样的：

1、在内存中spray一系列srvnet的对象buffer 

2、释放掉其中的空间，以便于srv的对象buffer进行占位     

3、srv对象buffer占位

4、发包越界写srvnet的对象buffer

5、触发代码执行

srvnet对象spray

和一般的内核漏洞的利用相比，这个漏洞的环境是远程的。通常的本地内核漏洞利用的时候我们可以从容地选择进行spray的内核对象，但是对于远程的环境而言，内核对象的选择及对应的控制就要小很多。EternalBlue中用于被覆盖的对象为srvnet buffer(SRVNET_BUFFER_HDR),微软提供了SMB 2直接支持TCP的通信方式，可以通过该方式来创建srvnet缓冲区。

通过MSDN可以知道，srvnet对象的spray过程，生成的大小在数据包里可以看到。

srv对象spray

srv对象是通过释放后立即重新申请的方式获取的地址空间，但是SMB中如何通过远程方式稳定的申请并释放一段pool内存呢?这使用了一个请求格式解析混乱错误（漏洞3），其中一个SMB_COM_SESSION_SETUP_ANDX请求数据包分配了一个0x11000字节的大型NonPagedPool。SMB连接通常使用SMB_COM_SESSION_SETUP_ANDX请求开始用户身份验证并建立SMB会话。下面显示了与SMB_COM_SESSION_SETUP_ANDX关联的两种格式结构，其中存在解析混乱错误。

SMB_COM_SESSION_SETUP_ANDX  Request(LM and NTLM authentication)：

SMB_Parameters
   {
   UCHAR  WordCount;//该字段的值必须为0x0D      //offset=0x00
   Words
     {
     UCHAR  AndXCommand;
     UCHAR  AndXReserved;
     USHORT AndXOffset;
     USHORT MaxBufferSize;
     USHORT MaxMpxCount;
     USHORT VcNumber;
     ULONG  SessionKey;
     USHORT OEMPasswordLen;
     USHORT UnicodePasswordLen;
     ULONG  Reserved;
     ULONG  Capabilities;                     //offset=0x17
     }
   }
 SMB_Data
   {
   USHORT ByteCount;                          //offset=0x1B
   Bytes
     {
     UCHAR      OEMPassword[];
     UCHAR      UnicodePassword[];
     UCHAR      Pad[];
     SMB_STRING AccountName[];
     SMB_STRING PrimaryDomain[];
     SMB_STRING NativeOS[];
     SMB_STRING NativeLanMan[];
     }
   }

SMB_COM_SESSION_SETUP_ANDX  Request(NTLMv2 authentication)：

SMB_Parameters
   {
   UCHAR  WordCount;//该字段的值必须为0x0C,         //offset=0x00
   Words
     {
     UCHAR  AndXCommand;
     UCHAR  AndXReserved;
     USHORT AndXOffset;
     USHORT MaxBufferSize;
     USHORT MaxMpxCount;
     USHORT VcNumber;
     ULONG  SessionKey;
     USHORT SecurityBlobLength;
     ULONG  Reserved;
     ULONG  Capabilities;                         //offset=0x15
     }              //Capabilities:0x80000000,Extended Security
   }
 SMB_Data
   {
   USHORT ByteCount; //ByteCount=0x16             //offset=0x19
   Bytes
     {
     UCHAR      SecurityBlob[SecurityBlobLength]; //offset=0xF0
     SMB_STRING NativeOS[];                       //offset=0xFF
     SMB_STRING NativeLanMan[];                  
     }
   }

SMB_COM_SESSION_SETUP_ANDX命令的请求依赖于WordCount的值来确定具体的请求格式，上面的代码可以看出，两种不同的格式具有不同的WordCount字段值。同样，ByteCount字段在NT安全性请求格式中位于偏移量0x1B处，在扩展安全性请求格式中位于0x19处。根据该错误，如果将SMB_COM_SESSION_SETUP_ANDX请求作为扩展安全（WordCount=12）发送，包含CAP_EXTENDED_SECURITY字段，但却没有FLAGS2_EXTENDED_SECURITY字段（Capabilities-> Extended_Security = 1 和 Flags2-> Extended_Security_Negotiation = 0）。

这将会导致服务器将以处理13类型请求的方式去处理类型12的请求包，则该请求将被错误地处理为NT安全请求（WordCount=13），从而进入错误的函数GetNtSecurityParameters流程中。

BlockingSessionSetupAndx()
{
    //...

    //check word count

    if(! (request->wordCount ==13 || (request->WordCount == 12 && (request->Capablilities & CAP_EXTENDED_SECURITY))) ) 
    {
        //error and return
    }
    //...

    if ((request->Capablilities & CAP_EXTENDED_SECURITY) && (smbHeader->Flags2 & FLAGS2_EXTENDED-SECURITY))
    {
        //this request is Extend Security request
        GetExtendSecurityParameters(); // extract parameters and data to variables                 
        SrvValidatesecurityBuffer(); // do authentication
    } 
    else 
    {
        //this request is NT Security request
        GetNtSecurityParameters(); // extract parameters and data to variables         
        SrvValidateUser(); // do authentication
    }

    //...
}

                                      注：上面的BlockingSessionSetupAndx函数在srv.sys中，内容为简化之后的

进入函数GetNtSecurityParameters，函数参数中的v78为通过wordcount和Bytecount计算出来的一个size。

如果没错的话，计算过程是下面这里：

最终会执行到 goto LABEL_119，然后就会使用计算错误的值来申请非分页池内存了。

这样就可以分配预设大小的缓冲区。使用此漏洞进行了两次分配：第一次是在Pre-Hole连接中，然后是在Hole连接中。

SMB 连接名称	初始ByteCount值	错误解析的ByteCount值	请求分配的大小	实际分配的大小
Pre-Hole connection	0x16	0xFFF0	0xFFEB	0x10000
Hole connection	0x16	0x87F8	0x10FEC	0x11000

 

 

 

然后在NTFea列表分配开始之前就关闭了Hole连接（也就是最后一个Trans2 Secondary即将发送的时候），以便NTFea列表占用了0x11000字节的释放空间。Pre-Hole连接的作用在漏洞利用中并不重要，但它可能旨在处理内存分配器在释放漏洞分配和为NTFea进行新分配之间的短时间内可能收到的其他小分配请求清单。关于此漏洞的一个有趣的事情是，所有四种类型的NonPagedPool分配（NTFea列表，Pre-Hole连接，Hole分配和NumGrooms分配）都是0x10000和0x11000字节的巨大分配。由于分配量很大，因此内核NonPagedPool中的分配几乎是连续的，因此即使多次尝试，利用的机会也很高。

申请预设大小的srv buffer后，继续进行srvnet对象spray，然后释放srv buffer，发送最后一个Trans2 Secondary，此时由于要申请的大小和刚释放的大小一致，该数据包会填补生成的hole，并触发溢出漏洞导致之后的srvnet对象buffer中的MDL和指针被修改。

Exploit利用过程小结

1、通过SMB_COM_NT_TRANSACT发送一段FEA LIST长度满足0x10000的数据包，FEA列表存储在内核的分页池内存中。发送回显请求数据包以保持TCP连接打开。

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

3、发送格式错误的SMB_COM_SESSION_SETUP_ANDX请求，这将导致NonPagedPool分配指定大小的buffer。

4、通过smb 2协议的TCP请求方式进行srvnet对象的spray，每次请求都会导致在NonPagedPool中分配大小为0x11000字节的SRVNet块，目的是填充内核内存中可能存在的碎片内存区域。

5、发送格式错误的SMB_COM_SESSION_SETUP_ANDX请求，这将导致在srvnet对象之后分配一段大小和srv对象大小几乎一致的pool内存，它负责对溢出目标NTFea列表要申请的buffer进行占位。

6、关闭第3步的连接，释放分配用来处理来自其他进程的意外内存分配，对第二次喷射srvnet buffer消除意外因素。

7、通过smb 2协议的TCP请求方式继续进行srvnet对象的spray，以确保srvnet位于srv对象之后。

8、关闭第5步的连接，释放占位的buffer，生成一个hole。

9、发送最后一个SMB_COM_TRANSACTION2_SECONDARY，由于大小一致，该数据包会填补生成的hole，并触发漏洞导致之后的srvnet对象buffer中的MDL和指针被修改，此时后续发送的数据将拷贝到ffdff000的位置。(Windows内存分配器通常以后进先出的方式工作。因此，最近释放的Hole就会分配给NTFea列表，导致溢出，从而修改SRVNet块相应的某些字段)

10、断开所有连接，触发 srvnet_recv 指向的 shellcode 执行(实际上在接收数据时 shellcode 就会执行)。

漏洞复现

由于我们常用的是R3的应用程序，而上面的漏洞是在R0发生的，由于会话隔离，看不见对应的calc.exe弹出来，打开Process Explorer即可看见。

参考链接

1、https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/81e15dee-8fb6-4102-8644-7eaa7ded63f7

2、https://www.freebuf.com/articles/terminal/153230.html

3、https://github.com/worawit/MS17-010

4、https://www.virusbulletin.com/virusbulletin/2018/06/eternalblue-prominent-threat-actor-20172018/