James Forshaw發(fā)現(xiàn)的DiagHub DLL loading技術(shù)已經(jīng)非常有名了。每當(dāng)你在windows或一些第三方軟件中發(fā)現(xiàn)SYSTEM權(quán)限的任意文件寫漏洞時(shí)，你就可以用這一招來造成任意代碼執(zhí)行，而且不用重啟。不幸的是這種方法在Windows 10 build 1903年被微軟禁止。Andrea Pierini在Twitter上簡單地提到了這一點(diǎn)。在這里，我想和大家分享一下我在最新版本的Windows上尋找DLL劫持弱點(diǎn)時(shí)發(fā)現(xiàn)的另一種加載dll的方法。
前言
在本文的開頭，我想澄清一下：
這不算是一個(gè)漏洞。正如我們所看到的，為了能夠使用這個(gè)技巧，必須先將一個(gè)專門制作的DLL植入C:WindowsSystem32文件夾，當(dāng)然只有 “SYSTEM” 權(quán)限的用戶才能做到這一點(diǎn)。
寫在開始
作為出發(fā)點(diǎn)，我決定尋找一些簡單的例子，例如在以NT AUTHORITY/System運(yùn)行的服務(wù)中的DLL劫持。我的想法是監(jiān)控那些可以被普通用戶啟動(dòng)或至少是 “影響 “的服務(wù)。為此，我做了一個(gè)非常簡單的PowerShell腳本，每秒鐘檢查一個(gè)服務(wù)是否被啟動(dòng)或停止。
在Windows操作系統(tǒng)的后臺，運(yùn)行Process Monitor來記錄文件系統(tǒng)操作。我簡單地配置了一個(gè)過濾器，只顯示涉及*.dll文件的操作，如果找不到的話就返回NAME NOT FOUND錯(cuò)誤代碼。然后，我試著在沒有管理員權(quán)限的情況下，一次一次地啟動(dòng)所有能啟動(dòng)的服務(wù)。不幸的是，我沒有用這個(gè)方法發(fā)現(xiàn)任何東西。不過我發(fā)現(xiàn)了以下內(nèi)容。
當(dāng) “Process Monitor “在后臺運(yùn)行時(shí)，它捕捉到一些定期打開 “windowscoredeviceinfo.dll “文件的操作。頻率不一，可能每小時(shí)發(fā)生一次，也可能每30分鐘發(fā)生一次。事件的屬性顯示了該進(jìn)程的命令行。通過查看事件的屬性能夠發(fā)現(xiàn)這個(gè)操作是由命令行”C:WINDOWS/System32/svchost.exe -k utcsvc -p”造成的。
知道了這一點(diǎn)，就可以很容易地通過以下PowerShell命令找到相應(yīng)的服務(wù)，例如。在這種情況下，可以用DiagTrack命令。
注：我也可以使用進(jìn)程的PID，例如在任務(wù)管理器中查找它。這種方法的缺點(diǎn)是，你不知道它什么時(shí)候啟動(dòng)，在你檢查的時(shí)候，進(jìn)程可能并不在運(yùn)行。
我們的第一個(gè)目標(biāo)
“Process Monitor “中的事件屬性顯示了一些關(guān)于DLL如何被加載的信息。Stack選項(xiàng)卡顯示了導(dǎo)致這次操作的調(diào)用列表。在這里，我們可以看到，初始調(diào)用是從diagtrack.dll進(jìn)行的。DiagTrack服務(wù)加載了FlightSettings.dll文件，它又使用了dcntel.dll中的GetCensusRegistryLocation()方法，最后，使用標(biāo)準(zhǔn)的LoadLibraryEx()WinApi調(diào)用加載了windowscoredeviceinfo.dll。
為了確定我的方向是正確的，我在IDA中打開最后一個(gè)DLL，并查找windowscoredeviceinfo.dll的出現(xiàn)。Strings標(biāo)簽頁中能夠清楚的找到這個(gè)dll的名字。
注意：你必須配置視圖以包含unicode字符串，這不是IDA的默認(rèn)設(shè)置……。
然后，我們可以直接到它在.rdata部分的位置，尋找Xrefs。在這種情況下，只有一個(gè)。這個(gè)字符串確實(shí)是在QueryWCOSDeviceInformation()方法中使用的。好吧，說明我們的路線是對的!
IDA生成的偽代碼非常清晰。我們發(fā)現(xiàn)前面看到的Process Monitor的LoadLibraryEx("windowscoredeviceinfo.dll")調(diào)用。然后，如果庫被成功加載，就會進(jìn)行下面的調(diào)用。GetProcAddress("QueryDeviceInformation")，也就是說這個(gè)函數(shù)應(yīng)該是windowscoredeviceinfo.dll的導(dǎo)出函數(shù)。
我們來總結(jié)一下情況。目前，我們知道以下幾點(diǎn)。
- DiagTrack服務(wù)定期（每30分鐘或每小時(shí)）運(yùn)行一個(gè)未知任務(wù)。
- 每次，它都會嘗試加載一個(gè)名為 “windowscoredeviceinfo.dll “的DLL，而這個(gè)DLL默認(rèn)情況下并不存在。
- 如果成功加載，則導(dǎo)入 “QueryDeviceInformation “函數(shù)。
這是一個(gè)好的開始，但我缺少一些關(guān)鍵要素。例如，我不知道這個(gè) “任務(wù) “是如何運(yùn)行的。我甚至不知道作為一個(gè)普通用戶是否能夠觸發(fā)它。所以，與其在不知道自己在尋找什么的情況下就開始對服務(wù)進(jìn)行逆向工程，我決定創(chuàng)建一個(gè)PoC DLL，并驗(yàn)證我是否真的能以NT AUTHORITYSystem的方式獲得任意代碼執(zhí)行。
制作一個(gè)PoC DLL
這個(gè)PoC DLL的目標(biāo)非常簡單。我想記錄一些關(guān)于加載它的進(jìn)程的關(guān)鍵信息：命令行、當(dāng)前用戶名、PID和PPID。所有這些都會被記錄到C:tempdll.log中。
首先，我想出了以下代碼。TrackCall()函數(shù)負(fù)責(zé)收集和記錄信息。它會被DllMain()和QueryDeviceInformation()執(zhí)行，用來跟蹤它的調(diào)用者。
#include <Windows.h>
#include <IOStream>
#include <Lmcons.h> // UNLEN + GetUserName
#include <tlhelp32.h> // CreateToolhelp32Snapshot()
int TrackCall(const wchar_t * callingFrom)
{
WCHAR strSt[4096], strUsername[UNLEN + 1];
WCHAR * strComandLine;
SYSTEMTIME st;
HANDLE hFile, hToolhelpSnapshot;
PROCESSENTRY32 stProcessEntry;
Dword dwPcbBuffer = UNLEN, dwBytesWritten, dwProcessId, dwParentProcessId;
BOOL bResult;
strComandLine = GetCommandLine(); // Get Command line of the current process
bResult = GetUserName(strUsername, &dwPcbBuffer); // Get current user name
dwProcessId = GetCurrentProcessId(); // Get PID
// Get PPID
hToolhelpSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAppROCESS, 0);
stProcessEntry = { 0 };
stProcessEntry.dwSize = sizeof(PROCESSENTRY32);
dwParentProcessId = 0;
if (Process32First(hToolhelpSnapshot, &stProcessEntry)) {
do {
if (stProcessEntry.th32ProcessID == dwProcessId) {
dwParentProcessId = stProcessEntry.th32ParentProcessID;
break;
}
} while (Process32Next(hToolhelpSnapshot, &stProcessEntry));
}
CloseHandle(hToolhelpSnapshot);
// Create log entry
GetLocalTime(&st);
wsprintfW(strSt, L"[%.2u:%.2u:%.2u] - PID=%d - PPID=%d - USER='%s' - CMD='%s' - METHOD='%s'n", st.wHour, st.wMinute, st.wSecond, dwProcessId, dwParentProcessId, strUsername, strComandLine, callingFrom);
// Save to log file
hFile = CreateFile(L"C:Tempdll.log", FILE_APPEND_DATA, 0, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
if (hFile != INVALID_HANDLE_VALUE)
bResult = WriteFile(hFile, strSt, lstrlenW(strSt)*sizeof(WCHAR), &dwBytesWritten, NULL);
CloseHandle(hFile);
return S_OK;
}
HRESULT __stdcall QueryDeviceInformation()
{
TrackCall(L"QueryDeviceInformation()");
return S_OK;
}
BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
TrackCall(L"DllMain()");
break;
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
然后，作為管理員，我把這個(gè)DLL復(fù)制到C:/Windows/System32，然后，等待它被調(diào)用…
過了一會兒，windowscoredeviceinfo.dll的調(diào)用終于出現(xiàn)在Process Monitor中。所有的CreateFile操作都成功返回。但是，在C:temp中沒有創(chuàng)建日志文件的跡象。當(dāng)然，這意味著DLL沒有被正確加載，問題是：為什么？我猜測，我創(chuàng)建的DLL沒有導(dǎo)出進(jìn)程所需的所有函數(shù)。
此時(shí)，我不知道該如何繼續(xù)，但是，當(dāng)我回到Process Monitor時(shí)，我看到了一些以前沒有看到的事件。
文件windowscoredeviceinfo.dll也被一個(gè)名為usocoreworker.exe的進(jìn)程加載，這個(gè)進(jìn)程的權(quán)限為NT AUTHORITY/System。這時(shí)，一些信息被記錄到C:Tempdll.log中，這說明代碼此時(shí)已經(jīng)正確執(zhí)行了。
這看起來更有希望，所以我決定拋開DiagTrack服務(wù)，看看這個(gè)新目標(biāo)。
轉(zhuǎn)移到新目標(biāo)
我們又回到了起點(diǎn)。我們需要找出usocoreworker.exe進(jìn)程是如何創(chuàng)建的。為此，我們可以尋找與寫入日志文件的PPID對應(yīng)的進(jìn)程。根據(jù)任務(wù)管理器，它是svchost.exe的一個(gè)實(shí)例，就像大多數(shù)Windows服務(wù)一樣，所以PPID對我們的幫助不大。
對應(yīng)的服務(wù)是 BrokerInfrastructure，它的描述是 “處理后臺任務(wù)”。好吧，這也沒什么用……。
讓我們來看看我們可以從Process Monitor 中找到什么。訪問與這個(gè)進(jìn)程相關(guān)的事件的屬性，然后，進(jìn)入Stack選項(xiàng)卡，會顯示以下內(nèi)容。我們可以看到，有很多對rpcrt4.dll和combase.dll的引用。這可能意味著這個(gè)進(jìn)程是由一個(gè)COM相關(guān)的RPC調(diào)用觸發(fā)的。如果是這樣的話，根據(jù)遠(yuǎn)程對象和接口的權(quán)限，也可以作為普通用戶觸發(fā)。
注。COM用于進(jìn)程間通信（IPC）。因此，它可以為低權(quán)限的進(jìn)程提供運(yùn)行高權(quán)限操作的能力。
從二進(jìn)制文件的屬性來看，我們可以看到如下描述：USO Core Worker Process。
根據(jù)前幾個(gè)要素，我試圖在谷歌上找到更多信息。第一個(gè)結(jié)果把我引向answsers.microsoft.com上的一個(gè)帖子。根據(jù)其中一條信息，我發(fā)現(xiàn)這個(gè)文件與 “Update Orchestrator Service “有關(guān)。
細(xì)細(xì)研究，我發(fā)現(xiàn)了這個(gè)非常有趣的關(guān)于 “USO客戶端 “的非官方文檔。首先，我們了解到 “USO “是 “Update Session Orchestrator “的縮寫。
我們還了解到，”USO客戶端”(usoclient.exe)是取代 “WUAUCLT “的工具，而WUAUCLT在以前的Windows版本中是用來管理Windows更新的。事實(shí)上，這個(gè)工具已經(jīng)被Windows系統(tǒng)管理員所熟知，因?yàn)殡m然它不被微軟官方支持，但它能讓他們自動(dòng)完成更新管理過程。
注：他們甚至引用了TechNet上微軟員工的回復(fù)，其中說你不應(yīng)該直接運(yùn)行這個(gè)工具。這越來越有趣了。我們喜歡做我們不應(yīng)該做的事情，不是嗎？
文檔中列出了所有你可以使用的選項(xiàng)。所以，我試著玩玩usoclient命令，看看是否能觸發(fā)我之前觀察到的相同行為。從StartScan開始，根據(jù)描述，它會觸發(fā)一個(gè)簡單地獲取可用更新的檢查。
我像往常一樣在后臺運(yùn)行 Process Monitor，運(yùn)行命令，成了。
結(jié)論
通過一個(gè)簡單的命令，我們能夠讓Update Orchestrator服務(wù)以NT AUTHORITY/System的方式運(yùn)行任意代碼。這種方法的另一個(gè)好處是，我們可以在DllMain之外運(yùn)行我們的代碼（即在加載器鎖之外）。
注意：根據(jù)微軟的說法，應(yīng)避免在DllMain中運(yùn)行代碼，因?yàn)樗赡軙?dǎo)致應(yīng)用程序死鎖。更多信息查看這里。
然而，這種技術(shù)也有一些缺點(diǎn)。
- 這需要你能夠控制一個(gè)特權(quán)文件創(chuàng)建或移動(dòng)的操作。
- 導(dǎo)致ACL覆蓋的漏洞等。
- 作為一個(gè)普通用戶，我們不知道DLL是否已經(jīng)成功加載。
依賴于usoclient工具而不了解其工作原理也是我不喜歡這種技術(shù)的地方。所以，我對客戶端和服務(wù)進(jìn)行了逆向工程，以便制作一個(gè)可以在未來項(xiàng)目中重復(fù)使用的開源工具。UsoDllLoader。我將在本文的第二部分嘗試解釋這個(gè)過程。敬請期待
Links & Resources
- Windows開發(fā)技巧。利用任意文件寫入來提升本地的權(quán)限。
https://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html
https://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html - Twitter – MS終于修復(fù)了Win 10 1903的 “Diag Hub Collector “漏洞。
https://twitter.com/decoder_it/status/1131247394031579138
https://twitter.com/decoder_it/status/1131247394031579138 - 非官方的USO客戶文件
https://www.urtech.ca/2018/11/usoclient-documentation-switches/
https://www.urtech.ca/2018/11/usoclient-documentation-switches/ - 關(guān)于 “USO客戶端 “工具的主題，在TechNet上。
https://social.technet.microsoft.com/Forums/en-US/7619f7fa-ffc1-433b-a885-12e26f9762bf/usoclientexe-usage?forum=win10itprogeneral
https://social.technet.microsoft.com/Forums/en-US/7619f7fa-ffc1-433b-a885-12e26f9762bf/usoclientexe-usage?forum=win10itprogeneral - 動(dòng)態(tài)鏈接庫最佳實(shí)踐
https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-best-practices
https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-best-practices
本文翻譯自 itm4n.github.io， 原文鏈接 。如若轉(zhuǎn)載請注明出處。
