吾愛破解 - LCG - LSG |安卓破解|病毒分析|破解軟件|www.vuyuem.live

 找回密碼
 注冊[Register]

QQ登錄

只需一步,快速開始

搜索
查看: 14790|回復: 117
上一主題 下一主題

[漏洞分析] CVE-2019-0708 微軟遠程桌面服務遠程代碼執行漏洞之漏洞分析與漏洞利用簡介

    [復制鏈接]
跳轉到指定樓層
樓主
giantbranch 發表于 2019-10-16 10:06 回帖獎勵

漏洞簡述

因為MS_T120這個channel是內部Channel,MS_T120 Channel被綁定兩次(內部綁定一次,然后我們又綁定一次——id不是31)。由于綁定的時候沒有限制,所以綁定在兩個不同的ID下,因此MS_T120 Channel就有兩個引用,假如我們關閉channel,就觸發一次free,而我們斷開連接系統默認也會free,那就變成了Double Free了(其實Double Free是UAF的特殊情況,因為這個USE是free而已)。

實驗環境

win 7 32位 旗艦版

漏洞分析

發送POC

kd> g

*** Fatal System Error: 0x0000000a
                       (0x00000000,0x00000002,0x00000001,0x840ED940)

Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

Connected to Windows 7 7600 x86 compatible target at (Sun Sep 29 16:59:07.622 2019 (UTC + 8:00)), ptr64 FALSE
Loading Kernel Symbols
...............................................................
................................................................
...............................
Loading User Symbols
................................................................
....................
Loading unloaded module list
.........
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {0, 2, 1, 840ed940}

Probably caused by : termdd.sys ( termdd!_IcaFreeChannel+44 )

Followup: MachineOwner
---------

nt!RtlpBreakWithStatusInstruction:
840b2394 cc              int     3
kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
    bit 0 : value 0 = read operation, 1 = write operation
    bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 840ed940, address which referenced memory

Debugging Details:
------------------

WRITE_ADDRESS:  00000000 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!ExDeleteResourceLite+87
840ed940 8901            mov     dword ptr [ecx],eax

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  svchost.exe

TRAP_FRAME:  90cc68ac -- (.trap 0xffffffff90cc68ac)
ErrCode = 00000002
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=841b0280 edi=8a998884
eip=840ed940 esp=90cc6920 ebp=90cc6934 iopl=0         nv up ei pl zr na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246
nt!ExDeleteResourceLite+0x87:
840ed940 8901            mov     dword ptr [ecx],eax  ds:0023:00000000=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from 84123e71 to 840b2394

STACK_TEXT:  
90cc6474 84123e71 00000003 8fa1ca4b 00000065 nt!RtlpBreakWithStatusInstruction
90cc64c4 8412496d 00000003 00000000 840ed940 nt!KiBugCheckDebugBreak+0x1c
90cc688c 8408d7eb 0000000a 00000000 00000002 nt!KeBugCheck2+0x68b
90cc688c 840ed940 0000000a 00000000 00000002 nt!KiTrap0E+0x2cf
90cc6934 90237da2 8a998884 868a7c98 8a998878 nt!ExDeleteResourceLite+0x87
90cc6948 90238060 8a998878 8a998884 868b5670 termdd!_IcaFreeChannel+0x44
90cc6964 9023895f 8a998878 868b5670 00000000 termdd!IcaDereferenceChannel+0x34
90cc69a0 90239354 868b5670 00000005 0000001f termdd!IcaChannelInputInternal+0x3a7
90cc69c8 a60c5dc9 88cc2e24 00000005 0000001f termdd!IcaChannelInput+0x3c
90cc6a00 a60c5e31 a6232008 88cc2e20 88cc2e10 RDPWD!SignalBrokenConnection+0x40
90cc6a18 9023937f a5f73008 00000004 00000000 RDPWD!MCSIcaChannelInput+0x55
90cc6a44 a609d436 88e14884 00000004 00000000 termdd!IcaChannelInput+0x67
90cc726c a609d090 88e14880 88c525a8 840137a0 tssecsrv!CDefaultDataManager::Disconnect+0x3c
90cc72a4 a609ca16 90cc72b4 88e14870 a60a0118 tssecsrv!CFilter::FilterIncomingData+0x222
90cc72d0 9023c772 88c525a8 00000000 868a1cb4 tssecsrv!ScrRawInput+0x60
90cc72f4 a60936a9 868195c4 00000000 868a1cb4 termdd!IcaRawInput+0x5a
90cc7b30 9023b56d 868a1b68 8911f330 8844dc58 tdtcp!TdInputThread+0x34d
90cc7b4c 9023b67c 89073800 00380173 8911f3a0 termdd!_IcaDriverThread+0x53
90cc7b74 9023c00c 8844dc58 8911f330 868b5670 termdd!_IcaStartInputThread+0x6c
90cc7bb4 90239e91 868b5670 8911f330 8911f3a0 termdd!IcaDeviceControlStack+0x50a
90cc7be4 9023a065 8911f330 8911f3a0 88f3ce68 termdd!IcaDeviceControl+0x59
90cc7bfc 840834bc 87c0cbb0 8911f330 8911f330 termdd!IcaDispatch+0x13f
90cc7c14 84284eee 88f3ce68 8911f330 8911f3a0 nt!IofCallDriver+0x63
90cc7c34 842a1cd1 87c0cbb0 88f3ce68 00000000 nt!IopSynchronousServiceTail+0x1f8
90cc7cd0 842a44ac 87c0cbb0 8911f330 00000000 nt!IopXxxControlFile+0x6aa
90cc7d04 8408a42a 0000096c 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
90cc7d04 776b64f4 0000096c 00000000 00000000 nt!KiFastCallEntry+0x12a
031cfc4c 776b4cac 6f5b18a7 0000096c 00000000 ntdll!KiFastSystemCallRet
031cfc50 6f5b18a7 0000096c 00000000 00000000 ntdll!NtDeviceIoControlFile+0xc
031cfc8c 6f5b25e9 0000096c 00380173 0037f0e0 ICAAPI!IcaIoControl+0x29
031cfcbc 77811174 80000000 031cfd08 776cb3f5 ICAAPI!IcaInputThreadUserMode+0x37
031cfcc8 776cb3f5 0037f0d8 74694ddb 00000000 kernel32!BaseThreadInitThunk+0xe
031cfd08 776cb3c8 6f5b25b2 0037f0d8 00000000 ntdll!__RtlUserThreadStart+0x70
031cfd20 00000000 6f5b25b2 0037f0d8 00000000 ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND:  kb

FOLLOWUP_IP: 
termdd!_IcaFreeChannel+44
90237da2 8d4644          lea     eax,[esi+44h]

SYMBOL_STACK_INDEX:  5

SYMBOL_NAME:  termdd!_IcaFreeChannel+44

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: termdd

IMAGE_NAME:  termdd.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bcadf

FAILURE_BUCKET_ID:  0xA_termdd!_IcaFreeChannel+44

BUCKET_ID:  0xA_termdd!_IcaFreeChannel+44

Followup: MachineOwner
---------

可以看到是termdd!_IcaFreeChannel調用nt!ExDeleteResourceLite后崩潰了

在free的時候崩潰,那么很有可能就是double free了

IcaRebindVirtualChannelsIcaBindVirtualChannels中我們都可以看到IcaFindChannelByName函數,我們看看這個函數,通過這個我們知道channelname是在0x94偏移

int __stdcall IcaFindChannelByName(int a1, int a2, char *a3)
{
  int v4; // ebx
  _DWORD *v5; // esi
  int v6; // edi

  if ( a2 != 5 )
    return IcaFindChannel(a1, a2, 0);
  IcaLockChannelTable(a1 + 272);
  v4 = a1 + 80;
  v5 = *(_DWORD **)(a1 + 80);
  if ( v5 == (_DWORD *)(a1 + 80) )
    goto LABEL_14;
  do
  {
    v6 = (int)(v5 - 40);
    if ( *(v5 - 4) == 5 && !__stricmp((const char *)(v6 + 0x94), a3) )   //通過這個我們知道channelname是在0x94偏移
      break;
    v5 = (_DWORD *)*v5;
  }
  while ( v5 != (_DWORD *)v4 );
  if ( v5 != (_DWORD *)v4 )
    _InterlockedExchangeAdd((volatile signed __int32 *)(v6 + 8), 1u);
  else
LABEL_14:
    v6 = 0;
  IcaUnlockChannelTable(a1 + 272);
  return v6;
}

通過上面棧回溯的這一行,我們可以看到free的地址是8a998878

90cc6948 90238060 8a998878 8a998884 868b5670 termdd!_IcaFreeChannel+0x44

看看channel name是不是MS_T120(0x94這個偏移,系統不同,應該不一樣的)

kd> da 8a998878+0x94 
8a99890c  "MS_T120"

可以看到確實是的,我們現在還不能完全確認是MS_T120 channel的UAF。

要進入步確認我們就需要看看這個MS_T120 channel實在哪里創建,是不是釋放了兩次

現在free函數已經知道了,那么申請內存的函數呢?

我們看看有哪些函數調用了IcaFindChannelByName

可以看到有一個IcaCreateChannel函數,很可能就是創建Channel,申請內存的函數,我們跟過去,又發現一個_IcaAllocateChannel

進去看看,看到申請的函數了,就是它了

那我們下兩個記錄斷點(這個需要查看匯編,看看ExAllocatePoolWithTag的返回值,還有_IcaFreeChannel的參數

bu termdd!_IcaAllocateChannel+0x1c ".printf \"AllocateChannel Addresss: 0x%x\n\",@eax;.echo;gc"
bu termdd!_IcaFreeChannel ".printf \"FreeChannel Addresss: 0x%x\n\",@esi;.echo;gc"

再發送poc

發送payload

AllocateChannel Addresss: 0x88eecf38 
AllocateChannel Addresss: 0x892b4df0 
AllocateChannel Addresss: 0x86a10d08 
AllocateChannel Addresss: 0x87c63688 
AllocateChannel Addresss: 0x88f6e1a8 
AllocateChannel Addresss: 0x892b4818 
FreeChannel Addresss: 0x88eecf38 
FreeChannel Addresss: 0x88f6e1a8 
FreeChannel Addresss: 0x892b4818 
FreeChannel Addresss: 0x87c63688 
FreeChannel Addresss: 0x86a10d08 
FreeChannel Addresss: 0x892b4df0 
AllocateChannel Addresss: 0x88f6e1a8 
AllocateChannel Addresss: 0x892bfc10 
AllocateChannel Addresss: 0x88eecf38 
AllocateChannel Addresss: 0x87c63688 
AllocateChannel Addresss: 0x892b4df0 
AllocateChannel Addresss: 0x86a95c50 
FreeChannel Addresss: 0x88f6e1a8 
FreeChannel Addresss: 0x88f6e1a8 

*** Fatal System Error: 0x0000000a
                       (0x00000000,0x00000002,0x00000001,0x840ED940)

Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

Connected to Windows 7 7600 x86 compatible target at (Fri Sep 27 15:29:54.017 2019 (UTC + 8:00)), ptr64 FALSE
Loading Kernel Symbols
...............................................................
................................................................
..............................
Loading User Symbols
................................................................
....................
Loading unloaded module list
......
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {0, 2, 1, 840ed940}

Probably caused by : termdd.sys ( termdd!_IcaFreeChannel+44 )

Followup: MachineOwner
---------

nt!RtlpBreakWithStatusInstruction:
840b2394 cc              int     3

我們看到,對0x88f6e1a8這個地址free了兩次

FreeChannel Addresss: 0x88f6e1a8 
FreeChannel Addresss: 0x88f6e1a8 

那就完全確認這個是UAF,也可以說是DOUBLE FREE(2 free)

在上面的基礎,我們再下一個斷點,看看是否同一個channel綁定了兩個ID

bu termdd!_IcaBindChannel ".echo _IcaBindChannel ==================;kv;gc"

我已經把垃圾信息過濾了,日志如下:

kd> g
AllocateChannel Addresss: 0x88fd5738 
_IcaBindChannel ==================
ChildEBP RetAddr  Args to Child              
a52c99e0 90238be9 88fd5738 00000005 0000001f termdd!_IcaBindChannel (FPO: [Non-Fpo])
a52c9a04 90238d5e 8b1788e9 00000005 891282a7 termdd!_IcaAllocateChannel+0xf1 (FPO: [Non-Fpo])
a52c9a28 90240177 88f9b6b0 00000005 88b89648 termdd!IcaCreateChannel+0x6c (FPO: [Non-Fpo])
a52c9a58 9023a019 88b89648 88b896b8 869454d0 termdd!IcaCreate+0x13d (FPO: [Non-Fpo])
a52c9a70 840834bc 87c0cbb0 88b89648 8694552c termdd!IcaDispatch+0xf3 (FPO: [Non-Fpo])
a52c9a88 8428762d ba4135ef a52c9c30 00000000 nt!IofCallDriver+0x63
a52c9b60 842681d7 87c0cbb0 a57ff6e0 87bf5858 nt!IopParseDevice+0xed7
a52c9bdc 8428e24d 00000000 a52c9c30 00000040 nt!ObpLookupObjectName+0x4fa
a52c9c38 842865ab 013ae714 867ff6e0 a52c9c01 nt!ObOpenObjectByName+0x159
a52c9cb4 84291eb6 03251114 c0100000 013ae714 nt!IopCreateFile+0x673
a52c9d00 8408a42a 03251114 c0100000 013ae714 nt!NtCreateFile+0x34
a52c9d00 776b64f4 03251114 c0100000 013ae714 nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame home.php?mod=space&uid=402414 a52c9d34)
......
......
......
_IcaBindChannel ==================
ChildEBP RetAddr  Args to Child              
a52c9960 9023949b 88fd5738 00000005 00000003 termdd!_IcaBindChannel (FPO: [Non-Fpo])
a52c9b74 9023bf90 86818670 88f17708 86818670 termdd!IcaBindVirtualChannels+0x101 (FPO: [Non-Fpo])
a52c9bb4 90239e91 86818670 88f17708 88f17778 termdd!IcaDeviceControlStack+0x48e (FPO: [Non-Fpo])
a52c9be4 9023a065 88f17708 88f17778 89187758 termdd!IcaDeviceControl+0x59 (FPO: [Non-Fpo])
a52c9bfc 840834bc 87c0cbb0 88f17708 88f17708 termdd!IcaDispatch+0x13f (FPO: [Non-Fpo])
a52c9c14 84284eee 89187758 88f17708 88f17778 nt!IofCallDriver+0x63
a52c9c34 842a1cd1 87c0cbb0 89187758 00000000 nt!IopSynchronousServiceTail+0x1f8
a52c9cd0 842a44ac 87c0cbb0 88f17708 00000000 nt!IopXxxControlFile+0x6aa
a52c9d04 8408a42a 00000840 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
a52c9d04 776b64f4 00000840 00000000 00000000 nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ a52c9d34)
......
......
......
FreeChannel Addresss: 0x88fd5738 
FreeChannel Addresss: 0x88fd5738 

我們首先確定0x88fd5738這個地址的channel是不是MS_T120

kd> da 0x88fd5738+0x94
88fd57cc  "MS_T120"

再看看termdd!_IcaBindChannel 的棧,針對的都是88fd5738這個地址,但是我們看第3個參數第一次是0x1f(其實就是十進制的31),而第二次是03,那就明顯看到將同一個channel綁定了兩個ID,導致有了兩個引用,所以修復的時候強制指定為31,不管你綁定多少次,ID都是31

a52c99e0 90238be9 88fd5738 00000005 0000001f termdd!_IcaBindChannel (FPO: [Non-Fpo])

a52c9960 9023949b 88fd5738 00000005 00000003 termdd!_IcaBindChannel (FPO: [Non-Fpo])

最后我們再來看看他們調用棧的不同點

第一個調用棧,可以看到從NtCreateFile到termdd!IcaDispatch再到termdd!IcaCreateChannel,就是系統創建的這個channel,分配這個channel后進行了_IcaBindChannel操作

ChildEBP RetAddr  Args to Child         
a52c99e0 90238be9 88fd5738 00000005 0000001f termdd!_IcaBindChannel (FPO: [Non-Fpo])
a52c9a04 90238d5e 8b1788e9 00000005 891282a7 termdd!_IcaAllocateChannel+0xf1 (FPO: [Non-Fpo])
a52c9a28 90240177 88f9b6b0 00000005 88b89648 termdd!IcaCreateChannel+0x6c (FPO: [Non-Fpo])
a52c9a58 9023a019 88b89648 88b896b8 869454d0 termdd!IcaCreate+0x13d (FPO: [Non-Fpo])
a52c9a70 840834bc 87c0cbb0 88b89648 8694552c termdd!IcaDispatch+0xf3 (FPO: [Non-Fpo])
a52c9a88 8428762d ba4135ef a52c9c30 00000000 nt!IofCallDriver+0x63
a52c9b60 842681d7 87c0cbb0 a57ff6e0 87bf5858 nt!IopParseDevice+0xed7
a52c9bdc 8428e24d 00000000 a52c9c30 00000040 nt!ObpLookupObjectName+0x4fa
a52c9c38 842865ab 013ae714 867ff6e0 a52c9c01 nt!ObOpenObjectByName+0x159
a52c9cb4 84291eb6 03251114 c0100000 013ae714 nt!IopCreateFile+0x673
a52c9d00 8408a42a 03251114 c0100000 013ae714 nt!NtCreateFile+0x34
a52c9d00 776b64f4 03251114 c0100000 013ae714 nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ a52c9d34)
......
......
......

而第二次明顯是由我們觸發的,termdd!IcaDeviceControl到termdd!IcaBindVirtualChannels

ChildEBP RetAddr  Args to Child              
a52c9960 9023949b 88fd5738 00000005 00000003 termdd!_IcaBindChannel (FPO: [Non-Fpo])
a52c9b74 9023bf90 86818670 88f17708 86818670 termdd!IcaBindVirtualChannels+0x101 (FPO: [Non-Fpo])
a52c9bb4 90239e91 86818670 88f17708 88f17778 termdd!IcaDeviceControlStack+0x48e (FPO: [Non-Fpo])
a52c9be4 9023a065 88f17708 88f17778 89187758 termdd!IcaDeviceControl+0x59 (FPO: [Non-Fpo])
a52c9bfc 840834bc 87c0cbb0 88f17708 88f17708 termdd!IcaDispatch+0x13f (FPO: [Non-Fpo])
a52c9c14 84284eee 89187758 88f17708 88f17778 nt!IofCallDriver+0x63
a52c9c34 842a1cd1 87c0cbb0 89187758 00000000 nt!IopSynchronousServiceTail+0x1f8
a52c9cd0 842a44ac 87c0cbb0 88f17708 00000000 nt!IopXxxControlFile+0x6aa
a52c9d04 8408a42a 00000840 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
a52c9d04 776b64f4 00000840 00000000 00000000 nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ a52c9d34)
......
......
......

那么到最后我們我們關閉連接,我們綁定的MS_T120 channel  free了一次,系統自己再free一次,那就造成了double free了

可以看看最后兩次free的調用棧,第一次我們主動釋放了ID 為03的channel,第二次是我們關閉了連接導致的釋放(ID為31),明顯看到第二次的棧上有tssecsrv!CDefaultDataManager::Disconnect(由于多次調試,下面的跟上面的地址會不一樣)

FreeChannel Addresss: 0x88ca9d48 
ChildEBP RetAddr  Args to Child              
8e653a10 90238060 88ca9d48 00000000 891e19a8 termdd!_IcaFreeChannel (FPO: [Non-Fpo])
8e653a2c 90238949 88ca9d48 890a0670 00000000 termdd!IcaDereferenceChannel+0x34 (FPO: [Non-Fpo])
8e653a68 90239354 890a0670 00000005 00000003 termdd!IcaChannelInputInternal+0x391 (FPO: [Non-Fpo])
8e653a90 945be1cf 8a9fb0d4 00000005 00000003 termdd!IcaChannelInput+0x3c (FPO: [Non-Fpo])
8e653ab0 945c1548 8a9fb0d4 00000005 00000003 RDPWD!WDICART_IcaChannelInputEx+0x1d (FPO: [Non-Fpo])
8e654148 945bbe42 a41c3008 8a9e9682 00000014 RDPWD!WDW_OnDataReceived+0x240 (FPO: [Non-Fpo])
8e654174 945bbbfd a41c38f0 a41e7134 00000000 RDPWD!SM_MCSSendDataCallback+0x19a (FPO: [Non-Fpo])
8e6541cc 945bba64 00000027 8e654204 8a9e9674 RDPWD!HandleAllSendDataPDUs+0x115 (FPO: [Non-Fpo])
8e6541e8 945d7958 00000027 8e654204 8a9fb0d0 RDPWD!RecognizeMCSFrame+0x32 (FPO: [Non-Fpo])
8e654214 945be63f a41c3008 8a9e96a2 00000001 RDPWD!MCSIcaRawInputWorker+0x3b4 (FPO: [Non-Fpo])
8e654228 9023c772 a41c3008 00000000 8a9e9674 RDPWD!WDLIB_MCSIcaRawInput+0x13 (FPO: [Non-Fpo])
8e65424c 945af46d 8a95a0c4 00000000 8a9e9674 termdd!IcaRawInput+0x5a (FPO: [Non-Fpo])
8e654264 945aef06 8a9e9674 0000002f 8a95a0c0 tssecsrv!CRawInputDM::PassDataToServer+0x2b (FPO: [Non-Fpo])
8e6542a4 945aea16 8e6542b4 8a95a0b0 945b2118 tssecsrv!CFilter::FilterIncomingData+0x98 (FPO: [Non-Fpo])
8e6542d0 9023c772 88c85050 00000000 8a9e9674 tssecsrv!ScrRawInput+0x60 (FPO: [Non-Fpo])
8e6542f4 945a56a9 8918c284 00000000 8a9e9674 termdd!IcaRawInput+0x5a (FPO: [Non-Fpo])
8e654b30 9023b56d 8a9e9528 88580158 8a981b68 tdtcp!TdInputThread+0x34d (FPO: [Non-Fpo])
8e654b4c 9023b67c 8a9f5878 00380173 885801c8 termdd!_IcaDriverThread+0x53 (FPO: [Non-Fpo])
8e654b74 9023c00c 8a981b68 88580158 890a0670 termdd!_IcaStartInputThread+0x6c (FPO: [Non-Fpo])
8e654bb4 90239e91 890a0670 88580158 885801c8 termdd!IcaDeviceControlStack+0x50a (FPO: [Non-Fpo])
8e654be4 9023a065 88580158 885801c8 890a1360 termdd!IcaDeviceControl+0x59 (FPO: [Non-Fpo])
8e654bfc 840834bc 87c0cbb0 88580158 88580158 termdd!IcaDispatch+0x13f (FPO: [Non-Fpo])
8e654c14 84284eee 890a1360 88580158 885801c8 nt!IofCallDriver+0x63
8e654c34 842a1cd1 87c0cbb0 890a1360 00000000 nt!IopSynchronousServiceTail+0x1f8
8e654cd0 842a44ac 87c0cbb0 88580158 00000000 nt!IopXxxControlFile+0x6aa
8e654d04 8408a42a 000007f4 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
8e654d04 776b64f4 000007f4 00000000 00000000 nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 8e654d34)
037af99c 776b4cac 6f5b18a7 000007f4 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
037af9a0 6f5b18a7 000007f4 00000000 00000000 ntdll!NtDeviceIoControlFile+0xc (FPO: [10,0,0])
037af9dc 6f5b25e9 000007f4 00380173 029916f8 ICAAPI!IcaIoControl+0x29 (FPO: [Non-Fpo])
037afa0c 77811174 80000000 037afa58 776cb3f5 ICAAPI!IcaInputThreadUserMode+0x37 (FPO: [Non-Fpo])
037afa18 776cb3f5 029916f0 740f4a8b 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])
037afa58 776cb3c8 6f5b25b2 029916f0 00000000 ntdll!__RtlUserThreadStart+0x70 (FPO: [Non-Fpo])
037afa70 00000000 6f5b25b2 029916f0 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])
FreeChannel Addresss: 0x88ca9d48 
ChildEBP RetAddr  Args to Child              
8e653948 90238060 88ca9d48 88ca9d54 890a0670 termdd!_IcaFreeChannel (FPO: [Non-Fpo])
8e653964 9023895f 88ca9d48 890a0670 00000000 termdd!IcaDereferenceChannel+0x34 (FPO: [Non-Fpo])
8e6539a0 90239354 890a0670 00000005 0000001f termdd!IcaChannelInputInternal+0x3a7 (FPO: [Non-Fpo])
8e6539c8 945d7dc9 8a9fb0d4 00000005 0000001f termdd!IcaChannelInput+0x3c (FPO: [Non-Fpo])
8e653a00 945d7e31 a41e7008 8a9fb0d0 8a9fb0c0 RDPWD!SignalBrokenConnection+0x40 (FPO: [Non-Fpo])
8e653a18 9023937f a41c3008 00000004 00000000 RDPWD!MCSIcaChannelInput+0x55 (FPO: [Non-Fpo])
8e653a44 945af436 8a95a0c4 00000004 00000000 termdd!IcaChannelInput+0x67 (FPO: [Non-Fpo])
8e65426c 945af090 8a95a0c0 88c85050 840137a0 tssecsrv!CDefaultDataManager::Disconnect+0x3c (FPO: [Non-Fpo])
8e6542a4 945aea16 8e6542b4 8a95a0b0 945b2118 tssecsrv!CFilter::FilterIncomingData+0x222 (FPO: [Non-Fpo])
8e6542d0 9023c772 88c85050 00000000 8a9e9674 tssecsrv!ScrRawInput+0x60 (FPO: [Non-Fpo])
8e6542f4 945a56a9 8918c284 00000000 8a9e9674 termdd!IcaRawInput+0x5a (FPO: [Non-Fpo])
8e654b30 9023b56d 8a9e9528 88580158 8a981b68 tdtcp!TdInputThread+0x34d (FPO: [Non-Fpo])
8e654b4c 9023b67c 8a9f5878 00380173 885801c8 termdd!_IcaDriverThread+0x53 (FPO: [Non-Fpo])
8e654b74 9023c00c 8a981b68 88580158 890a0670 termdd!_IcaStartInputThread+0x6c (FPO: [Non-Fpo])
8e654bb4 90239e91 890a0670 88580158 885801c8 termdd!IcaDeviceControlStack+0x50a (FPO: [Non-Fpo])
8e654be4 9023a065 88580158 885801c8 890a1360 termdd!IcaDeviceControl+0x59 (FPO: [Non-Fpo])
8e654bfc 840834bc 87c0cbb0 88580158 88580158 termdd!IcaDispatch+0x13f (FPO: [Non-Fpo])
8e654c14 84284eee 890a1360 88580158 885801c8 nt!IofCallDriver+0x63
8e654c34 842a1cd1 87c0cbb0 890a1360 00000000 nt!IopSynchronousServiceTail+0x1f8
8e654cd0 842a44ac 87c0cbb0 88580158 00000000 nt!IopXxxControlFile+0x6aa
8e654d04 8408a42a 000007f4 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
8e654d04 776b64f4 000007f4 00000000 00000000 nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ 8e654d34)
037af99c 776b4cac 6f5b18a7 000007f4 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
037af9a0 6f5b18a7 000007f4 00000000 00000000 ntdll!NtDeviceIoControlFile+0xc (FPO: [10,0,0])
037af9dc 6f5b25e9 000007f4 00380173 029916f8 ICAAPI!IcaIoControl+0x29 (FPO: [Non-Fpo])
037afa0c 77811174 80000000 037afa58 776cb3f5 ICAAPI!IcaInputThreadUserMode+0x37 (FPO: [Non-Fpo])
037afa18 776cb3f5 029916f0 740f4a8b 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])
037afa58 776cb3c8 6f5b25b2 029916f0 00000000 ntdll!__RtlUserThreadStart+0x70 (FPO: [Non-Fpo])
037afa70 00000000 6f5b25b2 029916f0 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])

漏洞利用簡介

由于是double free,其實就是uaf利用思路,我們在第二次free的時候向上回溯

ChildEBP RetAddr  Args to Child              
8e653948 90238060 88ca9d48 88ca9d54 890a0670 termdd!_IcaFreeChannel (FPO: [Non-Fpo])
8e653964 9023895f 88ca9d48 890a0670 00000000 termdd!IcaDereferenceChannel+0x34 (FPO: [Non-Fpo])
8e6539a0 90239354 890a0670 00000005 0000001f termdd!IcaChannelInputInternal+0x3a7 (FPO: [Non-Fpo])

發現IcaChannelInputInternal有虛函數調用,可以從這劫持控制流

看匯編也就是這里劫持控制流

要控制channel的數據,必須得在其第一次free了之后占位,我們申請同樣大小的內存

我們看到申請的大小是0xc8

那么只要控制channel內存的0x8C偏移,劫持v12虛函數指針

但是我們要劫持到哪呢,沒有信息泄露啊

現在exp的一般的做法是內核堆噴射,在Non-paged Pool進行堆噴,win7在這個地址上面是沒有DEP的,所以直接噴內核shellcode就好了,而且win7的Non-paged Pool的起始地址比較固定,那還好命中一些

一切就緒就可以劫持控制流了

我們也可以看到堆噴射出的shellcode有很多

kd> s 86000000 L 2000000 60 e8 00 00 00 00 5b e8
8688d030  60 e8 00 00 00 00 5b e8-23 00 00 00 b9 76 01 00  `.....[.#....v..
8688d088  60 e8 00 00 00 00 5b e8-cb ff ff ff 8b 45 00 83  `.....[......E..
8688d430  60 e8 00 00 00 00 5b e8-23 00 00 00 b9 76 01 00  `.....[.#....v..
8688d488  60 e8 00 00 00 00 5b e8-cb ff ff ff 8b 45 00 83  `.....[......E..
8688d830  60 e8 00 00 00 00 5b e8-23 00 00 00 b9 76 01 00  `.....[.#....v..
8688d888  60 e8 00 00 00 00 5b e8-cb ff ff ff 8b 45 00 83  `.....[......E..
8688dc30  60 e8 00 00 00 00 5b e8-23 00 00 00 b9 76 01 00  `.....[.#....v..
8688dc88  60 e8 00 00 00 00 5b e8-cb ff ff ff 8b 45 00 83  `.....[......E..
86892030  60 e8 00 00 00 00 5b e8-23 00 00 00 b9 76 01 00  `.....[.#....v..
86892088  60 e8 00 00 00 00 5b e8-cb ff ff ff 8b 45 00 83  `.....[......E..
86892430  60 e8 00 00 00 00 5b e8-23 00 00 00 b9 76 01 00  `.....[.#....v..
86892488  60 e8 00 00 00 00 5b e8-cb ff ff ff 8b 45 00 83  `.....[......E..
86892830  60 e8 00 00 00 00 5b e8-23 00 00 00 b9 76 01 00  `.....[.#....v..
86892888  60 e8 00 00 00 00 5b e8-cb ff ff ff 8b 45 00 83  `.....[......E..
86892c30  60 e8 00 00 00 00 5b e8-23 00 00 00 b9 76 01 00  `.....[.#....v..
86892c88  60 e8 00 00 00 00 5b e8-cb ff ff ff 8b 45 00 83  `.....[......E..
868c4030  60 e8 00 00 00 00 5b e8-23 00 00 00 b9 76 01 00  `.....[.#....v..
868c4088  60 e8 00 00 00 00 5b e8-cb ff ff ff 8b 45 00 83  `.....[......E..
868c4430  60 e8 00 00 00 00 5b e8-23 00 00 00 b9 76 01 00  `.....[.#....v..
868c4488  60 e8 00 00 00 00 5b e8-cb ff ff ff 8b 45 00 83  `.....[......E..
868c4830  60 e8 00 00 00 00 5b e8-23 00 00 00 b9 76 01 00  `.....[.#....v..

參考

https://github.com/n1xbyte/CVE-2019-0708

https://www.malwaretech.com/2019/05/analysis-of-cve-2019-0708-bluekeep.html

https://www.malwaretech.com/2019/09/bluekeep-a-journey-from-dos-to-rce-cve-2019-0708.html

補充資料

CVE-2019-0708 微軟遠程桌面服務遠程代碼執行漏洞分析之補丁分析

免費評分

參與人數 49吾愛幣 +50 熱心值 +45 收起 理由
章三內 + 1 + 1 [email protected]
大灰尾巴狼 + 1 + 1 [email protected]
Liu0827 + 1 + 1 歡迎分析討論交流,吾愛破解論壇有你更精彩!
bricher9988 + 1 + 1 用心討論,共獲提升!
asylm + 1 + 1 我很贊同!
nigacat + 1 + 1 [email protected]
一枝梨花 + 1 <font style="vertical-align: inherit;"><font style=
1394926200 + 1 + 1 [email protected]
dazhige + 1 + 1 鼓勵轉貼優秀軟件安全工具和文檔!
cat_mist + 1 用心討論,共獲提升!
warren_520 + 1 歡迎分析討論交流,吾愛破解論壇有你更精彩!
18889646651 + 1 + 1 我很贊同!
大塘程序員 + 1 + 1 熱心回復!
guohsm + 1 [email protected]
Yennfer_ + 1 + 1 [email protected]
也一樣約約越 + 1 + 1 雖然看不懂,但是好像很牛逼的樣子
lemon__star + 1 + 1 我很贊同!
hikansakuratan + 1 + 1 [email protected]
L.KH + 1 + 1 熱心回復!
果汁分妳一半 + 1 + 1 [email protected]
守望者warden + 1 + 1 用心討論,共獲提升!
mjyxxxxx + 1 我很贊同!
yixi + 1 + 1 [email protected]
PGdcJco + 1 + 1 用心討論,共獲提升!
lsrh2000 + 1 + 1 熱心回復!
luzhiyao + 1 + 1 感謝發布原創作品,吾愛破解論壇因你更精彩!
test_for_jiao + 1 + 1 熱心回復!
大大怪 + 1 + 1 tql
wmslecz + 1 + 1 [email protected]
wmsuper + 3 + 1 [email protected]
poisonbcat + 1 + 1 我很贊同!
greatwall001 + 1 [email protected]
E147852 + 1 + 1 熱心回復!
獨行風云 + 1 + 1 感謝發布原創作品,吾愛破解論壇因你更精彩!
N0LL + 1 + 1 [email protected]
siuhoapdou + 1 + 1 [email protected]
愛拍陰天 + 1 + 1 我很贊同!
tztt3033 + 1 + 1 用心討論,共獲提升!
Terco + 1 [email protected]
iBristlecone + 1 + 1 歡迎分析討論交流,吾愛破解論壇有你更精彩!
qn542231788 + 2 + 1 歡迎分析討論交流,吾愛破解論壇有你更精彩!
為海爾而戰 + 2 + 1 我很贊同!
gaosld + 1 + 1 感謝發布原創作品,吾愛破解論壇因你更精彩!
莫流云 + 1 + 1 歡迎分析討論交流,吾愛破解論壇有你更精彩!
抄經大弟子 + 1 + 1 熱心回復!
40m41h42t + 1 用心討論,共獲提升!
a1142099496 + 2 + 1 歡迎分析討論交流,吾愛破解論壇有你更精彩!
愛吃西柚的狼 + 1 + 1 <font style="vertical-align: inherit;"><font style=
韓老師長得帥 + 1 + 1 用心討論,共獲提升!

查看全部評分

本帖被以下淘專輯推薦:

發帖前要善用論壇搜索功能,那里可能會有你要找的答案或者已經有人發布過相同內容了,請勿重復發帖。

推薦
Quan 發表于 2019-11-4 14:57
大概看了一下,歸根到底就是因為巨硬在這里忘了做檢查 給入侵者留下機會 造成堆內存破壞 進而執行任意代碼,大概就是那版RDP協議中,在初始化連接序列的時候,安全機制還沒有啟用。
然后這個時候系統要建立信道(初始化的一部分),在那一版的RDP協議中,定義了兩種信道,一個是SVC(靜態虛擬信道),另一個是DVC(動態虛擬信道);前者(SVC)是靜態的且數量受限,在會話初始化的時候創建,直到會話結束才由系統釋放,后者(DVC)是根據用戶需求來動態創建釋放的。
前面提到了,初始化的時候系統要建立信道,所以服務端會創建一個名為MS_T120,索引值為31的信道,這個MS_T120是屬于SVC的,所以只會在內部使用,客戶看不到,而且只有會話結束了,他才會被系統釋放。忽略一些后續過程,只看關鍵:但是這個時候,問題就來了,入侵者可以通過設置另一個也叫MS_T120但是索引值不是31的SVC。
這個時候MS_T120指針就會有了兩個引用了,問題就來了,當最后關閉連接的時候,當初入侵者自己綁定的MS_T120就會被free掉一次,系統在會話結束的時候會對這個MS_T120進行釋放,等于說又free了一次,同一個指針free了兩次,最后的結果就是free了個寂寞:二次釋放導致堆內存被破壞,進而使得入侵者能夠執行任意代碼。
這就是這個漏洞大概的原理,這個漏洞其實也挺好修復,只要加一層檢測代碼,確保MS_T120和索引值31始終綁定就好了。

免費評分

參與人數 2吾愛幣 +2 熱心值 +2 收起 理由
seed + 1 + 1 通俗易懂
zycode + 1 + 1 [email protected]

查看全部評分

3#
Monitor 發表于 2019-10-16 10:43
這個我目前水平還看不懂,讓大神們相互交流吧,先做個記號。
4#
落神 發表于 2019-10-16 10:50
5#
wsb0626 發表于 2019-10-16 10:58
小白表示 看的頭暈眼花 收藏下 等我混好了 再來
6#
coolcalf 發表于 2019-10-16 11:14
然后呢? 能進入不?
7#
Danger_Robot 發表于 2019-10-16 13:24
你字多,我一句也看不懂,我也不會用
8#
167023ab 發表于 2019-10-16 13:45
我能夠看懂的部分也就只有多線程部分,向優秀的人學習
9#
愛新覺羅罹江 發表于 2019-10-16 13:50
牛逼,但我看不懂,只會用,膜拜大佬
10#
墓后煮屎者 發表于 2019-10-16 14:26
技術含量太高。。歡迎大神們來討論。
11#
xssc 發表于 2019-10-16 14:28
牛批啊。確實牛批。如何防止呢?
您需要登錄后才可以回帖 登錄 | 注冊[Register]

本版積分規則 警告:禁止回復與主題無關內容,違者重罰!

快速回復 收藏帖子 返回列表 搜索

RSS訂閱|小黑屋|聯系我們|吾愛破解 - LCG - LSG ( 京ICP備16042023號 | 京公網安備 11010502030087號 )

GMT+8, 2019-12-9 10:03

Powered by Discuz!

© 2001-2017 Comsenz Inc.

快速回復 返回頂部 返回列表
新快赢481走势图200