繞過AppLocker系列之CreateRestrictedToken的利用

大多數時候，繞過AppLocker都會利用可信的Microsoft二進位文件或者配置錯誤的策略進行代碼執行，這些方法都比較簡單。但是，我們還有一種通過利用架構設計的漏洞來繞過SPR或AppLocker。特別是在Windows 7和Windows 2008 Server環境中，可以濫用API函數（CreateRestrictedToken）來實現繞過。微軟後來發布了一個補丁來解決這個問題。

從命令提示符可以輕易的識別出是否缺少這個補丁：

wmic.exe qfe list | findstr.exe 2532445

AppLocker修補程序丟失

因為沒有輸出任何內容，所以這表示KB2532445補丁並沒有安裝。直接嘗試執行不受信任的二進位文件就會因為AppLocker的限制而運行失敗。

有一個由Michael Bailey開發的PowerShell 腳本，它通過使用SANDBOX_INERT標誌來利用API函數CreateRestrictedToken，以便可以允許執行二進位文件。由於該標誌禁用了所有規則集合的檢查，因此可以繞過AppLocker和軟體限制策略。這個漏洞最初是由Didier Stevens發現的，並且在他的博客中進行了完整的記錄。

AppLocker Bypass – CreateRestrictedToken

為什麼會發生這樣的情況呢？讓我們來看看 MSDN 是如何定義CreateRestrictedToken這個 API函數的。關於CreateRestrictedToken 函數的SANDBOX_INERT標誌，MSDN 有如下描述：

如果使用此值，系統將不會檢查AppLocker規則或應用軟體限制策略。對於AppLocker，此標誌將禁用所有這四個規則集的檢查：可執行文件，Windows Installer，腳本和DLL。

在安裝過程中創建必須運行提取的DLL的安裝程序時，請在SaferComputeTokenFromLevel函數中使用SAFER_TOKEN_MAKE_INERT標誌。

我寫了一個小的應用程序來進行測試：

HANDLE hToken;HANDLE hNewToken;PROCESS_INFORMATION sPI;STARTUPINFO sSI; if (OpenProcessToken(GetCurrentProcess(), TOKEN_ALL_ACCESS, &hToken)){ if (CreateRestrictedToken(hToken, SANDBOX_INERT, 0, NULL, 0, NULL, 0, NULL, &hNewToken)) { memset(&sSI, 0, sizeof(sSI)); sSI.cb = sizeof(sSI); if (CreateProcessAsUser(hNewToken, L"c:testDialog42.exe", NULL, NULL, NULL, TRUE, 0, NULL, NULL, &sSI, &sPI)) { puts("process created"); }}

這個程序會啟動另外一個程序——Dialog42.exe，我已經使用白名單配置了SRP，但是Dialog42.exe並不在白名單列表中：

但是，當我在我的應用程序中使用SANDBOX_INERT標誌啟動Dialog42.exe時，就可以正常運行。

參考

https://blog.didierstevens.com/2011/01/25/circumventing-srp-and-applocker-to-create-a-new-process-by-design/

https://support.microsoft.com/en-us/help/2532445/you-can-circumvent-applocker-rules-by-using-an-office-macro-on-a-compu

http://baileysoriginalirishtech.blogspot.co.uk/2015/06/applocker-schmapplocker.html

https://github.com/strictlymike/Invoke-SchmappLocker/blob/master/Invoke-SchmappLocker.ps1

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！