记 MOSEC 2020 及上海一游 (1)

记 MOSEC 2020 及上海一游 (1)

也算是自己人生第一次“出差”,体验还是相当不错的,这里留下小记,也算是表达对各个发言人以及主办方能在这个疫情下安排出此次会议的敬佩了。P.S. 这次会议的门票应该是作为善款继续加油战疫了


先给出会议的一个时间表(印在每个人发的牌牌上)

MOSEC2020 Outline

其中报告一共有五场,另外就是MOSEC经典的BaiJiuCon文化;由于会场似乎是要求禁止拍照录用(当然形式上是这样)白天的五场talk只好简单的讨论一下,简介性的内容可以阅读看雪的这篇推送

但BaiJiuCon会场都开了直播了(斗鱼直播,5lipper,暂时还没上传似乎),内容也相当精彩,相关我会另开一篇文章来简单介绍

MOSEC 2020移动安全技术峰会精彩一览mp.weixin.qq.com图标


P.S 如果文章有任何侵权请联系我删除~

议题一,深入理解苹果操作系统IO80211 Family网络组件

演讲嘉宾: 王宇

主讲简介: 滴滴出行美国研究院资深专家工程师

内容简介:

简单来说,王宇大神就苹果设备的Wi-Fi子系统从 IO80211FamilyV1 升级至 IO80211FamilyV2 的发展进行了探索,并对其中的安全问题进行了研究。这里他很简练地将Wi-Fi子系统的攻击面概括为如下三点

  1. From remote and local firmware to operating system kernel
  2. From user-mode daemon and framework to operating system kernel
  3. All other handlers and parsers for input parameters

其中第2点是大家比较熟悉的通过用户态程序交互进行权限提升(多是系统调用或者iotctl等)而第1点与第3点都相对陌生一些,其中第3点就我的理解来说是对于前两点的补充,如协议设计问题以及嵌套子系统问题,暂且不去纠结,而第1点,通过固件作为跳板攻击操作系统内核这个方式确实是powerful的(下面会给一些links)

主讲人接着便从他发现V2专有的漏洞,V1和V2共有的漏洞和只有V1版本存在的漏洞等等要点进行了介绍

王宇大神说他写的一个简单fuzzer能在一小时内就把整个硬盘塞满panic数据 所以有兴趣赶紧去 fuzz 苹果 Wi-Fi 哈哈

首先是 CVE-2020-9834,一个循环未检查边界造成的越界写漏洞;然后是 CVE-2020-9833的一个未有效初始化带来的漏洞;还有就是一个任意写漏洞,不过因为苹果还没修所以没有介绍(有兴趣的可以关注呀)这些CVE细节应该都以在网上搜到,这里就不赘述啦。

给出大神列出的 takeaways

  • IO80211FamilyV2 and AppleBCMWLANCore integrate the original AirPort Brcm 4331/4360 series drivers, with more features and better logic
  • New features always mean new attack surfaces
  • The combination of reverse engineering and Apple SDK means a better life
  • Several brand new kernel vulnerability case studies

Links:

如何写一个可以在苹果上兼容运行的Wi-Fi框架 —— 11208elppA
part-1: newosxbook.com/articles
part-2: http://newosxbook.com/articles/11208ellpA-II.html

苹果的Wi-Fi基础
Intel Wifi for MACOS: github.com/AppleIntelWi
itlwm: github.com/OpenIntelWir
Voodoo80211: github.com/mercurysquad

Apple Wireless Direct Link (AWDL) 协议研究
bugs.chromium.com/p/pro

SkyWalk Subsystem
newosxbook.com/bonus/vo

Incomplete write primitive utilization
blackhat.com/docs/asia-

Apple泄露的一些SDK
github.com/phracker/Mac

王宇大神写的 OSX Kernel hook 框架
github.com/didi/kemon

感悟和思考:

从一个参会者的角度来说,这第一个talk属实让人胃口大开。不仅内容精彩,主讲人十分幽默的形式让人十分好评。

虽然不是做苹果系统,但最近对Wi-Fi固件安全还是有所涉猎的,整个听下来共鸣挺多,一点点感悟思考如下

  1. 逆向,毕竟没有源码(即使是开源的Linux,其使用的固件的代码也是厂商的,大多烧在ROM里面),逆向是最头疼的工作,除了像主讲分享的可以利用一些SDK的泄露、log函数的format等方式方便逆向的进行,但要做到熟练似乎只能依靠实战了
  2. 更新与攻击面的思考,该议题的落脚点便是苹果Wi-Fi的升级以及新的特性的引入,此中的代码迁移以及代码重构、添加都伴随着可能的安全问题


议题二,DroidCorn: 无源码Android Binary Fuzzing新实践

演讲嘉宾: 何淇丹

主讲简介: 传说中的Flanker,前科恩实验室高级研究员(似乎也是浙江大学的前辈?)曾拿下如Black Hat Pwnie Award最佳客户端漏洞提名以及Google Android Security Top Researcher称号。现在似乎主要在某互联网企业担任安全总监。

内容简介:

Flanker在演讲的过程中提到的:想要给出一款针对Android binary“开箱即用”的高效Fuzz框架,其演讲的核心内容——DroidCorn在设计上充分关注效率问题,做到“天下武功唯快不破”的实现。

在演讲的开始前奏中,主讲先给出了模糊测试的state of art

  • Fuzzing need some sort of "feedback"
  • de facto standard of modern fuzzing: Coverage-Guided (CGF)
  • coverage information is the key
    • compiler instrumentation w/ source code (GCC, LLVM)
    • hardware-based: processor trace
    • binary-based: static rewrite / dynamic tracing

对于fuzz,我们知道guided fuzzing的效果要远超于random fuzzing,而现有实现中coverage-based已经成为了工业界中的主流;为了能够获取程序运行的coverage信息,“代码插桩”是针对具有源码测试的主要解决方案(如AFL);此外,为了效率,有部分工作利用硬件特性来获取相关信息(x86的调试寄存器)。该两个方案的优点是准确,高效,但缺点也十分明显:前者需要源代码以及重新的编译,而后者对硬件有要求所以迁移性很弱。

Flanker介绍的DroidCorn主要面向第三类即没有源代码的纯binary测试,其获取coverage信息的解决方案主要有两种

  1. static rewrite 静态改写,比如通过插入hook跳转的方式来实现对binary的patch
  2. dynamic tracing 动态跟踪,使用模拟器来完成比较准确的追踪

对于DroidCorn工作而言,由于静态改写可能带来的对于反编译工具的挑战,ELF兼容性的伤害以及对于crash追踪的不准确性等缺点,主讲选择以Dynamic tracing作为其设计核心。

So far so good,对于动态跟踪,为了兼容性以及调试等优点,基本是采用QEMU的实现来完成的,DroidCorn也不例外。这里有关QEMU的一些细节就不做详细介绍了(如TCG、TLDR等概念,感兴趣的读者可以自行搜索)

为了能够在x86平台上高效的对ARM/AARCH64的安卓二进制程序进行测试,DroidCorn主要采取如下的思路以及框架

DroidCorn ARCH: A C++ framework that wraps arbitrary ARM/AARCH64 binary and turns it into fuzzable x64 target for AFL, run on arbitrary platform.
  • Crash Triager: Trace Recorder, Symbolizer
  • Mini Runtime: ELF Linker, MiniHeap, MiniHooker
  • Mini Kernel: Memory Layer, Syscall Handler
  • Processor: Unicorn Engine, Forkserver, Tracer

针对四层设计,DroidCorn都有好的idea和挑战,这里考虑到保密性就不做细节介绍了(比较典型的是使用host端的heap manager来替代了程序原本的libc jemalloc来完成加速,以及打开TB chaining完成加速)

实验验证方面,DroidCorn使用Samsung手机上的Quram图像处理库代码作为对象。首先完成对于库代码的一定逆向后,便可以编写fuzz的设置,最后有如下的实验结果

  • ~200/sec per core, ~6000 per server的运行效率
  • 7379的大数量crash发现
  • 找到如OOB read/write, arbitrary free, heap overflow 等等漏洞

对于未来工作方面,Flanker期待进一步完成优化工作,如简化回掉的开销,甚至思考是否可以强迫QEMU将tb编译,以AOT(ahead of time)的方式战胜现有的JIT(just in time)

最后给出 takeaways

  • CFG fuzzing on blackbox binaires
  • QEMU modes of fuzzing
  • DroidCorn design decisions and benefits
  • Samsung Quram fuzzing and bugs

Links:

American fuzzy lop 原来原名是一种小兔子呀
github.com/google/AFL

给予qemu-user以及像capstone, unicorn和keystone等的分析综合工具usercorn
github.com/lunixbochs/u

Android Native模拟 Allows you to partly emulate an Android native library
github.com/AeonLucid/An

enhanced AFL改进版 AFL++
github.com/AFLplusplus/

基于unicorn加强的afl
github.com/Battelle/afl

Improving AFL's QEMU mode (TB chaining)
abiondo.me/2018/09/21/i

QASAN: 基于QEMU的address sanitizer
github.com/andreafioral

Designing New Operating Primitives to Improve Fuzzing Performance
taesoo.kim/pubs/2017/xu

感悟和思考:

大概率后续也会接触一些fuzz的研究的,该工作提供的思路以及相关links感觉都很有价值;模糊测试除了好的guided切入外,其实效率确实是非常非常重要的一环,跑的越多自然理论上就可能找到更多的crash,这里通过将ARM/AARCH64的二进制程序转化到x86平台上进行模拟运行与测试,优化了效率(其实个人更疑惑直接使用ARM/AARCH64的server是不是会更快,当然Droidcorn这么做迁移性会好很多)


议题三,深入浅出JSC优化措施

演讲嘉宾: 招啟汛

主讲简介: Pwnie 2019最佳提权奖项的获得者,奇虎360 Vulcan团队成员

内容简介:

Safari引擎中的优化措施安全问题研究;由于不熟悉浏览器以及JS引擎,外加主讲的整个展示过于详细(精准到代码行那种)所以在没有一个框架性认识的前提下我基本没有听懂多少

这里稍微给定一点陈述好了,最重要的应该是介绍招神的挖洞思路

  • 主流的JS引擎:Chakra, V8, JSC, SpiderMonkey
  • 倒序挖洞法:这里主讲给出了一条他比较常用的倒序链
    • RCE
    • 任意地址读写
    • 伪造对象
    • 不同类型的数组混淆

从我的理解上,这里的倒序挖洞法意指先找到最重要的漏洞利用点,然后再考虑一步一步该如何去解决触发漏洞过程的细节,这样就能保证挖到高质量可利用的好漏洞(但过程感觉会比较艰辛?)

整体来说分享主要介绍了招神找到的一个JSC上的数组类型混淆漏洞以及整个POC的编写挖掘思路,细节过于复杂还是省略好了 XD

Links:

MOSEC 2018 talk, Remote code execution in Mobile Browser
mosec.org/en/2018/

循环优化时因为opcode导致的value问题
github.com/microsoft/Ch

类似问题链接 (webkit patch)
github.com/WebKit/webki
github.com/WebKit/webki

感悟和思考:

由于没听懂啥,思考自然也有点跟不上了。真要说的话,还是觉得做talk要尽可能面向不同技术栈的听众吧 XD...


议题四,Surge in the dark

演讲嘉宾: slipper

主讲简介: 上海交大0ops的联合创始人,盘古团队的安全研究员

内容简介:

此议题就安全研究者视角分析和体验了小米的澎湃S1——第一代自主研发的SoC国产芯片。

分享中,slipper也cite了招神的倒序挖洞法:为了能够突破这一款SoC的安全设计,他首先思考如何可以干掉手机的secure boot,实现上他通过逆向发现该芯片的bootchain过程中保留了许多原汁原味的“调试”接口,如基于串口的shell调试(虽然好像拆机实验中没有成功连上uart)以及sysparam的子系统。slipper发现如果能在init过程将soc-id的值修改为0,就可以在启动中跳过所有的检查,即关闭firstboot过程中对于secondboot以及trustzone启动的检查以及secondboot中对于内核启动的检查;

这里给出slipper猜测的启动流程来帮助大家理解

  • romboot检验firstboot代码
  • firstboot
    • 检验secondboot以及trustzone
    • 失败后跳转入fastboot
  • secondboot
    • 判断boot reason
      • normal
      • recovery
      • bootloader

好的,有了这个可以长期绕过启动检查的原语,接着slipper就倒序开始找如何实现这个原语了。首先关于安全运行的Trustzone,澎湃S1是依赖开源的OP-TEE进行实现的,先不说使用开源的Trustzone比较low的事实(毕竟Samsung以及其他牌子手机都有自己闭源的TEE环境),澎湃S1也停了对于Trustzone组件的更新,导致了如可以降级这样的安全问题。更有甚者,澎湃S1由于不同组件之间版本的不兼容性,其SELinux策略并没有实际得到执行,导致系统内普通的用户态程序也可以和Trustzone中的ta进行交互。

挖洞过程中slipper首先分析用户态像TA申请服务的封装,结果是堆溢出多到屏幕也放不下;而对于TA的代码实现,则发现了有效的栈溢出漏洞。在找到有效的ROP gadget后,就实现了在Trustzone EL1层面的RCE。

下面给出整个利用的roadmap

  1. 利用untrusted app与Trustzone S-EL1层中的TA进行交互
  2. 利用TA中的漏洞实现RCE
  3. 通过RCE去hack unsafe world中的Kernel
  4. 通过Kernel影响Firstboot过程中的soc-id
  5. 通过恶意的soc-id长期影响kernel以及trustzone的启动

笔者没有接触过在Trustzone环境下实现exploit并改写unsafe world kernel memory这样的操作,接下来的内容也不细数了,有时间确实可以尝试尝试。

Links:

OP-TEE即其安全问题
github.com/OP-TEE
op-tee.org/security-adv

感悟和思考:

这篇工作整体给人感觉有点老——毕竟研究的对象是已经不再推送安全更新的小米澎湃S1,但其研究方法、挖掘思路以及相关知识点还是很让人受用的,包含SELinux以及Trustzone环境下的kernel exploit是非常具有挑战性的,相信自己未来也会遇到


议题五,攻击SEP的安全启动

演讲嘉宾: 徐昊

主讲简介: 盘古团队联合创始人!徐昊老师拥有者超过10年的信息安全领域从业经验,研究领域涵盖了操作系统安全、漏洞利用技术以及Rootkit检测,硬件虚拟化技术等等。

内容简介:

算是boss做收官的分享吧,关于iPhone的硬件架构SEP(Secure Enclave Processor)的安全研究。核心内容是基于去年公开的checkm8漏洞,通过iBoot过程的恶意代码来去挖掘SEP OS中的安全漏洞,进而影响SEP的启动过程。

首先就SEP做一点点简单介绍,对于iPhone的硬件架构,其在5S版本开始引入SEP来负责处理用户的锁屏密码以及生物信息比对等安全功能。SEP相比于传统的安全策略,通过使用专门的处理器以及较为独立的SEP OS来与传统的AP(Application Processor)分隔开来。这样即使攻击者攻破了AP中的应用,其仍然无法直接影响SEP内部的代码和数据。

如下图,iPhone的启动实际上包括了AP的启动以及SEP的启动;

其他的一些基础概念这里简单的过一遍,感兴趣的读者可以进一步搜索了解

  • SEP的启动加载的是苹果自己的一套IMG4镜像
  • 载荷的验证依靠ROM中的代码以及Apple's root CA public key合作完成
  • SEP处理器有其独立的随机nonce来处理DFU(Device Firmware Update) 以及Recovery
  • @axiOmx 实现了 checkm8 的exploit,其可以在iPhone X及以下版本中在 DFU 状态下完成任意代码执行;由于漏洞代码是在ROM中的,该漏洞基本无法被“完全”修复
  • SEP往往通过Mailbox以及Shared Memory来完成与AP world的通信

接着主讲人针对 SEP Boot 的过程做了比较详细的分析,其中包含

  1. 启动跳转与MMU的打开(以及TTBR寄存器设置细节及虚拟内存的配置),thumb指令集合的切换
  2. 其他寄存器环境的初始化(包含栈寄存器SP、VBAR寄存器、CPSR等等)
  3. Mailbox的注册以及实现
  4. memory protection 的打开,其中 SEP 内存由 TZ0 描述,其保护使用如下的方式
    - Isolation: 通过lock方式防止AP端访问SEP的内存
    - Encryption: 通过AES engine完成对SEP内存的透明加密解密
    - Integrity: 通过checksum
  5. ......

这边有着相当多的技术细节,有需要的读者还是尽可能自己去读手册和paper理解。总之在各个工作都准备好后,SEP即开始加载从AP发送来的SEPOS;首先其将接收到的IMG4固件存入保护内存之中,然后进行验证操作。通过验证后生成AES的密钥用于SEPOS channel的加密通信,完成参数配置后进入SEPOS的启动。这就是整个完整的boot过程

攻击面方面,主讲人就三点进行了讨论

  1. Mapped IO registers
  2. SEP messages
  3. IMG4 parser

而真正hacking过程,首先使用checkm8的攻击方式完成对iBoot的patch,并通过修改TZ0_baseTZ0_end两个配置值影响memory isolation的实现从而可以泄露SEP的内存内容,绕过SEP内存的锁保护;

在可以读写SEP内存后,就要解决被加密保护这一道关卡;在实现中,有2个page是没有被加密保护的(就理解来说似乎这两个page主要管的是加密初始化前的内容?)通过进一步的调试,发现初始化密钥使用的随机数会先驻留在这一段区域中。那么,主讲人提出了如下的利用方案

  • 通过checkm8完成对iBoot的代码patch,并调整TZ0寄存器的配置
  • 在"boot tz0"过程中,从AP层不断向物理地址 0x8_00BF_F018/0x8_00BF_F048区域写常量值(即race存储随机数的位置)
  • race失败则重启重复,直到成功

完成这一段加密channel随机数的racing后,还有另外一个channel(SEPOS启动所用数据的channel),这里主讲本想使用一样的方法去race随机数的,但结果是失败了。他给出的原因是:

  • 成功的案例中,存储随机数的位置被标记为device memory,这一段数据IO不会经过cache,所以AP处理器和SEP处理器之间的race可以成功
  • 失败案例中,存储随机数的位置被标记为normal memory,导致在两个处理器在IO过程中引入了cache,为racing提升了巨大的难度

虽然这个解释是说得通的,但是否是准确的呢?可能真的需要手动去做了才能理解吧 :D

总而言之言而总之,主讲人利用已有的方式完成了如下的目标和成就

  1. TZ0 memory isolation的攻破
  2. Deriving key时使用的随机数的racing攻击

Links:

checkm8
pangu8.com/jailbreak/ch

Demystifying the Secure Enclave Processor 建议多次阅读哦
blackhat.com/docs/us-16

SEPROM binaries for A7/8/9/10
securerom.fun

Apple Platform Security Guide
macobserver.com/news/20

感悟和思考:

非常有意思的talk,让人切实感受到了工业界中安全专家们target的方向;由于自己是了解一些像TrustZone这样的硬件保护设计的,但是苹果锁利用的双处理器SEP架构对我而言是陌生且性感的。如果真如徐昊大神所说,安卓和电脑端都逐渐在往这样的安全模型上迁移的话,此架构对于学术领域而言也将成为一大热点!

发布于 07-27

文章被以下专栏收录