作者：k0shl
作者博客：http://whereisk0shl.top
前言
我是菜鳥，大牛輕噴……
這個SMBv3漏洞是由lgandx爆出的一個未被微軟修復的漏洞（暫未發布補丁），漏洞出來后我進行了一定的分析，花了很多時間，這個漏洞有一些意思，但是對于SMB的整個協議通信過程非常龐大，所以沒有進行非常細致的跟蹤，包括一些不透明的結構體讓我感到暈頭轉向，但到最后還是有了一些結果。
這個SMB漏洞可以看作是被動的，需要用戶主動去訪問445端口才可以觸發，而不像ms08067一樣主動攻擊別人，所以需要運行漏洞腳本在操作系統上。
終于趕在元宵節這天完成了這個任務，也在這里，祝大家元宵節快樂（不知道文章發布的時候過沒過元宵節23333）！
這個漏洞在twitter爆出來之后，很多老外也在微博下面問是否可以RCE，包括國內的預警中也有人問到。
http://bobao.#/learning/detail/3451.html
http://www.freebuf.com/vuls/126100.html
那么很多人看到PoC中的關鍵部分，就會想：有填充數據，會不會是緩沖區溢出！
## Tree Connect
if data[16:18] == "\x03\x00":
head = SMBv2Header(Cmd="\x03\x00", MessageId=GrabMessageID(data), PID="\xff\xfe\x00\x00", TID="\x01\x00\x00\x00", CreditCharge=GrabCreditCharged(data), Credits=GrabCreditRequested(data), NTStatus="\x00\x00\x00\x00", SessionID=GrabSessionID(data))
t = SMB2TreeData(Data="C"*1500)#//BUG
packet1 = str(head)+str(t)
buffer1 = longueur(packet1)+packet1
print "[*]Triggering Bug; Tree Connect SMBv2 packet sent."
self.request.send(buffer1)
data = self.request.recv(1024)答案是否定的，至少在我看來，大量的數據目的并非是為了填充緩沖區，而是為了繞過tcpip.sys的某處判斷，從而進入漏洞出發的函數調用邏輯。
問題出現在smbv2后的一個特性Tree Connect，用來處理共享服務的特性，opcode：0x03，而整個問題，確是多個地方導致的。下面我們就一起來進入今天的旅程吧！
Github地址：https://github.com/lgandx/PoC/tree/master/SMBv3%20Tree%20Connect
漏洞復現
首先，網上關于這個漏洞的觸發方法有很多，比較通用的是twitter中某老外提到的Powershell的方法，最為簡單，首先我們調試的環境是：Windows 10 x64 build 1607
接下來我們在kali2.0里運行漏洞腳本。
隨后執行"dir \ip\PATH"，漏洞觸發，通過windbg雙機聯調，此時捕捉到了BSOD。
可以看到提示此時問題出現在mrxsmb20.sys中，問題函數是Smb2ValidateNegotiateInfo，來看一下觸發位置的代碼。
kd> p
mrxsmb20!Smb2ValidateNegotiateInfo+0x17:
fffff803`1869c7d7 66394114 cmp word ptr [rcx+14h],ax
kd> r rcx
rcx=0x00000000`00000000此時rcx的值為0x0，是一處無效地址，因此這是由于空指針引用導致的BSOD，接下來繼續執行可以看到Windows 10引發藍屏。
回溯及數據包分析(important!)
我們來看一下mrxsmb20.sys關于Tree Connect特性的一些內容，代碼邏輯相對簡單。
可以看到執行到Smb2ValidateNegotiateInfo函數有兩條邏輯調用，一個是Smb2TreeConnect_CopyData，一個是Smb2TreeConnect_Receive，這里我就把我回溯的結果和大家分享一下，首先，通過Smb2TreeConnect_Receive來接收smb的Tree Connect數據，這個是通過opcode來決定的。
正常情況下不會進入Smb2TreeConnect_CopyData，但一旦由不正常（后面會提到）數據包執行，則會在Receive之后進入CopyData函數的處理邏輯，從而引發漏洞。
這里數據包分析很關鍵，因為在漏洞觸發過程中，就是由于數據包的問題導致的。
來看一下Smb最關鍵的這個數據包。
來看一下Smb頭部的協議格式。
在協議格式中Opcode指示smb類型
注意數據包中對應位置，opcode值是0x03，就是tree connect的處理。同時這里在后面分析中我們要用到，注意Data數據之前的長度。其中包含了NetBIOS Session Service 4字節，和 SMB2 Header ＋ Tree Connect Body 80字節，以及 Data n字節。這個非常重要，后續分析我們會用到。
漏洞分析
剛開始，我天真的以為是CopyData引發的某些異常，后來發現我錯了，其實這個漏洞可以看成利用tcpip.sys中的某些邏輯特性，以及mrxsmb20.sys中對于相關結構的檢查不夠嚴格導致的空指針引用BSOD，而整個漏洞形成，我是利用正常和不正常的對比才終于發現。在分析的過程中，大量不透明的結構體引用讓我有點尷尬，期待更熟悉SMB的大牛能夠繼續豐富分析。
正常的SMB2 Tree Connect包是不會觸發異常的。
首先我們來看一下正常的邏輯調用，關鍵函數在tcpip.sys中的TcpDeliverDataToClient，這個函數負責處理接收到的數據包，在一個while(1)循環中。
char __fastcall TcpDeliverDataToClient(PKSPIN_LOCK SpinLock, KSPIN_LOCK *a2, _QWORD *a3, _QWORD **a4)
{
while ( 1 )
{
……
v22 = (unsigned int)vars30;
v23 = TcpIndicateData(v7, v6, v5, &v72);
v24 = v71;
if ( !(v6[3] + v6[4]) )
break;
……在這個循環中，剛進入循環位置有一個if語句，后面我們會提到，在接收到TreeConnect包之后，不會進入if語句，而是執行下面的函數調用，在TcpIndicateData函數內部會調用到之前提到的Smb2TreeConnect_Receive，注意這一切現在都是在我們發送一個正常數據包時完成的。（接下來我們會分析到為什么是正常的）
在這個函數入口下條件斷點。
kd> bp tcpip!TcpDeliverDataToClient ".if(poi(rbx+20)==0x1E4){;}.else{g;}"
kd> g
tcpip!TcpDeliverDataToClient:
fffff801`f18017a0 4055 push rbp
kd> dd rbx+20 L1
ffffb304`06865c58 000001e4命中時，rbx會存放一個結構體，這個結構體按照IDA的反饋來看是一個KSPIN_LOCK自旋鎖，windows內核同步處理的一種機制，這個暫且不管，注意一下rbx結構體＋20位置的值，是1e4，這個值轉換成10進制就是484，正好是我們發送的400個C的Data數據加剛才我們提到的頭部84字節的長度。
接下來進入TcpIndicateData函數后會命中Smb2TreeConnect_Receive函數開始進行接收處理。
kd> p
tcpip!TcpDeliverDataToClient+0x209:
fffff801`f18019a9 e8e2810100 call tcpip!TcpIndicateData (fffff801`f1819b90)
kd> dd rbx
ffffb304`06865c38 aa9ce398 fffff801 00000000 00000000
ffffb304`06865c48 00000000 00000000 00000000 00000000
ffffb304`06865c58 000001e4 00000000 00000000 00000000
ffffb304`06865c68 00000000 00000000 00000000 00000000
ffffb304`06865c78 06865c60 ffffb304 00000000 00000000
ffffb304`06865c88 00000000 00000000 00000000 00000000
ffffb304`06865c98 00000000 00000000 00000000 00000000
ffffb304`06865ca8 00000000 00000000 00000000 00000001
kd> p
Breakpoint 1 hit
mrxsmb20!Smb2TreeConnect_Receive:
fffff801`f3fbc4b0 48895c2420 mov qword ptr [rsp+20h],rbx處理過程很長，這里我直接略過，在處理結束后會多層ret后返回到TcpDeliverDataToClient函數中，仍然處于while循環中。
kd> bp tcpip!TcpIndicateData+0x268
kd> g
Breakpoint 3 hit
tcpip!TcpIndicateData+0x268:
fffff80a`72c39df8 c3 ret
kd> p
tcpip!TcpDeliverDataToClient+0x20e:
fffff80a`72c219ae 833defa51a0001 cmp dword ptr [tcpip!MICROSOFT_TCPIP_PROVIDER_Context+0x24 (fffff80a`72dcbfa4)],1
kd> p
tcpip!TcpDeliverDataToClient+0x215:
fffff80a`72c219b5 448bf0 mov r14d,eax這里我列舉一下返回過程的逐層調用邏輯，因為kb回溯不到。Smb2TreeConnect_Receive -> SmbReceiveInd -> VctIndRecv -> SmbWskReceiveEvent -> afd!WskProTLEventReceive -> tcpip!TcpIndicateData -> tcpip!TcpDeliverDataToClient。
接下來就是關鍵了，首先會執行一處sub匯編指令。
kd> p
tcpip!TcpDeliverDataToClient+0x2b9:
fffff80a`72c21a59 48297b20 sub qword ptr [rbx+20h],rdi
kd> r rdi
rdi=00000000000001e4
kd> dd rbx+20 L1
ffffc10c`9fe79e78 000001e4這個相減之后，會將rbx結構體對應的長度變成0，隨后，會到達一處cmp操作，這處cmp操作會將這個值作為一個判斷條件。
kd> p
tcpip!TcpDeliverDataToClient+0x2de:
fffff80a`72c21a7e 4c896b48 mov qword ptr [rbx+48h],r13
kd> p
tcpip!TcpDeliverDataToClient+0x2e2:
fffff80a`72c21a82 488b4320 mov rax,qword ptr [rbx+20h]
kd> dd rbx+18 L1
ffffc10c`9fe79e70 00000000
kd> dd rbx+20 L1
ffffc10c`9fe79e78 00000000
kd> p
tcpip!TcpDeliverDataToClient+0x2e6:
fffff80a`72c21a86 48034318 add rax,qword ptr [rbx+18h]
kd> p
tcpip!TcpDeliverDataToClient+0x2ea:
fffff80a`72c21a8a 0f858dfeffff jne tcpip!TcpDeliverDataToClient+0x17d (fffff80a`72c2191d)
kd> p
tcpip!TcpDeliverDataToClient+0x2f0:
fffff80a`72c21a90 48837e2000 cmp qword ptr [rsi+20h],0來看一下這一段偽代碼。
while ( 1 )
{
v70 = v10;
v69 = TcpSatisfyReceiveRequests(v7);
if ( v24 >= v23 )
{
}
else
{
v25 = (char *)ReceiveDpcTable + 24 * v21;
v26 = v23 - v24;
v27 = v7[2];
v70 = v26;
*(_QWORD *)(*(_QWORD *)(v27 + 128) + (v21 << 7) + 56) -= v24;
v28 = *((_DWORD *)v25 + 5);
if ( v28 & 1 )
*((_DWORD *)v25 + 5) = v28 | 4;
else
TcpStartRcvWndTuningTimer(vars38);
v6[4] -= v26;
v29 = v6[9];
v6[3] = 0i64;
if ( v26 + v29 )
{
TcpAdvanceTcbRcvWnd(v7, (unsigned int)(v26 + *((_DWORD *)v6 + 18)));
v6[9] = 0i64;
}
else
{
v6[9] = 0i64;
}
}
if ( !(v6[3] + v6[4]) )
break;在偽代碼最后的位置，會對兩個值進行判斷，如果兩個值之和為0，則條件成立，程序會跳出循環，剛才的跟蹤我們可以發現，v6就是結構體，v6[4]的值來源于它自身減v26，而v26就是它自身，最后它的值為0，而剛才跟蹤v6[3]的值也為0（如果知道結構體就好清楚v6到底是什么了T.T）。
經過對比調試，發現在正常的處理SMB Tree Connect包和觸發BSOD的不正常情況下有一處關鍵的跳轉邏輯，這里是一處if語句判斷，成立則break跳出while循環，不成立，會繼續執行。
那么不正常的情況呢？之前的處理和之前的分析一樣，我們加大Data的值到1200，但是在返回后。
kd> p
tcpip!TcpDeliverDataToClient+0x2b9:
fffff80a`72c21a59 48297b20 sub qword ptr [rbx+20h],rdi
kd> r rdi
rdi=0000000000000404
kd> dd rbx+20
ffffc10c`a0643e78 00000504顯而易見，在我們加大Data長度的時候，到相減位置結構體對應位置的值是504，也就是1284，正好是Data的長度1200字節 ＋ 剛才分析到的84字節，而此時rdi的值只有0x404，也就是944長度，這是一個Max值，如果Data長度超過0x404，這里會認為還有數據，因此相減后v6[4]的值不為0。
kd> p
tcpip!TcpDeliverDataToClient+0x2bd:
fffff80a`72c21a5d 4533ed xor r13d,r13d
kd> dd rbx+20
ffffc10c`a0643e78 00000100這造成了一個問題，就是剛才到的break位置由于v6[4]不為0，所以不執行break，而是進入后續的處理。
kd> p
tcpip!TcpDeliverDataToClient+0x2e2:
fffff80a`72c21a82 488b4320 mov rax,qword ptr [rbx+20h]
kd> p
tcpip!TcpDeliverDataToClient+0x2e6:
fffff80a`72c21a86 48034318 add rax,qword ptr [rbx+18h]
kd> p
tcpip!TcpDeliverDataToClient+0x2ea:
fffff80a`72c21a8a 0f858dfeffff jne tcpip!TcpDeliverDataToClient+0x17d (fffff80a`72c2191d)
kd> p
tcpip!TcpDeliverDataToClient+0x17d:
fffff80a`72c2191d 49833f00 cmp qword ptr [r15],0
kd> p
tcpip!TcpDeliverDataToClient+0x181:
fffff80a`72c21921 0f85e9010000 jne tcpip!TcpDeliverDataToClient+0x370 (fffff80a`72c21b10)接下來，程序會回到while入口位置，接下來會進入之前提到沒有進入的if語句處理，這是由于剛才沒有break結束循環的原因，此時會進入if語句的處理，函數中所調用的函數都是Complete，猜測都是和結束數據包相關處理有關。
kd> p
tcpip!TcpDeliverDataToClient+0x1c1:
fffff80a`72c21961 e99bfeffff jmp tcpip!TcpDeliverDataToClient+0x61 (fffff80a`72c21801)
kd> p
tcpip!TcpDeliverDataToClient+0x61:
fffff80a`72c21801 48837b0800 cmp qword ptr [rbx+8],0
kd> dd rbx+8
ffffc10c`a0643e60 9d8c2fa0 ffffc10c 9d8c2fa0 ffffc10c來看一下這個if語句。
while ( 1 )
{
if ( v6[1] )
{
if ( !*v5 )
break;
v9 = v6[1];
v10 = v6[2];
*((_BYTE *)v6 + 98) &= 0xFEu;
v69 = v9;
v6[1] = 0i64;
v6[2] = 0i64;
v11 = vars30;
v71 = v10;
LODWORD(v12) = TcpSatisfyReceiveRequests(v7, 0, (__int64)v6, vars30, v5, &v69, &v66);
}
}在這個if語句中，會調用TcpSatisfyReceiveRequests函數，這個函數中第六個參數，也就是v69是很關鍵的，這個值決定了后面的空指針引用，接下來進入這個函數。
int __fastcall TcpSatisfyReceiveRequests(PKSPIN_LOCK SpinLock, char a2, __int64 a3, signed int a4, __int64 *a5, __int64 *a6, _DWORD *a7)
{
v8 = *a5;
v95 = SpinLock;
v9 = *a6; // RBP+148
v38 = *(_QWORD *)(v9 + 48);
v39 = *(_QWORD *)(v9 + 56);
v40 = *(_QWORD *)(v9 + 8);
v41 = *(_QWORD *)(v9 + 72);
v93 += v38;
v99 += *(_QWORD *)(v9 + 40);
v42 = *(_QWORD *)v9;
_guard_dispatch_icall_fptr(v40, 0i64, v38, v39);// call WskProTLReceiveComplete這個函數中的_guard_dispatch_icall_fptr調用了WskProTLreceiveComplete函數，而v40參數和v9結構體有關，v9是由傳入第六個參數，也就是剛才提到的v69有關，v69又來自于v6[1]，而這個結構體是和Complete有關，但是在TreeConnect數據包中卻沒有對這個結構體進行賦值。
隨后在WskProTLReceiveComplete中，會將rcx，也就是第一個參數v40，進行傳遞（64位Windows系統中，參數傳遞通過寄存器，第一個參數是rcx，第二個是rdx，第三個是r8，第四個是r9）。在后面的分析中，省略了無關的匯編過程，只留關鍵的給大家分享。
kd> p
afd!WskProTLReceiveComplete+0x34:
fffff80a`7365aa84 488bd9 mov rbx,rcx
…………
kd> p
afd!WskProTLReceiveComplete+0x8e:
fffff80a`7365aade 488bcb mov rcx,rbx
kd> r rbx
rbx=ffffc10ca01ba010
kd> p
afd!WskProTLReceiveComplete+0x91:
fffff80a`7365aae1 ff15512d0200 call qword ptr [afd!_imp_IofCompleteRequest (fffff80a`7367d838)]經過一系列傳遞后，這個第一個參數會直接傳給IofCompleteRequest函數，這個函數是irp完成函數，其實是一個中間過程，同步irp完成，后面就是善后工作。
在函數中，參數繼續傳遞。
kd> p
nt!IopfCompleteRequest+0xb:
fffff800`9464b81b 4881ec00010000 sub rsp,100h
kd> p
nt!IopfCompleteRequest+0x12:
fffff800`9464b822 488bd9 mov rbx,rcx
…………
kd> p
nt!IopfCompleteRequest+0x109:
fffff800`9464b919 488bd3 mov rdx,rbx
kd> p
nt!IopfCompleteRequest+0x10c:
fffff800`9464b91c 488bce mov rcx,rsi
kd> p
nt!IopfCompleteRequest+0x10f:
fffff800`9464b91f ff5735 call qword ptr [rdi+35h]
kd> t
Breakpoint 0 hit
mrxsmb!SmbWskReceiveComplete:
fffff80a`731d6950 48895c2408 mov qword ptr [rsp+8],rbx在IofCompleteRequest函數中，會有一處調用回到SmWskReceivComplete函數，而結構體會交給rdx，也就是第二個參數進入這個函數。隨后這個參數會連續傳遞。先來看一下之前的堆棧回溯。
kd> kb
RetAddr : Args to Child : Call Site
fffff800`9464b922 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : mrxsmb!SmbWskReceiveComplete
fffff80a`7365aae7 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopfCompleteRequest+0x112
fffff80a`72c60d9d : fffff800`963d54a8 ffffc10c`9ed02780 fffff800`963d54b0 fffff800`963d547c : afd!WskProTLReceiveComplete+0x97
fffff80a`72c21860 : 00000000`00000002 ffffc10c`a0643d00 00000000`00000007 00000000`00000000 : tcpip!TcpSatisfyReceiveRequests+0x3cd
00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!TcpDeliverDataToClient+0xc0之后參數會連續進行傳遞，首先會把當前rdx＋b8存放的值交給r14，之后把r14+40位置的值交給r8，最后引用的就是r8+98位置的值。
kd> p
mrxsmb!SmbWskReceiveComplete+0x1d:
fffff80a`731d696d 488bda mov rbx,rdx
kd> p
mrxsmb!SmbWskReceiveComplete+0x20:
fffff80a`731d6970 4c8bb2b8000000 mov r14,qword ptr [rdx+0B8h]
…………
kd> p
mrxsmb!SmbWskReceiveComplete+0x7f:
fffff80a`731d69cf 4d8b4640 mov r8,qword ptr [r14+40h]//1
kd> dd r14+40
ffffc10c`a01ba168 9fdf3c58 ffffc10c可以看到，這個過程并沒有對這個值進行檢查，由于結構體不透明，不能確定到底對應存放的是什么，但其實這個結構體的連續調用我們可以理解為_KPCR ->_ KTHREAD -> _EPROCESS -> Token這種關系，在Windows內核有很多這樣的域以及相關的結構體，而相互又是嵌套的。
這個結構體的值為0x0的原因可能就是由于這個complete部分的數據包是由于SMB Tree Connect過長引起的，而mrxsmb20.sys中卻沒有對相關結構體進行檢查。
kd> p
mrxsmb!VctIndDataReady+0x36:
fffff80a`731d6a56 498bf8 mov rdi,r8
…………
kd> p
mrxsmb!VctIndDataReady+0x146:
fffff80a`731d6b66 488bd7 mov rdx,rdi
kd> p
mrxsmb!VctIndDataReady+0x149:
fffff80a`731d6b69 488bcb mov rcx,rbx
kd> p
mrxsmb!VctIndDataReady+0x14c:
fffff80a`731d6b6c ff15eeed0200 call qword ptr [mrxsmb!_guard_dispatch_icall_fptr (fffff80a`73205960)]
kd> r rdx
rdx=ffffc10c9fdf3c58
kd> t
mrxsmb!guard_dispatch_icall_nop:
fffff80a`731d8a30 ffe0 jmp rax
kd> p
mrxsmb20!Smb2TreeConnect_CopyData:
fffff80a`7546b6c0 48895c2410 mov qword ptr [rsp+10h],rbx最后進入CopyData后，會引用這個結構體＋98偏移位置的值，進入漏洞觸發的函數，而沒有對這個值進行檢查。
kd> p
mrxsmb20!Smb2TreeConnect_CopyData+0x32:
fffff80a`7546b6f2 488b8b98000000 mov rcx,qword ptr [rbx+98h]
kd> p
mrxsmb20!Smb2TreeConnect_CopyData+0x39:
fffff80a`7546b6f9 e8c210ffff call mrxsmb20!Smb2ValidateNegotiateInfo (fffff80a`7545c7c0)
kd> dd rbx+98
ffffc10c`9fdf3cf0 00000000 00000000最后在函數中引用空指針，引發了BSOD。
關于這個結構體的問題我還是比較在意的，希望未來能夠更深入的分析SMB的各種機制，元宵快樂！新的一年，大家一起加油！謝謝大家！
本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/215/
暫無評論