06李中權-深入Android可信應用漏洞挖掘.pdf

1、深 入 A n d r o i d 可 信 應 用 漏 洞 挖 掘李中權About Me啟明星辰 ADLab 移動安全專家、高級安全研究員專注于 Apple、Android、IoT 的漏洞挖掘與 Fuzzing小米 SRC Top 1發現 Apple、華為、榮耀、小米、三星、聯發科、OPPO、VIVO 等主流廠商的高危漏洞曾在天府杯上完成產品破解目錄05 TA 的 Fuzzing06TA 攻擊面分析07TO DO01TEE 介紹02主流 TA 的架構實現和逆向分析03如何對 TA 做安全研究04TA 的模擬TEE 介紹TEE 介紹什么是 TEE？全稱為“可信執行環境”（Trusted Exec

2、ution Environment），是位于主處理器中的一個獨立的安全區域TEE 的角色？TEE 為運行在其中的應用程序提供了一個隔離的環境以保護應用程序和數據免受其他軟件的攻擊。TEE 常用于處理敏感的數據，如密碼、密鑰、生物識別數據等。即使設備的主操作系統被攻擊，TEE 中保存的敏感數據和安全策略也不會受到影響基本概念什么是 Normal World？指設備的主操作系統環境，包括運行的應用程序和操作系統本身。這個環境通常包含用戶的各種應用程序和服務，但是它并不被認為是安全的，因為它可能受到各種各樣的攻擊。在本次演講中，Normal World 和 REE 都指的是 Android 操作系統

3、什么是 CA？Client Application，這些應用程序運行在設備的主操作系統（即“Normal World”）中，并通過特定的 API 與 TEE（也被稱為Secure World）通信通用架構圖Normal WorldAPP APPAPPAPPFramework ServicesEL0Android KernelEL1HypervisorEL2TA TATATATA TATATAS-EL0TEEOSS-EL1Trusted FirmwareEL3Secure World可信應用 TA 承擔的作用敏感數據的安全存儲(Eg:指紋、圖片、用戶密鑰)安全通信完整性校驗安全的加密策略DRMe

4、tc為什么會對 TA 做安全研究？2022 年下半年本想對 TA、TEEOS、ATF 整體做漏洞挖掘但挖掘 TA 時發現 TA 的漏洞多到超乎想象，故針對部分主流廠商的 TA 做了漏洞挖掘目標：基于 OP-TEE 的自研 TEE小米的 MiTEE MTK 某國產廠商自研的 TEE 高通、Kinibi華為、三星：（彼時剛有研究員分析過，故有架構分析但未深入挖掘）60 處漏洞被確認（含撞洞）因廠商漏洞披露策略的限制，省略部分漏洞細節主流 TA 的架構實現和逆向分析理解 CA 和 TA 的通信12345CA 調用 API 與 REE Driver 通信REE Driver 初始化請求，封裝必要的參數

5、并通過 Secure Monitor 發送給 TEETEE 接收到請求后，將 TA 鏡像文件的內容從 REE 側加載到 TEE 的共享內存中TEE 校驗 TA 的完整性、證書簽名、版本等校驗通過后，TEE 加載 TA，進入 TA 的生命流程Global Platform TEE Client API 規范標準化開發流程提升 TA 開發的效率用 Session 管理創建、打開、關閉會話的流程以及與 TA 的交互方式規范會話中的命令調用以及輸入/輸出參數的管理理解 Global Platform 規范中 TA 的生命周期12345TA_CreateEntryPoint TA_OpenSession

6、EntryPointTA_InvokeCommandEntryPointTA_CloseSessionEntryPointTA_DestroyEntryPointGP TEE Client API TA 的基本定義TA UUID根據 TA 處理外部數據的方式，我將 TA 分為兩類遵循 Global Platform TEE Client API 規范的 TA使用 TEE_Params 結構做數據交換如：MiTEE、HTEE、OP-TEE 以及很多基于 OP-TEE 二次開發的 TEE使用二進制數據流的 TA從外部傳入的二進制數據流中讀取數據廠商可能自行實現了新的數據傳輸和處理的協議也可能基于

7、Global Platorm 規范做了二次封裝，限制了調用 TA 的參數類型如：高通 QSEE、Kinibi TEE一款 TEE 中可以同時存在這兩種 TA如何分析 CA 和 TA 的調用流程不同的 TEE 實現有不同的調用流程，授人以魚不如授人以漁通用的分析思路：ps A|grep calsof p$ca_pidCA 和 TA 的調用流程基于 GP 規范的 TA 的方法調用CA 和 TA 的調用流程高通 TA 的方法調用TA 的實例多實例（Multi-Instance）：多個 CA 可以同時與同一個 TA 進行交互，每個 CA 的交互不會影響其他的 CA單實例（Single-Instance

8、）：TA 只有一個實例，所有的 CA 共享同一個 TA 實例。如果一個 CA 正在與這個 TA 交互，其他的 CA 必須等待直到當前的交互完成對于單實例 TA，常見于 Fingerprint TA，測試時建議使用 Frida hook 其 CA 后再跟 TA 通信，否則需 kill 掉原始 CA 并自行配置 TA 的初始化，該邏輯一般很復雜，耗費精力TA 的提取常規的 TA：從設備上提?。ㄐ枰?Root）：從 OTA 固件包中提?。篘ON-HLOS.imgsystem.img/vendor.img/product.img/odm.img嵌入式 TA（如三星 TEEGris 中的部分 TA）：分

9、析并按 TEEOS 的特定鏡像格式解析逆向分析MDT format TAs https:/ format TAs https:/ OP-TEE based format TAsRemove their headersTA 的逆向分析如何對 TA 做安全研究對 TA 做安全研究的難點123很難或完全無法調試 TATEE 與 Android 系統獨立軟件調試基本不可能，部分 TEE 可借助 JTAG 進行硬件調試CA 調用 TA 的執行 Log 被關閉或者加密，無法得知 CA 請求的執行結果大部分 TA 都包含敏感的內容或功能，故只有擁有一定權限的 CA 才能調用指定 TA研究員需要先提權到某個

10、Group、System 或 Root 權限才能調用 TA部分廠商還限制了能夠調用該 TA 的進程，需要攻擊者先拿下指定 CA 或內核的權限才能跟 TA 通信 TA 的安全研究在真實的手機設備上使用模擬工具在真實的 Android 設備上針對 TA 做安全研究本地 SYSTEM/ROOT 提權解鎖 BOOTLOADER：NDAY 或者 0 DAY借助跳板實現攻擊本地 System/Root 提權https:/ AI，效果更佳本地 System/Root 提權可用于安全研究的漏洞可武器化的漏洞額外關注：僅可用于安全研究的本地提權漏洞01非默認配置的漏洞需要預先授予輔助功能的漏洞020304如：通

11、知欄中的PendingIntent 劫持漏洞需要授予其他敏感權限的漏洞其他需要多次用戶交互的安全漏洞解鎖 BootLoader難嗎？解鎖了 5 款手機的 Bootloader3 款手機（N Day）2 款手機（0 Day）解鎖 Bootloader：N Day最新的旗艦手機？解鎖 Bootloader：N Day最新的旗艦手機？NO子品牌、發布了很久甚至不再維護的手機，但能運行最新的 OEM 系統？YES最終：解鎖這類手機的 Bootloader 后，就能獲得在真機上測試 TEE/TA 的能力在 Exp 編寫完成后，即可在最新版本的旗艦機上直接使用我們的目標很簡單：擁有一臺具備最新系統的手機手

12、機的版本、配置、是否仍在維護無需關心該漏洞能否被武器化（如是否清除用戶數據）、是否是默認配置亦無需在意解鎖 Bootloader：0 Day+N Day修復解鎖 Bootloader 的漏洞 與 修復普通應用的漏洞的策略 有本質區別故廠商在修復解鎖 Bootloader 的漏洞時，不僅需要提供該漏洞的 Patch，還需要封禁用戶降級到漏洞版本的能力老版本系統的 Bootloader 被解鎖，攻擊者可自行刷入最新版本的系統從而保證在最新系統上仍然獲得 Root 權限部分手機亦可直接更新系統，廠商的 OTA 邏輯并不會回鎖 Bootloader解鎖 Bootloader：0 Day+N Day國內

13、主流廠商都對手機降級有嚴格限制部分手機需要先降級到一個中間包，才能再降級到指定版本部分手機需要使用廠商提供的降級工具才可降級廠商提供了一些安全策略來保證降級策略不被繞過，如公私鑰、簽名、降級 Key 等但廠商的防降級安全策略真的安全嗎？并不是。手機降級是很正常的用戶需求，在安全性和用戶體驗的考量中，廠商很容易做出妥協，為用戶開辟例外。我們只需專注于找到這些例外單純的安全策略實現漏洞出于廠商隱私保護需要，省略這部分的漏洞細節TA 的模擬TA 的模擬Unicorn輕量級、多平臺、多架構的CPU模擬框架，基于QEMU支持多種架構ARM/ARM64,MIPS,x86/x64平臺獨立的特性以及友好的AP

14、I選擇：Qiling Framework 或 基于 Unicorn 二次開發方案 1：Qiling Framework 基于 Unicorn 做二次開發，目前已經非常成熟，開發了很多必要的功能幫助開發者快速模擬和 Fuzzing。方案 2：自己基于 Unicorn 做二次開發，工作量更大，但定制化能力更強。最終：本次研究的目標為業內部分主流的 TEE 的 TA 實現，目的是構建通用的模擬和 Fuzzing 框架。因每個 TEE 的 Syscall 都不一樣，為避免在兼容性上耗費太多時間，采取方案 2。但若后續針對指定 TEEOS 做安全研究，會轉向 Qiling Framework。Memor

15、yLayoutTA BinaryStackHeapShared memoryAdditional componentsSession，file storage，etcTALoaderSet ContextLoad TA in GP formatLoad TA in MDT formatDependency parsingLoad TA in MCLF formatRelocationLoad TA in Custom formatHookHook TA functionsCrash Patch HandlerVulnerability CheckerSyscall ImplInputParse

16、 Input as Data StreamParse Input as GP FormatParse Input in Custom FormatInput checkerLogLogBacktraceDuplicate Fuzzing ResultsDebugTA 的 Fuzzing：AFL-Unicorn無狀態的 Fuzzing無法發現需要苛刻觸發條件的漏洞基于 Crash 的漏洞檢測會漏掉大量的安全漏洞NO ASANAFL-Unicorn 的堆溢出檢測Free：Patchhttps:/ Fuzzing？序列化請求預先執行并保存上下文（基于快照）CVE-2022-32602(1)CVE-2

17、022-32602(2)TA 的攻擊面分析TA 攻擊面12345678910內存破壞類型混淆未授權訪問整數溢出后門或測試指令信息泄露條件競爭文件操作未初始化變量邏輯漏洞類型混淆Global Platform 規范采用 TEE_Param 結構封裝請求數據，開發者需自行校驗外部輸入的參數類型是否合法 TA 的類型混淆無一幸免。只要廠商的 TA 遵循了 Global Platform 規范，總有一個或多個 TA 存在該漏洞該漏洞的漏洞發現和修復都很簡單，但影響大，能被直接漏洞利用的概率高，存在該漏洞的 TA 多我認為的根本原因：TEE 授予了開發者過大的權限，將 TA 接受和處理外部參數類型的危險

18、能力授予了開發者從開發效率和易用性上看，這種策略沒有問題但對開發者的要求過高。如果開發者沒有很好的理解 TA 請求中的參數類型或單純的疏忽，采用了不安全的方式處理外部輸入，就會造成很嚴重的安全問題。CVE-2023-20652防護 TA 的類型混淆漏洞：建議的開發方式TA 在獲取外部輸入時，需要校驗 ParamTypes 以及調用 TEE_CheckMemoryAccess 函數防止非法輸入更通用的辦法：可將外部輸入參數的類型校驗功能封裝為 SDK，限制外部傳入的參數類型只能為共享緩沖區即，收回開發者對于 TA 參數校驗的能力限制開發者只能從共享緩沖區中讀取數據該策略對開發無任何影響，但能極大

19、的提高 TA 的安全性內存破壞：指紋 TA指紋 TA：攻擊指紋匹配度信息泄露通過漏洞泄露：通過 Log 泄露：（檢查/proc 目錄 或 cat/proc/kmsg）：基于 OP-TEE 的 TEEKinibiTEEGrisLog 被加密或者關閉了？檢查/proc 和/vendor，可能有彩蛋邏輯漏洞：提取手機中用戶保存的明文密碼KeyStore:https:/ Keystore 解密該應用的所有加密數據邏輯漏洞：提取手機中用戶保存的明文密碼邏輯漏洞：提取手機中用戶保存的明文密碼邏輯漏洞：提取手機中用戶保存的明文密碼從功能和使用效果上劃分，我將 Keystore 的用戶身份認證策略劃分為 2

20、種：1.用戶校驗指紋或 Pin 碼，TA 返回 true 或 false 的校驗結果并保存當前授權的時間 之后用戶再觸發數據解密時，TA 會校驗一次最近的授權時間，超過一定毫秒就認定非法（如500，1000），只有合法才會解密數據，之后返回解密結果給 REE 的 CA2.用戶校驗指紋或 Pin 碼:如果校驗通過，觸發 onAuthenticationSucceeded 回調，TEE 返回被二次加密過的解密密鑰給 REE，REE 層把解密密鑰和密文發送給 TEE 從而解密數據這 2 種策略的核心都發生在 TEE。REE 層無法 Hook 或干擾，從而保證在 REE 淪陷的情況下用戶的數據仍然安全

21、 邏輯漏洞：提取手機中用戶保存的明文密碼很好的Demo：https:/ 中的自動填充服務：https:/ OEM 廠商均可實現自己的自動填充服務策略本次分享中使用 Pixel 5a 做演示邏輯漏洞：提取手機中用戶保存的明文密碼issue-241204654:com.google.android.gms看起來 GMS 使用了需要用戶身份認證才能獲得用戶明文密碼的安全策略，但實際呢？邏輯漏洞：提取手機中用戶保存的明文密碼GMS 在初始化密鑰階段并未設置 setUserAuthenticationRequired（true），故 GMS 實際上并沒有使用“需要用戶身份認證”的 API 來保存用戶的明

22、文密碼，解密本地的密文并不需要通過指紋校驗之所以 UI 流程上看起來有指紋校驗的步驟，只是因為 GMS 在 REE 層獨立調用了指紋校驗的 API，該校驗的結果并不會影響 TEE 的解密策略這意味著：在 REE 淪陷的情況下攻擊者可直接觸發密文的解密策略，或者單純篡改 REE 保存的指紋校驗結果以執行解密策略邏輯漏洞：提取手機中用戶保存的明文密碼frida-U-l bypass.js-n com.google.android.gms.ui即，System 權限便可提取本應由 TEE 保護的用戶數據。對于用戶密碼的防護等級明顯不足跳板因為權限和調用方校驗，目標 TA 無法被直接攻擊可通過攻擊其他

23、 TA 來進行攻擊Android 側的普通App缺乏權限，無法跟 REE Driver 通信可通過系統服務或預裝應用暴露的接口完成攻擊，如 IFAAIFAA部分 TA 因業務需要，并無任何權限限制。任意三方應用都可通過 Android 側預置的 CA 暴漏的接口與目標 TA 通信，并不需要直接與 TEE Driver 通信https:/ 廠商需要自行實現 IFAA 的邏輯向指定文件寫入 AAA 的 PoC該漏洞也支持讀取任意文件，如支付密鑰文件操作Android 側的攻擊者雖然無法解密該數據，但能直接刪除或修改原始文件的內容（修改的內容無法被 TA 正確讀?。┠J的 OP-TEE 的文件操作

24、API 并不存在路徑穿越漏洞。但部分廠商自行實現的 TEE 系統構建了自己的文件交互 API，甚至直接使用了 C/C+的文件操作函數，導致路徑穿越漏洞重現多實例 TA 對于同一個文件的操作可能存在條件競爭如指紋模板，因數據過大，通常使用 AES 加密后保存在 REE 的文件系統中，AES 的 Key 包括 UUID+HUK 等RPMB 和 SFSTEE中的數據存儲保存在 SFS 中的數據攻擊面TO DOTO DOTEEOS 和 ATF 的模擬和 Fuzzing借助 AI 提升 Fuzzing 的效率和數據變種的策略Some New FindingsMacOS 通用沙箱逃逸（10.15 14.0）多個 MacOS Full Disk Access 提權（10.14 14.0）MacOS 本地提權etc.See you next year謝謝