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.
Also in PROCESS EXPLORER you can easily identify which of the SVChosts is the one that handles RDP connections.(Remote Desktop Services)
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.
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
the execution continues here
here
here
IcaOpen is called
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
We arrived to IcaDispatch when opening the driver.
Reversing we can see
The MajorFunction value is read here
As MajorFuncion equals 0 it takes us to IcaCreate
Inside IcaCreate, SystemBuffer is equal to 0
A chunk of size 0x298 and tag ciST is created, and I call it chunk_CONNECTION.
chunk_CONNECTION is stored in FILE_OBJECT.FsContext
I rename FsContext to FsContext_chunk_CONNECTION.
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
When that call ends an instance of the class Cstack is created
And the class constructor is called.
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
The second call returns to
00000000`06d0f7c0 000007fe`f7dc04bd rdpcorekmts!CKMRDPConnection::InitializeInstance+0x21d
And this second call continues to
Next
Next
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.
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
in the decompiled code
Previously IRP is moved to r12
That address is accessed many times over there, so the only way to stop when it is nonzero is to use a conditional breakpoint.
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.
We arrived at this code, the variable named "contador" is zero, for this reason, we landed in IcaCreateStack.
In IcaCreateStack a new fragment of size 0xBA8 is allocated, I call it chunk_stack_0xBA8.
I comment the conditional breakpoint part, to avoid stopping and only keep logging.
I repeat the process to get a new fresh log.
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.
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.
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.
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.
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.
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.
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)
This will dump the bytes perfectly to the file.
I will use this script in the conditional breakpoint.
This script made a raw dump, but wireshark only imports in this format.
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.
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.
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"
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
That file will be decoded as TPKT in wireshark.
That's the complete script.
Using that script, the dump file is created, when it is imported as a hexadecimal file in Wireshark, it is displayed perfectly.
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.
We can see that there are a few more calls before starting to receive data, a couple more calls to the driver.
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.
It will stop when MajorFunction = 0xE
We arrived at IcaDeviceControl.
We can see that this call is generated when the program accepts the connection, calling ZwDeviceIoControlFile next.
We can see that IRP and IO_STACK_LOCATION are maintained with the same value, fileobject has changed.
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.
The previous FILE_OBJECT was an object that was obtained from ObReferenceObjectByHandle.
The new FILE_OBJECT has the same structure but is a different object, for that reason we create a new structure for this.
We continue reversing ProbeAndCaptureUserBuffers
A new chunk with the size (InputBufferLenght + OutputBufferLenght) is created.
Stores the pointers to the Input and Output buffers chunks.
We can see that IcaUserProbeAddress is similar to nt! MmUserProbeAddress value
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)
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.
Since the OutputBufferLength is zero, it will not copy from OutputUserBuffer to the chunk_OutputBuffer.
Clears chunk_OutputBuffer and return.
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
The variable "resource" points to IcaStackDispatchTable.
I frame the area of the table and create a structure from memory which I call _IcaStackDispatchTable.
I entered and started to reverse this function.
The first time we arrived here, the IOCTL value is 38002b.
We arrived to a call to _IcaPushStack.
Inside two allocations are performed, i named them chunk_PUSH_STACK_0x488 and chunk_PUSH_STACK_0xA8
When IOCTL value 0x38002b is used, we reach _IcaLoadSd
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
These IOCTLs also reach _IcaCallSd
IOCTL 0x380148 does nothing
IOCTL 0x380173 reaches _IcaDriverThread
And this last one reaches tdtcp_TdInputThread also.
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.
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
Requested Protocol
Negotiation Response package
The Response package was similar only with Type=0x2 RDP Negotiation Response
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
0x04: type ErectDomainRequest
0x01: subHeight length = 1 byte
0x00 : subHeight = 0
0x01: subInterval length = 1 byte
0x00: subInterval = 0
User Attach Packet package
We need to analyze the response.
03 00 00 0b 02 f0 80 2e 00 00 07
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)
0x38: channelJoinRequest (14)
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)
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.
Client Info PDU or Send Data Request Package
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
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
Then the chunk is accessed after the free here, EBX will point to the freed chunk.
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.
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.
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.
For Windows XP 32 bits that size should be 0x8c.
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.