FavoriteLoading
0

SMBv3遠程拒絕服務(BSOD)漏洞分析


前言
我是菜鳥,大牛輕噴。
這個SMBv3漏洞是由lgandx爆出的一個未被微軟修復的漏洞(暫未發布補丁),漏洞出來后我進行了一定的分析,花了很多時間,這個漏洞有一些意思,但是對于SMB的整個協議通信過程非常龐大,所以沒有進行非常細致的跟蹤,包括一些不透明的結構體讓我感到暈頭轉向,但到最后還是有了一些結果。
這個SMB漏洞可以看作是被動的,需要用戶主動去訪問445端口才可以觸發,而不像ms08067一樣主動攻擊別人,所以需要運行漏洞腳本在系統上。
終于趕在元宵節這天完成了這個任務,也在這里,祝大家元宵節快樂!
這個漏洞在twitter爆出來之后,很多老外也在微博下面問是否可以RCE,包括國內的預警中也有人問到。
那么很多人看到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字節。這個非常重要,后續分析我們會用到。

分頁閱讀: 1 2 3 4 5
【聲明】:8090安全小組門戶(http://www.jvwkvg.tw)登載此文出于傳遞更多信息之目的,并不代表本站贊同其觀點和對其真實性負責,僅適于網絡安全技術愛好者學習研究使用,學習中請遵循國家相關法律法規。如有問題請聯系我們,聯系郵箱[email protected],我們會在最短的時間內進行處理。