A Dissection of the “EsteemAudit” Windows Remote Desktop Exploit

Summary

In April, a group known as the “Shadow Brokers” released a cache of stolen information that included multiple tools to exploit vulnerabilities in various versions of Microsoft Windows. The most famous of these is an exploit tool called “EternalBlue” which was repurposed to spread the WanaCrypt0r ransomware/worm earlier this month. Another tool released in this dump is “EsteemAudit”, which exploits CVE-2017-9073, a vulnerability in the Windows Remote Desktop system on Windows XP and Windows Server 2003. Both versions of this operating system are no longer supported by Microsoft (XP ended in 2014, Server 2003 in 2015) and as such Microsoft has not released a patch for the vulnerability.

Organizations that still rely on these out-of-date operating systems need to ensure they are defending against exploitation of this vulnerability, as it allows a remote attacker to take control over the system without any authentication.

Palo Alto Networks defends our customers’ systems from this exploit in the following ways:

• Traps prevents exploitation of this vulnerability on Windows XP and Server 2003 hosts.
• Threat Prevention Signature 32533 released in Content Update 692 detects the exploit in the NGFW.

Organizations that cannot upgrade systems and do not use the protections describe above should consider disabling the smart card module through Group Policy or in the registry.

Exploitation of the vulnerability is complex, but the EsteemAudit tool makes it possible for novices to use it. The remainder of this blog includes a detailed analysis of where the vulnerability exists and how EsteemAudit exploits it.

EsteemAudit Overview

This RDP remote exploit named EsteemAudit uses an inter-chunk heap overflow in an internal structure (named key_set with a size of 0x24a8) on the system heap allocated by gpkcsp.dll, which is a component of Windows Smart Card. In detail, there is 0x80 sized buffer (named key_data) in the key_set structure to store smart card information, after which there are two key_object pointers in adjacent memory. However, there is a call to memcpy in gpkcsp! MyCPAcquireContext with no boundary check, copying the entire user-controlled sized data to the location of 0x80 sized key_data. If the attacker puts more than 0x80 sized data as the source argument of memcpy, the key_object pointer adjacent with key_data will be overflowed. To exploit this, the EsteemAudit code puts the 0xb2-7 size controlled data as the source argument of memcpy, and overflowed key_object pointer with a fixed address 0x080190dc, which is an address of data section of gpkcsp.dll. After triggering the memcpy path to complete the overflow, the exploiter puts user-controlled data in that global variable at a fixed address 0x080190d8 in data section, and then triggers gpkcsp!ReleaseProvider to release the C++ object key_object (call [vtable+8]) to get control over EIP. Finally, the SharedUserData technique is used to call VirtualProtect by syscall with number 0x8f and the first stage shellcode is executed.

Introduction

Remote RDP exploits are the stuff of legend. Fortunately, no public remote exploit for Windows RDP has been available since the NT4/Win98 era. In April 2017, a group using the name “The Shadowbrokers” released an RDP exploit named EsteemAudit which attacks the remote desktop service on Windows 2003 and Windows XP by using an inter-chunk heap overflow in the Smart Card component gpkscp.dll. In this blog, we will first describe some of the internals of remote desktop protocol and mechanism, and then analyze the EsteemAudit.exe itself. Next we will analyze the details about how to deal with the RDP data in kernel and user land, how the inter-chunk heap overflow occurs, and how to exploit this inter-chunk heap overflow to execute shellcode on the vulnerable system. Finally, we will introduce the possible detection methods and how to mitigate this vulnerability without a patch.

Mechanism and Protocol

The full details of how the Remote Desktop Protocol operates are out of scope for this blog, but in this section we’ll describe the components which are relevant to this exploit.

Architecture and Components

The Terminal Services Architecture has four parts: multi-user kernel, the Remote Desktop client, the Terminal Services Licensing service, and Session Directory Services.

Figure 1 Terminal Services Architecture Diagram – (Used with permission from Microsoft)

The following table describes the Terminal Services architecture components.

Figure 2 Terminal Services Architecture Components – From Microsoft

Nicolas Collignon describes the relationships between these components in his paper named Tunneling TCP over RDP.

In the kernel-land, the relevant component is rdpwd.sys, which is responsible for MCS (Multipoint Communication Service) stack. The RDP PDU (Protocol Data Unit) are parsed and decrypted in this component.

In user-land, the winlogon component is most relevant. It is responsible for authentication of remote client. For example, if the client request a smart card redirection, the winlogon.exe will launch smart card component and communicate with the client.

RDP Protocol

With the architecture and components of remote desktop service introduced, we can dive into the components of the Remote Desktop Protocol that are relevant to the vulnerability exploited by EsteemAudit. There are several RDP documents in MSDN documentation page which are relevant to this analysis. Some of them describe the basic protocol like, [MS-RDPBCGR]: Remote Desktop Protocol: Basic Connectivity and Graphics Remoting. Others describe extensions for RDP, like [MS-RDPESC]: Remote Desktop Protocol: Smart Card Virtual Channel Extension. Aurélien Bordes listed all of the extensions at a talk at the OSSIR conference in 2010.

For the purposes of this analysis, we will consider the following components:

• [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 is based on the ITU (International Telecommunication Union) T.120 series of protocols. The T.120 standard is composed of multiple other standards, and uses the X.224 standard for transport layer communications. The X.224 standard specified how RDP packets should be encrypted and we can see this in “request PDU” and “confirm PDU” requests.

The encryptionMethods flag in X.224 request in the example below is set to 0x00000012, which represents the client requesting the 128-bit RC4 encryption [128BIT_ENCRYPTION_FLAG 0x00000002] or FIPS[FIPS_ENCRYPTION_FLAG 0x00000010].

Figure 3 X.224 Request PDU Specifying Encryption Methods

The server responds by confirming the encryptionMethod is 0x00000002 (128-bit RC4) in an X.224 confirm PDU message.

Figure 4 X.224 Confirm PDU message Confirming Encryption Method (128-bit RC4)

To keep this blog from going outside the scope of the vulnerability we will not explain the remaining steps in the protocol connection process, but the details are available in in [MS-RDPBCGR] - Remote Desktop Protocol: Basic Connectivity and Graphics Remoting.

After the RDP connection is created, the PDU between client and server will be encrypted with the negotiated encryption method (for example: 128-bit RC4). Below is an example of Client Info PDU.

Figure 5 RDP Client Info PDU

The data included in this PDU is parsed out into the following components:

The remaining data from the offset 0x51 to the end which begins with 86 b8 8a a9 is Encrypted TS_INFO_PACKET.

We can parse the protocol details from plain TS_INFO_PACKET according the format described in [MS-RDPBCGR].

Figure 6 Info Packet Structure from MS-RDPBCGR

Smart Card Extension

RDP has an extension which supports remote client login using a smart card. From [MS-RDPESC], we can find the protocol sequence and details of protocol flow.

Figure 7 High Level Protocol Sequence Diagram from MS-RDPESC

Figure 8 Protocol Flow Diagram from MS-RDPESC

EsteemAudit uses the type of SCARD_IOCTL_TRANSMIT to communicate with the smart card module on the server.

Figure 9 SCARD_IOCTL_TRANSMIT description from MS-RDPESC

As the specification states, the packet returned to a client by the server has a type of Transmit_Return. The specification describes the various fields this packet includes.

Figure 10: Transmit_Return description from MS-RDPESC

The packet sent from server to server has a type of Transmit_Call.

Figure 11 Transmit_Call description from MS-RDPESC

RDP Exploit Client (EsteemAudit.exe)

After understanding the basic knowledge of architecture, components, protocol and communications of RDP, we can look specifically at what the EsteemAudit.exe exploit client does. EsteemAudit.exe is responsible for communicating with the RDP server just like an RDP Client according the RDP protocol. It emulates an RDP client using a smart card, and sends a smart card redirection authentication request to RDP server to force it to handle the data and structure sent by EsteemAudit using the smart card module gpkcsp.dll where the vulnerability exists.

EsteemAudit.exe Overview

After reverse engineering the EsteemAudit binary, we found the exploit-start function named GoRunExp at the address .text:00381009. We will not show the entire function for brevity, and only introduce the main execution flow here.

We found that after the preparation work including connect2Target and building the exploit buffer, RecvProcessSendPackets is called repeatedly to receive and process the data from the server and send the buffer previously prepared back to it. RecvProcessSendPackets is responsible for all the details of communicating with smart card modules on the RDP server, which we discuss in an upcoming section. However, we will not introduce the details of this function, but focus on what packets RecvProcessSendPackets sends to exploit the vulnerability.

Overflow Packet

When building the overflow packet, there are only two effective fields: a value at the 0x8d offset and a constant 0x9000 at the 0x91 offset, all other fields are random data.

Figure 12 build_overflow_x86 function assembling the exploit packet.

To see the complete data sent by client, we can inspect one of the overflow packets.

Figure 13 Overflow Packet dissected in Wireshark

As described below, after the offset 0x51, the data named TS_INFO_DATA is encrypted. To decrypt the TS_INFO_DATA, we noticed that all of data are encrypted by client with the Libeay32!RC4 function.

We can get the prototype of the RC4 function -- RC4(key, len, in, out) by simply debugging it.

Figure 14 Libeay32!RC4 disassembly.

We can then set a breakpoint before and after the RC4 function execution to print the in and out buffers retrieve the encrypted data and decrypted data.

The decrypted buffer gives us the content of the TS_INFO_DATA of the overflow packet.

As the execution continues, we can extract the two fields from the memory dump which will trigger the buffer overflow.

The address 0x080190dc is important to note, we will introduce how it is involved in the exploit in the RDP Server section below.

Exploit Packet Analysis

When building the exploit buffer, there are many interesting fields used in the buffer, like 0x11111111, 0x22222222 and 0x7ffe0300.

Figure 15 The build_exploit_x86 function assmploying the exploit buffer.

Figure 16 The exploit buffer in a live pcap.

We can extract the data for the exploit buffer the same way we did for the overflow buffer.

The exploit buffer packet is also a Device Control Response (DR_CONTROL_RSP) with the kind set to DR_DEVICE_IOCOMPLETION (0x49434472). This is the same as the overflow buffer described earlier.

The final two packets of the first stage are the Select_MF and End Response messages, respectively. We only show the decrypted data here.

The length of pExtraBytes is two. Two two extra bytes “90 00” will be processed by smart card module on the Server.

The length of pExtraBytes is 0, it is just an end response. This completes the traffic from EsteemAudit, next we’ll go into how the server processes this data.

RDP Server

With the details on what the client send to the server and the protocol in the encrypted packet out of the way, we can start looking at how the server processes the packet and where the vulnerability is exploited.

Kernel Layer

As described in the Architecture and Component section, we know that the kernel component is responsible for receiving the RDP data. We need to identify the data entry point function that handles the RAW data sent from the client to the server.

Look at the two stack traces below. It directly shows the execution flows when a DEVICE_IO packet arrives. Termdd is the core dispatcher, RDPWD is responsible for MCS stack ad we can get the raw data sent by client from RDPWD!MCSIcaRawInput. The next several functions parsed data layer by layer according to the RDP protocol described earlier.

We can see the content of srcBuf through the comment from IDA pro when RDPWD!MCSIcaRawInputWorker call RDPWD!RecognizeMCSFrame.

Figure 17 Content of srcBuf

We can also see how RDPWD!RecognizeMCSFrame decodes PER.

Figure 18 RDPWD!RecognizeMCSFrame decodes PER-encoded MCS Domain PDU

After parsing the MCS stack, RDPWD will parse the TS_DATA_INFO part. The data in TS_DATA_INFO is encrypted so the SM_MCSSendDataCallback function calls SMDecryptPacket-> DecryptData->rc4 to decrypt the data first.

Figure 19 Decrypting the TS_DATA_INFO data

For those who want to recreated this, you can also set breakpoint in RDPWD!rc4 function which is a similar implementation with libeay32 like we did in the client to see encrypted and decrypted data on the server.

Next, the SM_MCSSendDataCallback function calls WDW_OnDataReceived will handle the decrypted data.

Figure 20 WDW_OnDataReceived Function Call

After this, the function calls termdd!IcaChannelInput to dispatch decrypted data to different channels. In this example, the buffer overflow packet sent by EsteemAudit is the Device IO packet which is a part of File System Virtual Channel Extension and will be parsed by RDPDR module.

We can find the DR_DEVICE_IOCOMPLETION [MS-RDPEFS.pdf] header in the decrypted buffer overflow packet.

In RDPDR module, we can see there is vtable call to recognize the packet and then handle the packet.

Figure 21 RDPDR Module Handling the packet

If the server receives a packet marked as RDPDR_HEADER, RecognizePacket with the appropriate class is called.

Figure 22 RecognizePacket called for RDPDR_HEADER

The buffer overflow and exploit packets sent by EsteemAudit have the 0x49434472 flag set. 0x4472 is used for the Device redirector core component and 0x4943 is used for Device I/O response.

Figure 23 Packet Type Flags from [MS-RDPESP]

After recognizing the packet type, rdpdr!DrSession::ReadCompletion calls HandlePacket to parse the packet. We can see OnDeviceControlCompletion will deal with the header.

Figure 24 Continued Parsing of the RDP Packet

After handling the packet, we can see rdpdr!DrDevice::CompleteRxContext be notified via I/O that we have processed the packet and we can exchange the context. Other modules are also notified and continue to process the left part of the packet, here is pbExtraBytes buffer.

Figure 25 CompleteRxContext Notified of the Processed Packet

User Land Layer

In user land, winlogon.exe calls the smart card modules, like gpkcsp, scredir, and winscard to communicate with the client.

First, we can investigate the stack trace below. It is a stack trace of copying the pbExtraBytes sent by the client from the kernel to the user land. We see the data sent by client flow into the user land on the server.

The most important function in user land on the server is gpkcsp!MyCPAcquireContext. It is responsible for sending, receiving and processing smart card packets, and it corresponds to the RecvProcessSendPackets function of EsteemAudit.

Before we start introduce this function, let’s look at scredir!SCardTransmit. This function is called by gpkcsp!DoSCardTransmit and it is a basic unit for sending and receiving the smart card information.

Figure 26 scredir!SCardTransmit Function

We that the 1^st argument to _SendSCardIOCTL, 0x900d0, represents SCARD_IOCTL_TRANSMIT, and the data structure of the send and receive buffer fallows _Transmit_Call and _Transmit_Return structure described earlier. After getting the data from the kernel, Transmit_Return_Decode will decode and process the data. Pay attention to scredir!_CopyReturnToCallerBuffer function, it will copy the data sent by client to a global variable 0x080190d8 in data section. This means that the data in buffer overflow packet and in exploit packet will be copied to the address 0x080190d8. That’s why an absolute address 0x080190dc is hardcoded in buffer overflow packet.

Figure 27 Data from the Overflow and Exploit Packets are copied to 0x080190d8.

Now we can introduce the gpkcsp!MyCPAcquireContext function and the whole exploit process. The details for SCardEstablishContext and ConnectToCard are not shown here, but we will introduce what happened when the data in buffer overflow packet arrived.

Figure 28 gpkcsp!MyCPAcquireContext Function

There is global variable named ProvCont which stores a 0x24a8 sized heap address.

Figure 29 below graphically shows the data structure of gpkcsp!ProvCont.

Figure 30 Graphical Depiction of the gpkcsp!ProvCont data structure.

After calling DoSCardTransmit to deal with buffer overflow packet and store the data in 0x080190d8, MyCPAcquireContext initialize the KeyData memory (0x80) and copies the data at 0x080190dd with the size in the data sent by client (0xb2-7) to the KeyData memory.

Figure 31 MyCPAcquireContext Initializes data structure and copies data, causing the overflow

Figure 32 below shows how memory is overwritten causing the heap overflow.

Figure 32 Graphical Depiction of the Heap Overflow

The debug log shows where KeyObject object overflows.

After KeyObject overflows, we can see how gpkcsp!MyCPAcquireContext deals with the next packets and how the EIP was controlled.

Figure 33 gpkcsp!MyCPAcquireContext handles the subsequent packets

We note that the unsymbolized function sub_8009094 calls DoSCardTransmit and copies expbuffer to 0x080x90d8, which is an always fix address to store any data sent by client without ASLR (Address Space Layout Randomization) on Windows Server 2003.

After the exploit buffer is ready, gpkcsp!MyCPAcquireContext processes the ReleaseProvider path.

Figure 34 gpkcsp!MyCPAcquireContext processes the ReleaseProvider path

This will trigger the C++ class vtable call KeyObject->release in the CryptDestroyKey function.

Figure 35 Object is released in the CryptDestroyKey function

The log below show the process from controlling EIP to shellcode execution. The exploit uses the SharedUserData technique to call KiFastSystemCall to execute VirtualProtect and make the memory 0x080180d8 writable and executable, and to execute the shellcode at address 0x08019148. At this point the exploit has completed the first stage.

Detection and Mitigation

As CVE-2017-9073 only exists on Windows Server 2003 and Windows XP, both of which are no longer supported by Microsoft, users should first consider upgrading to a newer version of Windows as no official patch is available. However, as this vulnerability exists in the smart card module gpkcsp, there are potential work-arounds.

• Disabling the smart card module through Group Policy or in the registry.
  • Do this in the registry: Set/Add key fEnableSmartCard in the path HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\ to 0 with the type of REG_DWORD.
• Traps prevents exploitation of this vulnerability on Windows XP and Server 2003 hosts.
• Threat Prevention Signature 32533 released in Content Update 692 detects the exploit in the NGFW.
• Wherever possible, disable or restrict access to RDP from external sources

Conclusion

RDP is a very useful but very complex component of Windows. Based on our analysis of the EsteemAudit exploit, we find that the vulnerability itself is not obscure, but it took quite a bit of effort to write a successful exploit. Interestingly, gpkcsp choose a global variable to store the data sent by the client, it supplies a capacity of controlling the arbitrary data in already-known address in the remote server without ASLR. This is a powerful feature for exploit authors to take advantage of. In any case, EsteemAudit is a reliable and powerful RDP exploit tool for Windows XP and Windows 2003. Users should take steps to ensure their Windows XP and Windows Server 2003 are protected through one of the mitigation steps listed above. A network vulnerability like this one can be used in a “worm-able” fashion, similar to the WanaCrypt0r attacks which had global impact earlier this month.

Register for Ignite ’17 Security Conference
Vancouver, BC June 12–15, 2017

Ignite ’17 Security Conference is a live, four-day conference designed for today’s security professionals. Hear from innovators and experts, gain real-world skills through hands-on sessions and interactive workshops, and find out how breach prevention is changing the security industry. Visit the Ignite website for more information on tracks, workshops and marquee sessions.