2025 HITCON CTF Final｜學生交流賽出題
Driver Killer
以 Windows Kernel Driver、CVE 與 TOCTOU 為核心設計的 HITCON CTF Final 交流題。
- Year
- 2025
- Role
- 出題組長／Driver 開發／環境整合
- Team
- 3 人團隊
- Share
- 60%
專案總覽
2025 HITCON CTF Final 以學生交流為核心，由決賽隊伍互相設計題目。我擔任較入門難度題目的出題組長，負責 Driver Killer 的整體框架與核心驅動程式。
問題與動機
Windows Driver 題目容易因環境、除錯門檻與核心概念過重而失去引導性。設計時需要兼顧可解性、漏洞脈絡與環境穩定度。
參賽者需要理解 Driver 行為，又不能被部署與環境問題阻塞。
同時涵蓋提權、CVE 與 TOCTOU，但仍維持交流題的循序提示。
方法與核心內容
題目以兩個具有漏洞的 Windows Driver 為核心，搭配使用者層程式、提權路徑與完整挑戰環境，讓參賽者從觀察介面一路定位漏洞。
實作兩個具可分析弱點的驅動程式，支撐主要解題路徑。
設計啟動、互動、權限與驗證流程，確保題目可重現。
技術脈絡
題目將使用者層入口、核心 Driver、競態條件與提權成果串成完整攻擊路徑。
兩個 Driver 組成的漏洞原語
最終題目預先載入兩個具有弱點的 Driver。第一個 Driver 接收 PID 與指定 key，檢查 PID 是否為 4（SYSTEM）後刻意等待 1.1451419 秒，再把 SYSTEM token 複製到請求中的 PID；第二個 Driver 則提供核心記憶體任意寫入能力。
預期解題觀察
- 從 user-mode 呼叫與 IOCTL 結構還原輸入欄位、key 與共享請求位置。
- 辨識『檢查』與『使用』之間仍引用同一份可被改寫的資料。
- 把任意寫入從單獨的危險能力，組合成可控制競態視窗的利用原語。
TOCTOU 提權鏈
利用程式先以 PID=4 通過權限檢查；在 Driver 進入等待視窗後，再透過另一個 Driver 修改共享 request 中的 PID，使後續 token 複製目標變成攻擊者程序。這個流程呈現典型的 Time-of-check to time-of-use：驗證成立的物件狀態，在實際使用前已被改變。
check(PID == 4, key) → wait → overwrite(request.PID) → copy(SYSTEM token, target PID)
Windows Kernel 題目環境
題目以 Windows OVA 提供一般使用者權限的起始環境，參賽者需要找到已載入 Driver、逆向介面並完成提權，最後讀取桌面上的 flag。設計時同時處理 Driver signing、32／64 位元差異、相依函式與乾淨 VM 的部署問題。
執行流程
參賽者需要先逆向 Driver 介面，再找出競態與可利用條件。
01 — 盤點 Driver 行為
分析 IOCTL、輸入資料與核心物件的處理方式。
02 — 定位漏洞條件
從程式狀態與時間差找出 TOCTOU 可利用點。
03 — 完成利用鏈
結合題目提供的環境與提權路徑取得最終成果。
出題時遇到的核心層工程問題
原先嘗試以多執行緒、PsCreateSystemThread 與 IoQueueWorkItem 建立競態，但同步 I/O 阻塞、核心工作執行與 Driver 載入穩定度都增加了環境不確定性。最終版本改以可預期的等待視窗與另一個寫入原語，讓漏洞概念仍然清楚。
賽後解題與失敗路徑
現場沒有隊伍完成預期的 Driver 利用鏈，部分隊伍改走非預期的腳本提權或 prompt injection。這反映題目除了程式碼正確，還需要在乾淨 VM 進行黑箱測試、移除旁路，並用提示確認參賽者能走到核心觀察點。
實作展示與攻擊證據
以下畫面依照參賽者實際會經過的順序，說明我在題目中準備的 Windows 環境、兩個漏洞 Driver、逆向線索與核心除錯資訊。完整的操作型解題影片與 GitHub 原始碼則放在本頁簡報下方。
題目起點：Flag 需要更高權限
參賽者以一般使用者進入 Windows OVA。桌面雖然直接放有 flag.txt，但目前權限無法讀取；因此第一個明確目標，就是從系統中找到能取得更高權限的攻擊面。
定位兩個自製漏洞 Driver
題目把 NotSuspiciousDriver.sys 與 CantWriteAnyDriver.sys 放入 Windows Driver 目錄並註冊成服務。名稱本身只提供模糊提示，參賽者仍需確認 Driver 是否載入、找到裝置介面，再從 user-mode 呼叫與 IOCTL 反推 request 結構。
C:\Windows\System32\drivers，與其他系統 Driver 一起出現在環境中。
.sys 路徑，可用來確認題目元件已在核心中載入。
NotSuspiciousDriver 提供具 TOCTOU 時間窗的 token 操作；CantWriteAnyDriver 則提供核心記憶體寫入原語。預期解法必須把兩者組合，而不是只利用單一 Driver。逆向驗證：PID 檢查、延遲與 Token 操作
反編譯結果會看到 Driver 先比較指定值與 PID 4，再呼叫 KeDelayExecutionThread 產生等待時間，之後才以 PsLookupProcessByProcessId 取得程序並參考其 primary token。檢查與使用之間的間隔，就是可被另一個 Driver 改寫 request 的競態窗口。
PsReferencePrimaryToken 等關鍵線索，讓參賽者能還原預期的 SYSTEM token 複製路徑。
sleep 就假設存在 race condition；還要確認等待前後使用的是同一份可被外部修改的資料，以及另一個 Driver 是否能精確覆寫目標欄位。賽後觀察：提示系統反而形成非預期路徑
題目原本希望參賽者從 Driver 逆向得到 TOCTOU 與 arbitrary write，但現場也出現利用提示／LLM 介面取得過多資訊的非預期方式。輸出直接指出 PID 4、race condition、token 與任意寫入原語，等同大幅縮短了核心逆向過程。
我的貢獻
貢獻比例 60%，擔任出題組長，負責創意整合、Driver 開發與環境整合。
- 01出題組長統整隊員研究方向，決定題目故事、難度與解題節奏。
- 02Driver 開發負責兩個漏洞 Driver 的核心實作。
- 03題目框架設計使用者層互動與整體挑戰結構。
- 04環境整合整合部署、測試與決賽現場需要的執行環境。
成果與反思
題目完成並於 HITCON CTF Final 交流賽提供其他隊伍挑戰，也讓我第一次完整走過 Windows Driver 的開發、逆向與漏洞題目設計流程。
完整簡報
實際解題影片與原始碼
簡報說明題目設計與 intended solution；以下影片則完整呈現實際操作過程，並可搭配 GitHub 中的 Driver、利用程式與題目環境交叉閱讀。