DEF CON 33 - Can't Stop the ROP: Automating Universal ASLR Bypasses - Bramwell Brizendine
三句話摘要
研究員在 DEF CON 發表利用 PEB Walking 與 ROP 鏈自動化繞過 Windows 高熵 ASLR 的技術，並公開釋出工具，微軟知情但拒絕修補。 Windows PEB 結構數十年來以固定偏移暴露於 User Mode，使高熵 ASLR 可透過少數基礎 ROP gadget 以接近 100% 的成功率被繞過，且微軟短期內無意修補，任何仍在使用非記憶體安全語言開發的 Windows 應用程式均應將此列為高風險攻擊面。 ASLR 的根本缺陷在於 PEB 結構長期以來對 User Mode 完全可讀。 PEB 內的 LDR 模組列表以固定偏移量組織，攻擊者只要能讀取 PEB，就能沿著雙向鏈結遍歷出任意系統 DLL 的 base address，從而徹底癱瘓 ASLR 的隨機化保護。
重點整理
重點- 1
ASLR 的根本缺陷在於 PEB 結構長期以來對 User Mode 完全可讀。 PEB 內的 LDR 模組列表以固定偏移量組織，攻擊者只要能讀取 PEB，就能沿著雙向鏈結遍歷出任意系統 DLL 的 base address，從而徹底癱瘓 ASLR 的隨機化保護。
- 2
此技術本質上是「倍增器」而非獨立漏洞。 攻擊者需要一個既有的記憶體損壞漏洞作為入口，但透過本技術取得 kernel32/kernelbase/ntdll 的 base address 後，可引入數千個額外 ROP gadget，大幅擴張原本受限的攻擊面，讓原本難以利用的漏洞變得可完整利用。
- 3
PEB 的讀取方式遠不只 GS 暫存器一種，其可攻擊面比想像中更廣。 研究員示範了四條路徑：GS+0x60、RDGSBASE 指令、兩個 Windows syscall（SSN 固定為 0x19 與 0x25，在 Win10/11 全版本一致），甚至可在記憶體中即時合成 RDGSBASE gadget，使防禦者難以靠單一管控點阻斷。
- 4
修補需要架構層級的改動，微軟目前無意推進。 研究員提出多種緩解方案（LDR 隨機偏移、指標加密、細粒度 ASLR、Execute-Only 記憶體），但均非簡單 patch 可達成。更關鍵的是，修補此缺陷同時會破壞大量依賴 PEB Walking 動態解析位址的 C/C++ 惡意程式，對防禦方效益極大，但微軟仍選擇不作為。
實用技巧與重點
乾貨- 工具與資源
- 工具名稱：ASLR Mini Bypass Tool，整合於 Drop Rocket（ROP Rocket 套件）
- 釋出時間：DEF CON 當天凌晨 3:00 am
- 輸出格式：完整 Python exploit 腳本
- 技術參數
- 支援架構：64-bit Windows，可搭配 Force Relocate
- 目標 DLL：kernel32.dll、kernelbase.dll、ntdll.dll
- 總變體數：9 種 ROP 路徑 × 4 種 PEB 洩漏方式 = 36 種繞過組合
- 測試成功率：100%（所有測試 OS 版本）
- PEB 存取偏移量
- GS 暫存器 + 0x60 → PEB（64-bit）
- FS + 0x30 → PEB（32-bit）
- R12 → TEB（WOW64 Heaven's Gate 模式）
- TEB + 0x60 → PEB
- 模組鏈結遍歷（以 kernel32 為例）
- PEB + 0x18 → PEB_LDR_DATA
- LDR + 0x30 → InInitializationOrderModuleList
- Flink 次數與 DLL base 偏移總和恆為 0x40
- kernel32 DLL base 需跟隨 3 次 Flink
- Syscall 參數（NtQueryInformationProcess，SSN=0x19）
- RDX = 0（ProcessBasicInformation）
- R8 = 任意可寫記憶體
- R9 = ProcessBasicInformation 結構大小
- R10 = -1（當前 Process handle，0xFFFFFFFFFFFFFFFF）
- 結果位移：結構 + 0x8 = PEB base address
- Syscall 參數（NtQueryInformationThread，SSN=0x25）
- R10 = -2（當前 Thread handle）
- 取得 TEB 後再加 0x60 得 PEB
- SSN 穩定性：Win10 與 Win11 全版本 SSN 固定，無需動態解析；若需支援 Win7 則需使用 SysWhispers / HellsGate / HalosGate 等動態解析技術
- 漏洞通報時間軸
- 2024 年 4~5 月：回報微軟
- 2024 年 5 月 1 日：微軟確認有效，但判定不符合「跨越安全邊界」標準，不予修補
- 2024 年 7 月：微軟邀請在 Black Hat 會面
- 2024 年 8 月 7 日：正式會議，歷時約 50 分鐘，微軟維持不修補立場
- Bug Bounty 預期金額：$5,000～$15,000，最終獲得 $0
- 類似前例：2013 年微軟曾修補相同性質的 ASLR bypass（利用可預測位址）
- 緩解建議（研究員提出）
- LDR Data Table Entry 隨機化插入不可預測間距
- 限制 User Mode 直接讀取 PEB / 封鎖直接 Segment Loading
- 指標混淆或 XOR 加密（類似 Windows 已有的 Cookie 機制）
- Fine-Grained ASLR（函數/基本塊層級隨機化）
- Dynamic ASLR（週期性 rebasing）
- Execute-Only 記憶體（硬體支援，PEB/Loader 頁面設為不可讀）
- 強化 EAF/EAF+ 啟發式規則，偵測異常模組列表遍歷行為
結論
結論“Windows PEB 結構數十年來以固定偏移暴露於 User Mode，使高熵 ASLR 可透過少數基礎 ROP gadget 以接近 100% 的成功率被繞過，且微軟短期內無意修補，任何仍在使用非記憶體安全語言開發的 Windows 應用程式均應將此列為高風險攻擊面。”
完整解析
詳細Windows 的高熵 ASLR（Address Space Layout Randomization）長期以來被視為對抗記憶體損壞漏洞的核心防線，其設計初衷是透過隨機化各模組的載入位址，讓攻擊者無法預測 gadget 的記憶體位置，從而阻止 ROP（Return-Oriented Programming）等技術的成立。然而，UAH Verona 實驗室主任 Bramwell Brzeznine 博士在一次 Bug Bounty 調查中發現，Windows 的 Process Environment Block（PEB）結構長期以固定偏移量暴露完整的模組載入資訊，且在 User Mode 下完全可讀。這個存在數十年的設計缺陷，使高熵 ASLR 形同虛設。
攻擊流程建立在 PEB Walking 這個惡意程式早已廣泛使用的技術之上，但研究員將其轉化為純粹依賴 ROP gadget 的形式，無需執行任何 shellcode。具體步驟為：首先透過 GS 暫存器（offset 0x60）、RDGSBASE 指令、或 Windows syscall（NtQueryInformationProcess SSN=0x19、NtQueryInformationThread SSN=0x25）之一洩漏 PEB 位址；接著加上固定偏移 0x18 取得 PEB_LDR_DATA；再加 0x30 進入 InInitializationOrderModuleList 雙向鏈結；最後依目標 DLL 跟隨特定次數的 Flink，並從結構中讀取 DLL base address 欄位。整個流程僅需少數幾種基礎 gadget 類型（pop、mov dereference、add/increment），且同一個 gadget 可重複使用，對各種 binary 的相容性極高。
研究員據此開發了一套自動化工具，整合於現有的 Drop Rocket 框架中。工具支援三個目標 DLL（kernel32、kernelbase、ntdll）與三種模組鏈結遍歷方式，再乘上四種 PEB 洩漏路徑，共生成 36 種繞過變體，輸出為完整可用的 Python exploit 腳本，並透過語義搜尋與指令模擬自動選取適合的 gadget 組合。研究員在 DEF CON 現場示範中，從執行工具到完成所有 36 種鏈的生成僅需數秒。值得注意的是，在 Windows 10 與 11 的所有版本中，上述 syscall 的 SSN 編號均穩定不變，攻擊者無需動態解析，進一步降低了利用門檻。
在漏洞揭露層面，研究員於 2024 年 4～5 月向微軟通報，微軟在 5 月 1 日回覆確認漏洞有效，但以「未跨越安全邊界」（需依賴既有漏洞）為由拒絕修補，亦未提供任何 Bug Bounty 獎勵。研究員指出，此缺陷的修補意義遠不止於 ASLR 防護本身：大量以 C/C++ 編寫的惡意程式正是依賴 PEB Walking 來動態解析 API 位址以規避靜態分析，一旦修補此結構，這類惡意程式將被迫改用可輕易被 PEStudio 等工具偵測到的正常 import 或 GetProcAddress，對整體惡意程式生態將產生深遠影響。然而，真正徹底的修補需要架構層級的改動（例如 LDR 隨機偏移、指標加密或 Execute-Only 記憶體），微軟目前並無相關計畫。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
