[Windows] 惡意利用配置錯誤資訊清單（manifest）達成劫持與特權提升

-

 前言

這篇技巧是我在校稿最近剛出版的書《Windows APT Warfare：惡意程式前線戰術指南》正好看到 github.com/L3cr0f/DccwBypassUAC 這份 PoC 提及的 WinSxS 配置錯誤允許駭客劫持達成 UAC 特權提升看到比較有意思的事情所以寫一篇作為筆記。

不過這篇技巧目前在 Windows 10 上除非出現了配置錯誤的 DACL 可被寫入、否則新型的作業系統利用的可能性比較小XD 如果對 UAC 特權提升有興趣的讀者可以參考對岸這篇 BypassUAC原理及方法汇总 我覺得寫得還不錯、或者是看看我的書（？）

 WinSxS

 Windows 為了原生支援 WinSxS 多重系統模組功能——即同一個系統中可能會有新舊程式使用到同個系統模組但不同版本號的狀況。因此可以見到 C:\Windows\WinSxS\ 下有很多不同版本的資源包：


開發者能在編譯時期在純文字的資訊清單 *.manifest 記錄特定系統模組要從特定系統路徑、版本來裝載使用。而這邊引自上述對岸文章一段描述，其中提及了在資訊清單中還有一個特性可以使用：
在Windows中有些可执行程序没有内置的manifest，假设这个程序叫test.exe，如果攻击者在该可执行程序目录下新建一个test.exe.manifest并在manifest文件中指定file元素，则test.exe执行时会加载file元素中loadFrom属性指定的DLL（loadFrom的dll不能在KnownDlls中）
這是一個我覺得蠻有趣的特性，可以解釋為什麼系統槽下會有那麼多純文字保存的資訊清單 *.manifest 文件（我以前一直誤以為是開發者編譯完忘記刪掉XD）這描述說明了兩點：
  1. 除了開發者相當熟悉的嵌入式資訊清單，還有導出式資訊清單——在同層資料夾中保存與程式名同名的 *.manifest 文件即可被程式裝載器正確識別
  2. 無論嵌入或導出式資訊清單：使用 loadFrom 標籤可以指示程式裝載器在「裝載特定 DLL 模組」時便會被 redirect 去裝載另一個特定的 DLL 模組
總而言之當程式裝載器正在初始化一支靜態程式文件、發現其不具嵌入式資訊清單時，那麼就會同層目錄確認是否有同名的 *.manifest 清單文件進行解析並初始化，以下做個舉例：




桌面上現在有一皮卡丘打排球程式（picaball.exe）是一個不具嵌入式資訊清單的老舊程式、並且其引入函數表顯示出執行階段會需要使用到 DirectX 的模組 dsound.dll 作為遊戲引擎聲音輸出。

因此，在同層資料夾（即桌面）放置一個 picaball.exe.manifest 便會在遊戲程式被程式裝載器初始化時視為導出式資訊清單文件進行讀取；而在該資訊清單中第十行可見 loadFrom 的屬性，其指示了 dsound.dll 被裝載時將會被 redirect 去裝載 30cm_tw.dll 文件，因此一旦遊戲程式被執行便會裝載我們的惡意模組 30cm_tw.dll 並彈出視窗。

WinSxS重導向

在微軟官方文獻 Dynamic-Link Library Redirection 提及了若資訊清單中指定要裝載特定版本的 WinSxS 系統模組、但如果你不希望裝載 C:\Windows\WinSxS 下的那套 DLL 模組；那麼你也可以創建與程式同名的 *.local 資料夾其會被作為該程式應採用的 WinSxS 模組之基礎路徑。


如上圖所示系統高權服務 dccw.exe 會使用到 C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.17763.1935_none_570899e8c25aaf4a 中的 GdiPlus.dll

因此我們可以在 dccw.exe 同層目錄創建 dccw.exe.local 資料夾作為新的 WinSxS 參考路徑、並在其內部創建 x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.17763.1935_none_570899e8c25aaf4a 子目錄、並在此目錄中放入惡意的 GdiPlus.dll 便會發現當 dccw.exe 被執行起來後就會自動裝載 dccw.exe.local 子目錄中的惡意 GdiPlus.dll 模組

DCCW 本地提權

上面講完了這個有趣的小技巧後便可以回頭來提 github.com/L3cr0f/DccwBypassUAC 這份 PoC。

主要就是在 Win8.1 以前的 Windows 版本可以利用 CIA Vault 7 被揭露過的 iFileOperation COM 接口來任意「創建資料夾」在 C:\Windows\System32\dccw.exe 同層目錄中創建 C:\Windows\System32\dccw.exe.local 資料夾並投放惡意模組達成本地提權，細節部分大家自己看就好惹XD

留言

張貼留言

這個網誌中的熱門文章

[C#] Lambda花式應用噁爛寫法（跨UI委派秒幹、多線程處理...etc）

-
為啥會有這篇呢...因為最近寫太多C# 突然發現Lambda對程式碼減化太有幫助了=...= 為了怕哪天老人癡呆忘了這些噁心的花式寫法，就開一篇Blog文紀錄了 以前在寫多線程,可能得這麼寫： void Func() {/*多線程要做的事情*/} //接著呼叫： Thread nThread = new Thread(Func); nThread.Start(); 但今天用Lambda可以改寫： Thread nThread = new Thread(() => {/*多線程要做的事情*/}); nThread.Start(); 甚至在噁心點寫的寫法： new Thread(() => {/*多線程要做的事情*/}).Start(); 簡單來說Lambda的形式可拆解成： ()是指你的函數參數列、然後可用=>代表你要接的Lambda陳述句/塊，最後用{}把事情包起來。 在來就是比較討厭的C#內要做跨UI線程操控UI上物件，會有跨UI安全性線程問題， 所以一般會額外寫個委派函數，然後請求UI Thread去處理這個委派函數請求，才能控制 這樣往往可能只用一兩次的委派函數，卻要占用一個篇幅去寫委派函數 先看看正常的跨UI委派寫法： private delegate void nCallback(string ContentText); public void n(string ContentText) { if (this.InvokeRequired) { nCallback obj = new nCallback(n); this.Invoke(obj, new object[] { ContentText }); return; } this.Text = ContentText; } //調用時呼叫n("str") 就可以改寫成： this.Invoke(new Action(() => { this.Text = "Str"; })); 又因為=>後面可接陳述塊或者陳述句，所...
閱讀完整內容

[Windows] 逆向工程 C++ 中入口函數參數 main(argc, argv) 與如何正確的進行參數劫持

-
圖片
前言 我在 Github 上三年前開源了精簡的以 C/C++ 撰寫的 Windows 執行程式裝載器： aaaddress1/RunPE-In-Memory  用以從記憶體執行以 C/C++ 開發的 *.exe 程式不必以 CreateProcess() 來叫起，算是一種概念性 PoC 啦畢竟這種手段在惡意程式和殼上經常使用，所以寫一寫就丟出來給大家玩 XD 不過有人在我的專案發起了 Issue：既然能從記憶體中執行 *.exe 那能否偽造 *.exe 取得的參數呢？嗯好問題XD 正逢去年蠻忙的所以一直懶得弄，這個月比較閒於是就決定在專案中新增 參數偽造 的功能，這邊簡單提一下 C++ 中 main() 入口所收的 argc 與 argv 來的。 [附註] 以下逆向工程內容以 MinGW 生產的程式為例， 系統逆向工程為 Win10 企業版 1809版  CRTStartup 在 Windows 下通常取得參數通常分為兩種狀況：  WINAPI GetCommandLineW() 系統函數返回字串指針指向當前完整應用程式參數 從 main(argc, argv) 拿回來的參數，那麼第二種狀況在編譯器是怎麼吐參數給開發者 main 入口的呢？ 在編譯器吐出執行程式後，連結器會生產一段 CRTStartup 的函數用於做一些基礎的例如像是 Security Cookies、Control Flow Guard 保護的初始化，在一系列初始化之後 .data 段的全域變數 _argv、argc 紀錄著要傳入給開發者入口函數的 參數陣列 與 數量，就以參數形式呼叫 main() 函數 好問題，那這兩個全域變數是在哪裡被初始化的？ 你會發現以 MinGW 為例的話，會去呼叫 msvcrt!__getmainargs() 來取得參數資訊保存到 .data 全域變數上，後續再傳遞給 main() 函數；如果是 VC++ 吐出來的則是直接呼叫 GetCommandLineW() 在做文字切割取出參數 MSVCRT MSVCRT.dll 有導出一系列 C 函數是引用 #include <stdio.h> 時會用到的，例如 printf, sprintf, gets 等等。...
閱讀完整內容

重建天堂之門：從 32 位元地獄一路打回天堂聖地（上）深度逆向工程 WOW64 設計

-
圖片
前言 這份研究是從去年底開始摸的，主因是一直對 Windows 如何實作 WOW64 兼容架構覺得有意思，並且坊間蠻多開源的天堂之門專案都死掉了 QQ 所以才打算自己完全重新逆向工程分析過一次。 逆向整個 WOW64 架構可以發現很多蠻有意思的問題，比方說 Intel 晶片指令集模式切換、記憶體模擬分配、WOW64 偽造的原生 32-bit 環境，例如 System32 在 32-bit 下會被重導向至 SysWOW64 到底在哪一層實作重導向的呢 ;)  此研究也運氣不錯分別被國內研討會 CYBERSEC 收錄為 《重建天堂之門：從 32bit 地獄一路打回天堂聖地》 與 HITB（Hack In The Box Security Conference）收錄為  《WoW Hell: Rebuilding Heavens Gate》 若對線上演講內容有興趣可以參考 Youtube 上 HITB 的直撥串流  HITB2021AMS D1T2 - WoW Hell: Rebuilding Heavens Gate - ShengHao Ma   不過我英文很破能不看就不看啦 由於整份演講內容想提的細節太多了，所以本部落格文拆成上下兩集。 當前本文是上集，會講述完整逆向工程整套微軟設計的 WOW64 架構怎麼設計的 。而下集《 重建天堂之門：從 32 位元地獄一路打回天堂聖地（下）攻擊篇：x96 Shellcode、天堂聖杯 ＆ 天堂注入器 》會著重在我今年發表出來的幾個有趣的攻擊點 :) 如果對天堂之門技術已經很熟的大佬，可以跳過本文看下一集了 <(_ _)> ＊注意＊ 本份研究在 2021/06/11 是基於 Windows 10 Enterprise 最新版本逆向工程結果所紀錄， 可能與讀者電腦中反編譯出來的結果有所出入是正常的 。筆者實測了同樣是 Windows 10 但不同組建版本在組合語言層級皆有些許差異，不過各個函數設計用途是固定且規律的、不會因版本而有所差異。 而整份研究不限但至少涉及了以下已知文獻，蠻值得一看的 2011 -  Mixing x86 with x64 code by ReWolf 2012 -  Knockin’ on Heaven’s Gate by georg...
閱讀完整內容