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 固件包中提取：NON-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 攻击面内存破坏类型混淆未授权访问整数溢出后门或测试指令信息泄露条件竞争文件操作未初始化变量逻辑漏洞类型混淆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 正确读取）默认的 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谢谢