MOSEC-2020参会小记

昨天去参加了mosec2020的安全会议,这也是我第一次参加mosec,议题质量比预料中的要高,因此在这记录一下其中几个有意思的议题。

IO80211Family

第一个议题是王宇师傅(@keenjoy95)关于苹果WiFi子系统的安全研究分享,其实王宇在前一段时间就提了一大波苹果蓝牙子系统的漏洞,看来手里的料还是挺多的。之所以去撸WiFi子系统,也是因为“之前的一个0day在升级系统后不work了”,……说回思路方面,研究入口的寻找个人认为比较有启发性,利用Kemon的内核挂钩能力,确实可以做到往上拳打daemon process,往下脚踢kernel driver或firmware。

km
km

IO80211Family V1/V2的这些漏洞,也是因为在接口上发现有巨大的参数传入。一方面通过修改Kemon实现Passive Fuzzer,另一方面去逆向对于这些参数的处理和校验从而优化样本。效果怎么样呢?也就是“每天和panic打交道,对于一些品相不好的panic都懒得去分析”的地步吧。

另外,对于这些复杂的设备驱动,可以参考开源代码(AppleIntelWiFiMVM),甚至自己去实现一遍,这样可能在分析时会有不一样的理解。

像WiFi、蓝牙、NFC这些攻击面其实影响是很大的,而这部分驱动或者firmware的开发者由于自恃功能复杂天知地知或者抱着能用就行的心理,对一些不可信数据没有意识添加完善的边界检查,导致实现往往在遇到非预期输入时存在bug或者漏洞从而引起内存破坏。这部分分析一个绕不过的门槛是逆向的基本功,安全研究人员做好头发的保养工作还是很有必要的。

另外王宇也提到了他在macbook touchbar图像驱动中也是有0day的,感兴趣的同学也可以尝试去撞一下:)

DroidCorn: 无源码Android Binary Fuzzing

这个议题是flanker(@Flanker_017)介绍了他(们?)做的一个无源码fuzzing框架。说到无源码fuzz,常见的两个流派就是binary patch和dynamic instrument,而DroidCorn听名字也大概能猜到了,就是基于Unicorn开发的动态插桩式执行引擎。

该引擎架构大致分为以下部分:

  • Crash Triager
    • Trace Recorder
    • Symbolizer
  • Mini Runtime
    • ELF linker
    • Mini Heap
    • Mini Hooker
  • Mini Kernel
    • Memory Layer
    • Syscall Handler
  • Processor
    • Unicorn(patched)
    • ForkServer
    • Tracer

无源fuzz的思路和AFL-unicorn类似,在QEMU执行Translation Block的时候插入afl_maybe_log记录执行覆盖率。Unicorn本身只是QEMU中CPU Emulation部分代码提炼出来的可编程框架,要实现二进制程序的加载和运行还需要依赖于linker和内核的正确处理。DroidCorn中在这部分做了不少工作,实现自定义的ELF Linker、Runtime以及根据不同应用实现不同的内核系统调用(~20个),这让我想起了另一个类似的框架qiling.io。最后作为PoC,展示了三星手机图片库中找到的一些漏洞,不过工具想必近期是不会开源了,自己动手丰衣足食吧。

也许以后这类更偏向实战的无源fuzz会是一大热点。CPU指令的软件模拟运行的虽然可以做很多优化,但性能终究是比不上原生虚拟化的支持,ARM Server FTW?

深入浅出JSC优化措施

大宝(@S0rryMybad)的议题,讲得太深,而且又是我的知识盲区,所以不多介绍。唯一的收获是学会了面向RCE的“倒序挖洞法”,针对类型混淆去搜寻JS Array类型改变和检查的地方并寻找潜在的非预期状态。C/C++的代码审计和php有很大不同,但是现在网上更多的资料是关于后者,这个未来有时间也值得谈谈。

暗涌2020

slipper的议题,光听名字完全不知道说啥,副标题是小米5c中国产自研手机芯片澎湃S1分析,其实我觉得标题应该改成“小米5c: 年轻人的第一个fullchain” :)。

虽然标题说是芯片,不过和芯片本身没什么太大关系。议题本身还是很精彩的,从头到尾介绍了如何实现one-click获得小米5c的持久化root权限(准确来说可以达到S-EL1的权限)。

由于安卓的碎片化,小米ROM中其实还是Android7.1,所以在攻击链中有几部分使用了n-day,比如webview和sepolicy的问题。小米5c使用了OP-TEE作为TEE的实现,从其中某个TA里发现漏洞函数,通过在用户态发送消息可以触发。一般TA中都是没有现代mitigation的,所以直接栈溢出+ROP来返回内核并进行patch从而获取了root权限;最后则是通过分析firstboot(LK+aboot)发现特殊入口绕过SecureBoot从而实现持久化。

最近中美关系紧张,可能会出现更多的国产芯片。除了芯片本身的硬件实现外,软件设施也需要跟上时代。华为海思是个很好的例子,虽然其TEE(iTrustee,之前是Trusted Core)也曾经有过漏洞,但至少是和国际持平的。开源实现也不是不能用,不过开发者移植的时候最好先有个全面理解,这样也不至于把开源项目的测试接口原汁原味编译进release版本中,然后被安全研究员在大会上公开diss了:)

攻击SEP的安全启动

徐昊(@windknown)的压轴议题,这也是我觉得最有干货的一个议题了。在checkm8出来后,攻击者号称这是ROM的代码漏洞无法被修复,但是苹果计划在iOS14中修复这个问题,修复方法之一就是通过SEP。SEP是安全处理器(Secure Enclave Processor),与ARM提供的Truszone总线隔离不同,而是使用了一个独立的处理器来专门处理敏感信息。

关于SEP的公开信息并不多,曾经在2016年BlackHatUS中的议题“Demystifying the Secure Enclave Processor”介绍过,此后很长一段时间都没有相关的安全分析。SEP同样也是一个ARM处理器,拥有独立的RAM和外设,如加密引擎(GID/UID)和TRNG,但同时也有部分和应用处理器共用的资源,比如电源管理(PMGR)、Mailbox和共享内存。

Mailbox是SEP和AP之间唯一的通信信道,基于双方都能访问的映射IO寄存器实现。AP端的映射基地址是0x20da04000,SEP端映射的虚拟地址是0xcda00b80(物理地址为0x20da00b80)。Mailbox信息(messages)的大小是8字节,其中4字节为data,数据结构如下:

c

struct __attribute__((packed)) sep_message {
	unsigned __int8 endpoint;
	unsigned __int8 tag;
	unsigned __int8 opcode;
	unsigned __int8 param;
	unsigned int data;
}

sep
sep

这个议题本身更多关注与安全启动部分,作者逆向分析了SEP ROM中的代码,分析地址映射和地址保护初始化的逻辑,并寻找其中的攻击点,最终在部分型号下实现SEP的memory读写。可能由于作者还没有完全撸完,所以后面留了一手,不过总的来说也算给其他研究者提供了一个指引方向,后面应该会针对SEP有个小爆发。

Baijiu Con

会后的环节是白酒Con,想上台讲的喝一杯白酒讲五分钟,挺新颖的形式。其中也有一些有趣的议题,比如:

  • 王宇介绍了SEP研究的一些其他相关资料和最新进展
  • 王勇(ThomasKing2014)介绍了一种名为Arch-flip的奇淫技巧,在运行时切换ARM32/64位的运行环境,可用来辅助写chrome exp或者反逆向
  • Rancho介绍了Windows打印驱动的安全研究
  • redra1n介绍了供应链攻击,red on red,用魔法打败魔法(●—●)
  • 360的小哥介绍了奔驰汽车安全研究,进入汽车系统后发现一个越权远程控制任意奔驰的漏洞(还好买不起)
  • iOS in 2020: 秀了一把最新iOS 14的越狱,不说了,盘古NB
  • Chromium Series in TCTF: 分享CTF中遇到的Chromium的漏洞利用技巧

虽然会议视频和slides没有公开,但是CTF主播slipper在斗鱼直播间中直播了Baijiu Con部分的演讲,感兴趣的可以去看看,直播间号码是7851291