Low-level Reversing of BLUEKEEP vulnerability (CVE-2019-0708)

This work was originally done on Windows 7 Ultimate SP1 64-bit. 

The versions of the libraries used in the tutorial are:

  • termdd.sys version 6.1.7601.17514
  • rdpwsx.dll version 6.1.7601.17828
  • rdpwd.sys version 6.1.7601.17830
  • icaapi.dll version 6.1.7600.16385
  • rdpcorekmts.dll version 6.1.7601.17828

 

The Svchost.exe process

In the Windows NT operating system family, svchost.exe ('Service Host) is a system process that serves or hosts multiple Windows services.

It runs on multiple instances, each hosting one or more services. It's indispensable in the execution of so-called shared services processes, where a grouping of services can share processes in order to reduce the use of system resources.

The tasklist /svc command on a console with administrator permission shows us the different svchost processes and their associated services.

Image
tasklist svc command

Text

Also in PROCESS EXPLORER you can easily identify which of the SVChosts is the one that handles RDP connections.(Remote Desktop Services)

Image
PROCESS EXPLORER

 

 

 

 

 

 

 

 

STEP 1) Initial reversing to find the point where the program starts to parse my data decrypted

The first thing we'll do is try to see where the driver is called from, for that, once we're debugging the remote kernel with Windbg or IDA, we put a breakpoint in the driver dispatch i.e. in the IcaDispatch function of termdd.sys.

Image
debugging the remote kernel

Text

In windbg bar I type

.reload /f

!process 1 0

PROCESS fffffa8006598b30

SessionId: 0 Cid: 0594 Peb: 7fffffd7000 ParentCid: 01d4

DirBase: 108706000 ObjectTable: fffff8a000f119a0 HandleCount: 662.

Image: svchost.exe

The call stack is

WINDBG>k

Child-SP RetAddr Call Site

fffff880`05c14728 fffff800`02b95b35 termdd!IcaDispatch

fffff880`05c14730 fffff800`02b923d8 nt!IopParseDevice+0x5a5

fffff880`05c148c0 fffff800`02b935f6 nt!ObpLookupObjectName+0x588

fffff880`05c149b0 fffff800`02b94efc nt!ObOpenObjectByName+0x306

fffff880`05c14a80 fffff800`02b9fb54 nt!IopCreateFile+0x2bc

fffff880`05c14b20 fffff800`0289b253 nt!NtCreateFile+0x78

fffff880`05c14bb0 00000000`7781186a nt!KiSystemServiceCopyEnd+0x13

00000000`06d0f6c8 000007fe`f95014b2 ntdll!NtCreateFile+0xa

00000000`06d0f6d0 000007fe`f95013f3 ICAAPI!IcaOpen+0xa6

00000000`06d0f790 000007fe`f7dbd2b6 ICAAPI!IcaOpen+0x13

00000000`06d0f7c0 000007fe`f7dc04bd rdpcorekmts!CKMRDPConnection::InitializeInstance+0x1da

00000000`06d0f830 000007fe`f7dbb58a rdpcorekmts!CKMRDPConnection::Listen+0xf9

00000000`06d0f8d0 000007fe`f7dba8ea rdpcorekmts!CKMRDPListener::ListenThreadWorker+0xae

00000000`06d0f910 00000000`7755652d rdpcorekmts!CKMRDPListener::staticListenThread+0x12

00000000`06d0f940 00000000`777ec521 kernel32!BaseThreadInitThunk+0xd

00000000`06d0f970 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

An instance of CKMRDPListener class is created.

This thread is created, the start address of the thread is the method CKMRDPListener::staticListenThread

Image
CKMRDPListener

Text

the execution continues here

Image
execution continues

 

 

Text

here

Image
here

Text

here

Image
here

Text

IcaOpen is called

Image
IcaOpen is called

 

Image
caOpen is called

Text

We can see RDX (buffer) and r8d (size of buffer) both are equal to zero in this first call to IcaOpen.

Next the driver termdd is opened using the call to ntCreateFile

Image
driver termdd is opened

Text

We arrived to IcaDispatch when opening the driver.

Image
IcaDispatch

Text

Reversing we can see

Image
IcaDispatch ros+bx

Text

The MajorFunction value is read here 

Image
MajorFunction value

Text

As MajorFuncion equals 0 it takes us to IcaCreate

Image
MajorFuncion equals 0

Text

Inside IcaCreate, SystemBuffer is equal to 0

Image
IcaCreate, SystemBuffer is equal to 0

Text

A chunk of size 0x298 and tag ciST is created, and I call it chunk_CONNECTION.

Image
chunk_CONNECTION.

Text

chunk_CONNECTION is stored in FILE_OBJECT.FsContext

Image
chunk_CONNECTION

Text

I rename FsContext to FsContext_chunk_CONNECTION.

Image
FsContext to FsContext_chunk_CONNECTION

Text

IcaDispatch is called for second time

Child-SP RetAddr Call Site
fffff880`05c146a0 fffff880`03c96748 termdd!IcaCreate+0x36
fffff880`05c146f0 fffff800`02b95b35 termdd!IcaDispatch+0x2d4
fffff880`05c14730 fffff800`02b923d8 nt!IopParseDevice+0x5a5
fffff880`05c148c0 fffff800`02b935f6 nt!ObpLookupObjectName+0x588
fffff880`05c149b0 fffff800`02b94efc nt!ObOpenObjectByName+0x306
fffff880`05c14a80 fffff800`02b9fb54 nt!IopCreateFile+0x2bc
fffff880`05c14b20 fffff800`0289b253 nt!NtCreateFile+0x78
fffff880`05c14bb0 00000000`7781186a nt!KiSystemServiceCopyEnd+0x13
00000000`06d0f618 000007fe`f95014b2 ntdll!NtCreateFile+0xa
00000000`06d0f620 000007fe`f95018c9 ICAAPI!IcaOpen+0xa6
00000000`06d0f6e0 000007fe`f95017e8 ICAAPI!IcaStackOpen+0xa4
00000000`06d0f710 000007fe`f7dbc015 ICAAPI!IcaStackOpen+0x83
00000000`06d0f760 000007fe`f7dbd2f9 rdpcorekmts!CStack::CStack+0x189
00000000`06d0f7c0 000007fe`f7dc04bd rdpcorekmts!CKMRDPConnection::InitializeInstance+0x21d
00000000`06d0f830 000007fe`f7dbb58a rdpcorekmts!CKMRDPConnection::Listen+0xf9
00000000`06d0f8d0 000007fe`f7dba8ea rdpcorekmts!CKMRDPListener::ListenThreadWorker+0xae
00000000`06d0f910 00000000`7755652d rdpcorekmts!CKMRDPListener::staticListenThread+0x12
00000000`06d0f940 00000000`777ec521 kernel32!BaseThreadInitThunk+0xd
00000000`06d0f970 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

We had seen that the previous call to the driver had been generated here

Image
previous call to the driver

Text

When that call ends an instance of the class Cstack is created 

Image
class Cstack

 

 

 

 

 

 

And the class constructor is called.

Image
class constructor

 

 

 

 

 

 

 

this matches the current call stack

fffff880`05c146a0 fffff880`03c96748 termdd!IcaCreate+0x36
fffff880`05c146f0 fffff800`02b95b35 termdd!IcaDispatch+0x2d4
fffff880`05c14730 fffff800`02b923d8 nt!IopParseDevice+0x5a5
fffff880`05c148c0 fffff800`02b935f6 nt!ObpLookupObjectName+0x588
fffff880`05c149b0 fffff800`02b94efc nt!ObOpenObjectByName+0x306
fffff880`05c14a80 fffff800`02b9fb54 nt!IopCreateFile+0x2bc
fffff880`05c14b20 fffff800`0289b253 nt!NtCreateFile+0x78
fffff880`05c14bb0 00000000`7781186a nt!KiSystemServiceCopyEnd+0x13
00000000`06d0f618 000007fe`f95014b2 ntdll!NtCreateFile+0xa
00000000`06d0f620 000007fe`f95018c9 ICAAPI!IcaOpen+0xa6
00000000`06d0f6e0 000007fe`f95017e8 ICAAPI!IcaStackOpen+0xa4
00000000`06d0f710 000007fe`f7dbc015 ICAAPI!IcaStackOpen+0x83
00000000`06d0f760 000007fe`f7dbd2f9 rdpcorekmts!CStack::CStack+0x189
00000000`06d0f7c0 000007fe`f7dc04bd rdpcorekmts!CKMRDPConnection::InitializeInstance+0x21d
00000000`06d0f830 000007fe`f7dbb58a rdpcorekmts!CKMRDPConnection::Listen+0xf9
00000000`06d0f8d0 000007fe`f7dba8ea rdpcorekmts!CKMRDPListener::ListenThreadWorker+0xae
00000000`06d0f910 00000000`7755652d rdpcorekmts!CKMRDPListener::staticListenThread+0x12
00000000`06d0f940 00000000`777ec521 kernel32!BaseThreadInitThunk+0xd
00000000`06d0f970 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

 

The highlighted text is the same for both calls, the difference is the underlined line and the upper lines

00000000`06d0f7c0 000007fe`f7dc04bd rdpcorekmts!CKMRDPConnection::InitializeInstance+0x1da

Image
00000000`06d0f7c0 000007fe

Text

The second call returns to  

00000000`06d0f7c0 000007fe`f7dc04bd rdpcorekmts!CKMRDPConnection::InitializeInstance+0x21d

Image
 second call

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

And this second call continues to

Image
second call

 

 

 

 

 

 

 

 

Next

Image
next

Text

Next

Image
Next

Text

We arrived to _IcaOpen, calling ntCreafile for the second time, but now Buffer is a chunk in user allocated with a size different than zero, its size is 0x36.

Image
_IcaOpen

Text

This second call reaches IcaDispath and IcaCreate in similar way to the first call.

 

But now SystemBuffer is different than zero, I suppose that SystemBuffer is created, if the buffer size is different to zero.(in the first call buffer=0 → SystemBuffer=0 now buffer!=0 → SystemBuffer is !=0).

SystemBuffer is stored in _IRP.AssociatedIrp.SystemBuffer here 

Image
SystemBuffer

Text

in the decompiled code

Image
decompiled cod

Text

Previously IRP is moved to r12

Image
Previously IRP

 

 

Image
Previously IRP

Text

That address is accessed many times over there, so the only way to stop when it is nonzero is to use a conditional breakpoint. 

Image
address

Text

The first time that RAX is different from zero it stops before the second call to CREATE, and if I continue executing, I reach IcaCreate with that new value of SystemBuffer.

Image
RAX

Text

We arrived at this code, the variable named "contador" is zero, for this reason, we landed in IcaCreateStack.

Image
variable named contador is zero

Text

In IcaCreateStack a new fragment of size 0xBA8 is allocated, I call it chunk_stack_0xBA8.

Image
IcaCreateStack a new fragment

Text

I comment the conditional breakpoint part, to avoid stopping and only keep logging.

Image
comment the conditional breakpoint

Text

I repeat the process to get a new fresh log. 

Image
repeat the process

Text

Summarizing by just executing this two lines of code to create a connection, and even without sending data, we have access to the driver

The most relevent part of the log when connecting is this.

Image
MAJOR FUNCTION

IcaCreate was called two times, with MajorFunction = 0x0. The first call allocates CHUNK_CONNECTION, the second call allocates chunk_stack_0xBA8.

We will begin to reverse the data that it receives, for it would be convenient to be able to use Wireshark to analyze the data, although as the connection is encrypted with SSL, in Wireshark we could only see that the encrypted data which does not help us much.

Image
reverse the data

Text

The data travels encrypted and thus the Wireshark receives it, but we will try to use it all the same.

For this purpose we need to detect the point where the program begins to parse data already decrypted.

Image
data travels encrypted and thus the Wireshark

Text

The driver rdpwd.sys is in charge of starting to parse the data already decrypted.

The important point for us is in the function MCSIcaRawInputWorker, where the program started to parse the decrypted code.

Image
MCSIcaRawInputWorker

Text

STEP 2) Put some conditional breakpoints in IDA PRO to dump to a file the data decrypted

The idea is place a conditional breakpoint in that point, so that each time the execution passes there, it will save the data it has already decrypted in a file, then use that file and load it in Wireshark.

Image
conditional breakpoint

 

Text

This will analyze the module rdpwd.sys and I can find its functions in IDA, debugging from my database of termdd.sys, when it stops at any breakpoint of this driver.

Image
module rdpwdsys

Text

I already found the important point: if the module rdpwd.sys changes its location by ASLR, I will have to repeat these steps to relocate the breakpoint correctly.

 

address = 0xFFFFF880034675E8

filename=r"C:\Users\ricardo\Desktop\pepe.txt"

size=0x40
out=open(filename, "wb"
dbgr =True
data = GetManyBytes(address, size, use_dbg=dbgr)
out.write(data)
out.close()

This script saves in a file the bytes pointed by variable "address", the amount saved will be given by the variable "size", and saves it in a file on my desktop, I will adapt it to read the address and size from the registers at the point of breakpoint.

address=cpu.r12
size=cpu.rbp
filename=r"C:\Users\ricardo\Desktop\pepe.txt"
out=open(filename, "ab")
dbgr =True
data = GetManyBytes(address, size, use_dbg=dbgr)
out.write(data)

Image
out.write(data)

Text

This will dump the bytes perfectly to the file.

Image
dump the bytes

Text

I will use this script in the conditional breakpoint.

Image
script in the conditional breakpoint

Text

This script made a raw dump, but wireshark only imports in this format.

Image
raw dump

Text

address=cpu.r12
size=cpu.rbp
filename=r"C:\Users\ricardo\Desktop\pepe.txt"
out=open(filename, "ab")
dbgr =True
data = GetManyBytes(address, size, use_dbg=dbgr)

str=""
for i in data:
     str+= "%02x "%ord(i)

out.write(str)

in Windows 7 32 bits version this is the important point where the decrypted code is parsed, and we can use this script to dump to a file.

Image
Windows 7 32 bits version

Text

Windows 7 32 script

address=cpu.eax

size=cpu.ebx

filename=r"C:\Users\ricardo\Desktop\pepefff.txt"

out=open(filename, "ab")

dbgr =True

data = GetManyBytes(address, size, use_dbg=dbgr)

str=""

for i in data:

     str+= "%02x "%ord(i)

out.write(str)

 

Windows XP 32 bits script 

address=cpu.eax

size=cpu.edi

filename=r"C:\Users\ricardo\Desktop\pepefff.txt"

out=open(filename, "ab")

dbgr =True

data = GetManyBytes(address, size, use_dbg=dbgr)

str=""

for i in data:

    str+= "%02x "%ord(i)

out.write(str)

This is the similar point in Windows XP.

Image
Windows XP

Text

STEP 3) Importing to Wireshark

This script will save the bytes in the format that wireshark will understand.

When I I"Import from hex dump", I will use the port "3389/tcp" : "msrdp" 

Image
hex dump

Text

We load our dump file and put the destination port as 3389, the source port is not important.

 

I add a rule to decode port 3389 as TPKT

Image
rule to decode port 3389 as TPKT

 

Image
decode port 3389

Text

That file will be decoded as TPKT in wireshark.

That's the complete script.

Image
complete script

Text

Using that script, the dump file is created, when it is imported as a hexadecimal file in Wireshark, it is displayed perfectly.

Image
dump file is created

Text

This work can be done also by importing the SSL private key in wireshark, but I like to do it in the most manual way, old school type.

STEP 4) More reversing

We are ready to receive and analyze our first package, but first we must complete and analyze some more tasks that the program performs after what we saw before receiving the first package of our data.

Image
receive and analyze our first package

Text

We can see that there are a few more calls before starting to receive data, a couple more calls to the driver.

Image
few more calls

Text

The part marked in red is what we have left to analyze from the first connection without sending data.

I will modify the conditional breakpoint to stop at the first MajorFunction = 0xE.

Image
MajorFunction = 0xE

Text

It will stop when MajorFunction = 0xE

Image
MajorFunction = 0xE

Text

We arrived at IcaDeviceControl.

Image
IcaDeviceControl

Text

We can see that this call is generated when the program accepts the connection, calling ZwDeviceIoControlFile next.

Image
call is generated

Text

We can see that IRP and IO_STACK_LOCATION are maintained with the same value, fileobject has changed.

Image
IRP and IO_STACK_LOCATION

Text

We will leave the previous structure called FILE_OBJECT for the previous call, and we will make a copy with the original fields called FILE_OBJECT_2, to be used in this call.

Image
FILE_OBJECT

Text

The previous FILE_OBJECT was an object that was obtained from ObReferenceObjectByHandle.

Image
FILE_OBJECT

Text

The new FILE_OBJECT has the same structure but is a different object, for that reason we create a new structure for this.

Image
FILE_OBJECT

Text

We continue reversing ProbeAndCaptureUserBuffers

Image
ProbeAndCaptureUserBuffers

Text

A new chunk with the size (InputBufferLenght + OutputBufferLenght) is created.

Image
InputBufferLenght OutputBufferLenght

Text

Stores the pointers to the Input and Output buffers chunks.

Image
Input and Output

Text

We can see that IcaUserProbeAddress is similar to nt! MmUserProbeAddress value

Image
IcaUserProbeAddress

Text

That's used to verify whether a user-specified address resides within user-mode memory areas, or not.

If the address is lower than IcaUserProbeAddress resides in User mode memory areas, and a second check is performed to ensure than the InputUserBuffer + InputBufferLenght address is bigger than InputUserBuffer address.(size not negative)

Image
lower than IcaUserProbeAddress

 

Text

Then the data is copied from the InputUserBuffer to the chunk_Input_Buffer that has just allocated for this purpose.

We can see the data that the program copies from InputUserBuffer, it's not data that we send yet.

Image
InputUserBuffer

Text

Since the OutputBufferLength is zero, it will not copy from OutputUserBuffer to the chunk_OutputBuffer.

Image
OutputBufferLength is zero

Text

Clears chunk_OutputBuffer and return.

Image
chunk_OutputBuffer

Text

Returning from ProbeAndCaptureUserBuffers, we can see that this function copies the input and output buffer of the user mode memory to the new chunks allocated in the kernel memory, for the handling of said data by the driver

Image
ProbeAndCaptureUserBuffers

Text

The variable "resource" points to IcaStackDispatchTable.

Image
IcaStackDispatchTable

Text

I frame the area of the table and create a structure from memory which I call _IcaStackDispatchTable.

Image
_IcaStackDispatchTable

Text

I entered and started to reverse this function.

Image
I entered and started to reverse this function

Text

The first time we arrived here, the IOCTL value is 38002b.

Image
IOCTL value

Text

We arrived to a call to _IcaPushStack.

Image
_IcaPushStack

Text

Inside two allocations are performed, i named them chunk_PUSH_STACK_0x488 and chunk_PUSH_STACK_0xA8

Image
hunk_PUSH_STACK_0x488 and chunk_PUSH_STACK_0xA8

Text

When IOCTL value 0x38002b is used, we reach _IcaLoadSd 

Image
 IOCTL value 0x38002b

Text

We can see the complete log of the calls to the driver with different IOCTL only in the connection without sending data yet.

IO_STACK_LOCATION 0xfffffa80061bea90L

IRP 0xfffffa80061be9c0L

chunk_CONNECTION 0xfffffa8006223510L

IO_STACK_LOCATION 0xfffffa80061bea90L

IRP 0xfffffa80061be9c0L

FILE_OBJECT 0xfffffa8004231860L

chunk_stack_0xBA8 0xfffffa80068d63d0L

FILE_OBJECT_2 0xfffffa80063307b0L

IOCTL 0x380047L

FILE_OBJECT_2 0xfffffa8006335ae0L

IOCTL 0x38002bL

chunk_PUSH_STACK_0x488 0xfffffa8006922a20L

chunk_PUSH_STACK_0xa8 0xfffffa8005ce0570L

FILE_OBJECT_2 0xfffffa8006335ae0L

IOCTL 0x38002bL

chunk_PUSH_STACK_0x488 0xfffffa8005f234e0L

chunk_PUSH_STACK_0xa8 0xfffffa8006875ba0L

FILE_OBJECT_2 0xfffffa8006335ae0L

IOCTL 0x38002bL

chunk_PUSH_STACK_0x488 0xfffffa8005daf010L

chunk_PUSH_STACK_0xa8 0xfffffa8006324c40L

FILE_OBJECT_2 0xfffffa8006335ae0L

IOCTL 0x38003bL

FILE_OBJECT_2 0xfffffa8006335ae0L

IOCTL 0x3800c7L

FILE_OBJECT_2 0xfffffa8006335ae0L

IOCTL 0x38244fL

FILE_OBJECT_2 0xfffffa8006335ae0L

IOCTL 0x38016fL

FILE_OBJECT_2 0xfffffa8006335ae0L

IOCTL 0x380173L

FILE_OBJECT_2 0xfffffa8006334c90L

FILE_OBJECT_2 0xfffffa8006335ae0L

IOCTL 0x38004bL

IO_STACK_LOCATION 0xfffffa8004ceb9d0L

IRP 0xfffffa8004ceb900L

FILE_OBJECT 0xfffffa8006334c90L

chunk_channel 0xfffffa8006923240L

guarda RDI DESTINATION 0xfffffa8006923240L

FILE_OBJECT_2 0xfffffa8006335ae0L

IOCTL 0x381403L

FILE_OBJECT_2 0xfffffa8006335ae0L

IOCTL 0x380148L

I will put conditional breakpoints in each different IOCTL, to list the functions where each one ends up.

 

The IOCTLs 0x380047, 0x38003b, 0x3800c7, 0x38244f, 0x38016f, 0x38004b, 0x381403  end in _IcaCallStack

Image
The IOCTLs 0x380047

Text

These IOCTLs also reach _IcaCallSd

Image
 _IcaCallSd

Text

IOCTL 0x380148 does nothing 

IOCTL 0x380173 reaches _IcaDriverThread

Image
_IcaDriverThread

Text

And this last one reaches tdtcp_TdInputThread also.

Image
tdtcp_TdInputThread

Text

This function is used to receive the data sended by the user.

 

STEP 5) Receiving data

If we continue running to the point of data entry breakpoint, we can see in the call stack that it comes from tdtcp! TdInputThread.

Image
tdtcp! TdInputThread

Text

The server is ready now, and waiting for our first send.

 

We will analyze the packages and next we will return to the reversing.

STEP 6) Analyzing Packets

Negotiate Request package

03 00 00 13 0e e0 00 00 00 00 00 01 00 08 00 01 00 00 00

Image
Negotiate Request package

Text

Requested Protocol 

Image
Requested Protocol

Text

Negotiation Response package

The Response package was similar only with Type=0x2 RDP Negotiation Response

Image
Type=0x2 RDP Negotiation Response

Text

Connect Initial Package

The package starts with 

"\x03\x00\xFF\xFF\x02\xf0\x80" #\xFF\xFF are sizes to be calculated and smashed at the end

Header 

03 -> TPKT: TPKT version = 3  00 -> TPKT: Reserved = 0  FF -> TPKT: Packet length - high part  FF -> TPKT: Packet length - low part

X.224

 02 -> X.224: Length indicator = 2  f0 -> X.224: Type = 0xf0 = Data TPDU  80 -> X.224: EOT

PDU

"7f 65" .. -- BER: Application-Defined Type = APPLICATION 101,
"82 FF FF" .. -- BER: Type Length = will be calculated and smashed at the end in the Dos sample will be 0x1b2
"04 01 01" .. -- Connect-Initial::callingDomainSelector
"04 01 01" .. -- Connect-Initial::calledDomainSelector
"01 01 ff" .. -- Connect-Initial::upwardFlag = TRUE

"30 19" .. -- Connect-Initial::targetParameters (25 bytes)
"02 01 22" .. -- DomainParameters::maxChannelIds = 34
"02 01 02" .. -- DomainParameters::maxUserIds = 2
"02 01 00" .. -- DomainParameters::maxTokenIds = 0
"02 01 01" .. -- DomainParameters::numPriorities = 1
"02 01 00" .. -- DomainParameters::minThroughput = 0
"02 01 01" .. -- DomainParameters::maxHeight = 1
"02 02 ff ff" .. -- DomainParameters::maxMCSPDUsize = 65535
"02 01 02" .. -- DomainParameters::protocolVersion = 2

"30 19" .. -- Connect-Initial::minimumParameters (25 bytes)
"02 01 01" .. -- DomainParameters::maxChannelIds = 1
"02 01 01" .. -- DomainParameters::maxUserIds = 1
"02 01 01" .. -- DomainParameters::maxTokenIds = 1
"02 01 01" .. -- DomainParameters::numPriorities = 1
"02 01 00" .. -- DomainParameters::minThroughput = 0
"02 01 01" .. -- DomainParameters::maxHeight = 1
"02 02 04 20" .. -- DomainParameters::maxMCSPDUsize = 1056
"02 01 02" .. -- DomainParameters::protocolVersion = 2

"30 1c" .. -- Connect-Initial::maximumParameters (28 bytes)
"02 02 ff ff" .. -- DomainParameters::maxChannelIds = 65535
"02 02 fc 17" .. -- DomainParameters::maxUserIds = 64535
"02 02 ff ff" .. -- DomainParameters::maxTokenIds = 65535
"02 01 01" .. -- DomainParameters::numPriorities = 1
"02 01 00" .. -- DomainParameters::minThroughput = 0
"02 01 01" .. -- DomainParameters::maxHeight = 1
"02 02 ff ff" .. -- DomainParameters::maxMCSPDUsize = 65535
"02 01 02" .. -- DomainParameters::protocolVersion = 2

"04 82 FF FF" .. -- Connect-Initial::userData (calculated at the end in the DoS example will be 0x151 bytes)

"00 05" .. -- object length = 5 bytes
"00 14 7c 00 01" .. -- object
"81 48" .. -- ConnectData::connectPDU length = 0x48 bytes
"00 08 00 10 00 01 c0 00 44 75 63 61" .. -- PER encoded (ALIGNED variant of BASIC-PER) GCC Conference Create Request PDU

"81 FF" .. -- UserData::value length (calculated at the end in the DoS example will be 0x13a bytes)

#-------------
"01 c0 ea 00" .. -- TS_UD_HEADER::type = CS_CORE (0xc001), length = 0xea bytes
"04 00 08 00" .. -- TS_UD_CS_CORE::version = 0x0008004
"00 05" .. -- TS_UD_CS_CORE::desktopWidth = 1280
"20 03" .. -- TS_UD_CS_CORE::desktopHeight = 1024
"01 ca" .. -- TS_UD_CS_CORE::colorDepth = RNS_UD_COLOR_8BPP (0xca01)
"03 aa" .. -- TS_UD_CS_CORE::SASSequence
"09 04 00 00" .. -- TS_UD_CS_CORE::keyboardLayout = 0x409 = 1033 = English (US)
"28 0a 00 00" .. -- TS_UD_CS_CORE::clientBuild = 2600

"45 00 4d 00 50 00 2d 00 4c 00 41 00 50 00 2d 00 " ..
"30 00 30 00 31 00 34 00 00 00 00 00 00 00 00 00 " .. -- TS_UD_CS_CORE::clientName = EMP-LAP-0014

"04 00 00 00" .. -- TS_UD_CS_CORE::keyboardType
"00 00 00 00" .. -- TS_UD_CS_CORE::keyboardSubtype
"0c 00 00 00" .. -- TS_UD_CS_CORE::keyboardFunctionKey

"00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 " ..
"00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 " ..
"00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 " ..
"00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 " .. -- TS_UD_CS_CORE::imeFileName = ""

"01 ca" .. -- TS_UD_CS_CORE::postBeta2ColorDepth = RNS_UD_COLOR_8BPP (0xca01)
"01 00" .. -- TS_UD_CS_CORE::clientProductId
"00 00 00 00" .. -- TS_UD_CS_CORE::serialNumber
"18 00" .. -- TS_UD_CS_CORE::highColorDepth = 24 bpp
"07 00" .. -- TS_UD_CS_CORE::supportedColorDepths = 24 bpp

"01 00" .. -- TS_UD_CS_CORE::earlyCapabilityFlags

 

"00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 " ..
"00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 " ..
"00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 " ..
"00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 " .. -- TS_UD_CS_CORE::clientDigProductId

07 -> TS_UD_CS_CORE::connectionType = 7
00 -> TS_UD_CS_CORE::pad1octet

01 00 00 00 -> TS_UD_CS_CORE::serverSelectedProtocol
#---------------

04 c0 0c 00 -> TS_UD_HEADER::type = CS_CLUSTER (0xc004), length = 12 bytes

"15 00 00 00" .. -- TS_UD_CS_CLUSTER::Flags = 0x15 f (REDIRECTION_SUPPORTED | REDIRECTION_VERSION3)
"00 00 00 00" .. -- TS_UD_CS_CLUSTER::RedirectedSessionID

#------------

"02 c0 0c 00" -- TS_UD_HEADER::type = CS_SECURITY (0xc002), length = 12 bytes
"1b 00 00 00" .. -- TS_UD_CS_SEC::encryptionMethods

"00 00 00 00" .. -- TS_UD_CS_SEC::extEncryptionMethods

"03 c0 38 00" .. -- TS_UD_HEADER::type = CS_NET (0xc003), length = 0x38 bytes

In this package we need to set the user channels, and a MS_T120 channel needs to be included in the list.

Erect Domain Package

Image
Erect Domain Package

Text

 0x04: type ErectDomainRequest

  0x01:  subHeight length = 1 byte

  0x00 : subHeight = 0

  0x01:  subInterval length = 1 byte

  0x00:  subInterval = 0

 

User Attach Packet package

Image
User Attach Packet package

Text

We need to analyze the response.

03 00 00 0b 02 f0 80 2e 00 00 07

Image
03 00 00 0b 02 f0 80 2e 00 00 07

Text

The last byte is the initiator, we need to strip from the response to use in the next packet.

Channel Join request package

Building the package

              xv1 = (chan_num) / 256   

             val = (chan_num) % 256   

             
'\x03\x00\x00\x0c\x02\xf0\x80\x38\x00' + initiator + chr(xv1) + chr(val) 

For channel 1003 by example

              xv1 = (1003) / 256   = 3 

             val = (1003) % 256   = 235

             
'\x03\x00\x00\x0c\x02\xf0\x80\x38\x00' + initiator + chr(3) + chr(235) 

Image
'\x03\x00\x00\x0c\x02\xf0\x80\x38\x00' + initiator + chr(3) + chr(235)

Text

0x38: channelJoinRequest (14)

Image
0x38: channelJoinRequest (14)

Text

All channel join packages are similar, the only thing that changes are the last two bytes that correspond to the channel number. 

Channel Join Confirm Response package

The response was

03 00 00 0f 02 f0 80 3e 00 00 07 03 eb 03 eb

0x3e:channelJoinConfirm (15)

Image
0x3e:channelJoinConfirm (15)

Text

result: rt_succesful (0x0)

The packet has the same initiator and channelid values than the request to the same channel.

 

When all the channels response the Join Request, the next package sended is send Data Request.

Image
Join Request

Text

Client Info PDU or Send Data Request Package

Image
Client Info PDU

Text

The remaining packages are important for the exploitation, so for now we will not show them in this first delivery.

STEP 7) The vulnerability

The program allocate a channel MS_T120 by default, the user can set different channels in the packages.

This is the diff of the function named IcabindVirtualChannels

Image
IcabindVirtualChannels

Text

This is the patch for the Windows XP version, which its logic is similar for every vulnerable windows version, when the program compares the string MS_T120 with the name of each channel, the pointer is forced to be stored in a fixed position of the table, forcing to use the value 0x1f to calculate the place to save it .

In the vulnerable version, the pointer is stored using the channel number to calculate the position in the channel table, and we will have two pointers stored in different locations, pointing to the same chunk.

If the user set a channel MS_T120 and send crafted data to that channel, the program will allocate a chunk for that, but will store two different pointers to that chunk, after that the program frees the chunk, but the data of the freed chunk is incorrectly accessed, performing a USE AFTER FREE vulnerability.

The chunk is freed here

Image
chunk is freed

Text

Then the chunk is accessed after the free here, EBX will point to the freed chunk.

Image
chunk is accessed

Text

If a perfect pool spray is performed, using the correct chunk size, we can control the execution flow, the value of EAX controlled by us, EBX point to our chunk, EAX =[EBX+0x8c] is controlled by us too.

Image
perfect pool spray

Text

STEP 8) Pool spray

There is a point in the code that let us allocate our data with size controlled, and the same type of pool.

Image
size controlled

Text

We can send bunch of crafted packages to reach this point, if this packages have the right size can fill the freed chunk, with our data.

In order to get the right size is necessary look at the function IcaAllocateChannel.

In Windows 7 32 bits, the size of each chunk of the pool spray should be 0xc8.

Image
Windows 7 32 bits

Text

For Windows XP 32 bits that size should be 0x8c.

Image
Windows XP 32 bits

Text

This pool spray remain in this loop allocating with the right size, and we can fill the freed chunk with our own data to control the code execution in the CALL (IcaChannelInputInternal + 0x118)

 

11/13/2019: Core Impact was updated for Bluekeep module CVE-2019-0708 to include support for Windows 7 Professional Edition – sp1 (x86_64) and added stability improvements.