iOS安全体系演进过程 及漏洞分析 从XcodeGhost说起 • 非官方的XCode在编译生成App的同时植入额 外的代码。新增代码可收集和上传用户部分隐 私数据，也具备伪造弹窗、分发广告等功能 部分厂商和用户反应 部分厂商和用户反应 iOS沙盒 ＋上架前审计 ＝ 安全 沙盒能完全保证设备安全么 ？安全 iOS沙盒 ＋上架前审计 ＝ 看个视频 完全信赖沙盒和审计＝自废武功 回到主题 • iOS安全架构发展时间轴 • 审视iOS代码签名策略：从进程创建到第一条 指令执行 • 总结 iOS安全架构发展时间轴 0防护 iPhoneOS 1.x Code Signing iPhonOS 2.x ASLR KASLR iOS 4.3 iOS 6 TouchID TeamID iOS 7 iOS 8 iOS安全体系经历了从无到有、从弱到强的发展 Kernel Integrity iOS 9 iOS安全架构发展时间轴 0防护 iPhoneOS 1.x Code Signing iPhonOS 2.x ASLR KASLR iOS 4.3 iOS 6 TouchID TeamID iOS 7 签名绕过漏洞对完美越狱非常关键 iOS 8 Kernel Integrity iOS 9 内容大纲 • iOS安全架构发展时间轴 • 审视iOS代码签名策略：从进程创建到第一条 指令执行 • 总结 可执行文件格式 • Mach-O: iOS/OS X上的可执行文件格式 可执行文件格式 • FAT Binary: 多个不同CPU架构的Mach-O 内核负责加载主程序 • FAT Binary解析漏洞 • 通过posix_spawn陷入内 核时，内核会试图从FAT binary中选择最匹配的 CPU架构 • 内核没有严格验证FAT header中的arch数目 漏洞代码 正常执行流程 • 内核加载主程序 • 主程序通过 LC_MAIN 命令指明主程序入口 • 内核加载dyld • dyld通过LC_UNIXTHREAD命令指明dyld的 入口 • 内核完成加载后，将控制流交回dyld（用户态） • dyld加载dylib后，将控制流交回主程序 iOS 8.2中的一个漏洞 • 内核并未主动验证主程序MachO头的签名 • 只有当dyld在用户态执行后才会去访问主程序 MachO头，触发page fault而引起签名验证 • 攻击思路 • 修改主程序的MachO头，强制其不加载dyld，同 时设置LC_UNIXTHREAD命令，将用户态的第一条 指令指向已有代码段，从而利用ROP的手段获得任 意代码执行 iOS 8.3中的修复 • 内核在注册主程序的代码签名段后就会访问MachO 头，进而触发签名检查 load_machfile parse_machfile exec_mach_imgact load_code_signature ubc_cs_blob_add K ern el EXEC V U serlan d mac_vnode_check_signature A M F ID 签名的实现 代码签名段 页面访问时的Sha1比较 iOS 8.3-8.4中的一个缺陷 • 代码签名实际校验是通过比对内存页面的SHA1值和 预存在代码签名段中的SHA1值 • iOS以内存页面大小（pagesize）为单位，预先存储 程序各部分的SHA1值 • 如果程序的大小不能被pagesize整除，在计算最后 一个SHA1值时，iOS并没有进行填充，而是计算实 际内容的SHA1 SHA1 程序的最后一个page 绿色代表程序中原有内容 签名段中保存的SHA1值