记 MOSEC 2020 及上海一游 (2)

上一篇文章就五个正式议题简单做了介绍,贴了主讲人的links以及自己一些不成熟的思考;本篇文章会聊一聊会议过程中的 BaiJiu Conf 环节;另外,由于自己太懒,这个时候才写出来555,很多类似的文章都已经有啦,大家也可以看看
- evilpan.com/2020/07/25/
- freebuf.com/fevents/244
不过写的应该都没有我详细 :D

白酒会 (BaiJiu Con)

在会议的日程中间,专门划分了将近2个小时的时间给了一个叫 BaiJiu Con 的活动,并且由 Thomas Lee 进行主持 (盘古团队的合作人,新加坡安全公司COSEINC的创始人);到会后才了解到,这是白酒会的简称 ;规则就是该会时间内,任意想要分享的成员可以依靠喝一小杯白酒来换取计时5分钟的演讲时间,另外的细节有

  1. 邀请共饮:毕竟上台的人是作为“宾客”的身份进行分享 ,盘古的组织负责人以及环节主持人都会在演讲者举杯时同样喝下一杯白酒。如下图,主持人 thomas 已经在向观众炫耀自己手上的茅台酒了。
主持人Thomas Lee以及他的“快乐”白酒

2. 当然,一个talk基本上5分钟是无法讲完的,这也意味着台上的嘉宾可能需要中途喝掉多杯白酒,而陪酒的主持人以及负责人也需要为所有的嘉宾陪酒(真的不会喝吐么,好在报名的嘉宾只有7名,如下)

白酒会参与者留名

正式的五个议题是不对外进行开放的,会场也被要求禁止拍照录音,所以上一篇博文只能框架性的描述并且少一点图片;而白酒会的氛围相对轻松很多,嘉宾5lipper也专门在斗鱼上开了直播,故此文我尽可能引入更多的细节,搭配直播一起食用会更加美味哦

5lipper_MOSEC 20 BaijiuCON 2_斗鱼视频v.douyu.com

1. Apple's Secure Enclave Processor

主讲嘉宾:王宇,考虑到上一篇介绍过了这里就不再赘述了

好巧不巧,白酒会的第一个分享恰恰好与正式议题的最后一个分享呼应了起来——均是关于Apple的SEP的安全问题;就嘉宾王宇自己的评价来说,徐昊老师的分享相对更实战一些(许多细节上的知识点)而自己的分享会显得学术一些(嗯,就是更难听懂的含义)

可惜的是,这一个分享的直播好像没有录全,故我就多补充一些当时候拍的照片来和大家叨叨好了
  • 关于SEP的一些链接分享;王宇老师说主要是专利描述,应该会写的很细节很规范
  • Blackhat的一篇非常有名的分享,王宇老师和徐昊老师都评价其是仅有的参考资料;基本都读了五遍以上(感兴趣的赶紧读起来,文章链接可以戳这里,视频链接可以戳这里
  • 下面的代码段是Blackhat分享里面主讲团队逆向得到的结果
  • 这里截图了部分2018年Apple泄露的启动代码,王宇老师发现这代码中的 sep_message 长得完完全全和逆向出来的一模一样(嗅到了一点阴谋的味道
  • 值得一提的是王宇老师讲的笑话:“如果是我去逆向,那逆出来一定都是一堆unknown了”,奉为经典
  • 接着王老师提到了他最近逛twitter时候的发现,安全研究者luca利用之前徐老师议题中提到的“write yourself a SEP app”的方式给SEP中写了一个ssh接口并可以连接上去;作为小白确实不理解这种方式的呈现所表达的利用程度 是不是一种任意代码执行的表述呢?
  • 那么SEP为啥会吸引安全研究者的眼球呢?自然是因为跑在SEP中的程序以及数据了;继续延伸这一篇Blackhat文章可知Apple中无论是KeyStore即密码管理以及Credential即证书管理都有部分核心内容迁移到了SEP中进行运行
  • 这里是王宇老师用自己的写的hook框架去打印出来的AP与SEP之间交互的一些信息,下面这一页在我的理解下也是差不多,通过打印出keystore交互的信息进一步帮助逆向工作
  • 注:这里开始已经也可以从斗鱼直播那里听主播来讲细节了
  • 后面几页连续内容都是阐述王宇老师逆向的心血,首先他找到一份泄露出来的固件程序 (n51 RELEASE版本,可惜没搜到下载的具体位置)这一段老师讲的还是蛮清除的,一定要听听
  • 王宇老师这里表述:“sks一定是我最关心的最大的攻击面”(这里sks意指secure keystore);上图就是通过user application申请打挂掉SEP的sks的一个panic信息截图,属于工作中发现的zero-day vulnerability
  • 更让人钦佩的是王宇老师对上个零日漏洞的评价只是“其他研究Keystore安全的人也能找到这样的0-day”;这一页ppt介绍了他发现的新的攻击面——利用苹果touch bar固件存在的漏洞打挂掉最新的MacOS Big Sur版本


2. Arch-flip

考虑到接下来的议题斗鱼上都有,这里就不逐页分析PPT了,而是选择摘一点点关键的页面并概括性的总结一下好啦

主讲嘉宾:王勇,阿里安全团队研究员;曾获得2019最佳提权奖项 (Pwnie Award 2019 - Best Privilege Escalation)

内容概述:

主讲人王勇就 Arch-flip 技术进行了介绍,拓展描述了相关的应用以及局限性;

什么是 arch-flip: Make the process interworking between AARCH32 and AARCH64;

稍微了解arm机器的读者大概知道,arm可以在运行时通过跳转来完成arm指令集与Thumb指令集之间的切换(换句话说,32位指令集与16位指令集之间切换)那么,你是否想过64位与32位之前切换呢?对于AARCH64而言,这是不被允许的,官方文档里说明了只有在异常级别切换时候才可以做执行状态切换(比如说系统调用进入内核,然后返回等),而不能简单的保持运行状态下实现

实际上,x64应该是可以实现的,因为其决定的关键就在汇编可以改变的段寄存器上;

在主讲人的描述下,我们清楚了如下要点

  1. 对于操作系统内核而言,某个运行的 task 是以64位指令集运行还是32位指令集运行是由 thread_info 中的 flags 成员的标志位来指定的;(TIF_32BIT宏标志置位表示以兼容32指令集模式运行)
  2. 对于硬件实现而言,真正的状态由 PSTATE 状态寄存器中的 nRW 比特位决定;相关细节可以阅读 ARM手册 中的 Execution state 章节

玩过操作系统的读者可能知道,在进程进行调度切换后,当前进程的状态信息会存入内核栈中的 pt_regs 结构体之中,然后被挂起。王勇师傅提出可以再重新调度该进程前想办法修改结构体中存储的 flags 字段以实现 Arch-flip的切换;

对于实现有以下的具体方案

  • 通过内核层漏洞;当获取了任意写原语后,改改内核栈自然不在话下
  • 通过内核层信号的函数回调来完成(暂未理解,搜索到一些用户态使用signal注册响应回调的博客,并未确定其中联系
  • 利用ptrace,调试和修改子进程PSTATE信息(也只是简单说了下,可能实操才理解吧

好吧,那么利用 arch-flip 可以有什么样的应用呢?

  1. Anti-Reverse:这个的hacking意味很强,可能是自己写的一个Aarch64的内核或者patch过的内核实现了arch-flip的支持,这样的话一个普通的程序可以通过系统调用的接口在逆向者完全不知情的情况下完成运行状态切换;因为现有的逆向工具,包括IDA也会被这种指令集切换的方式迷惑到
  2. SAMSUNG RKP保护机制绕过:这个比较模式,大概是一种基于TrustZone的保护机制;由于三星实现中只在64位的 execve 系统调用下做了 RKP 保护,所以通过 arch-flip 的切换就可以绕过这道防御
    (这里嘉宾说他2016年就已经完成了绕过?但确实没有搜到啥arch-flip的资料)
  3. Chrome沙箱逃逸:在最近的更新之前,Chrome的沙箱基本运行在32位的模式下,也导致一些exploit思路无法有效利用;比如沙箱中32位长的寄存器就没法有效去写64位内核下的ADDR_LIMIT字段。王勇师傅最后以binder漏洞复现,依靠Arch-flip破坏ADDR_LIMIT,从而完成基于pipe的内核层任意读写提权的demo作为了结尾


思考感悟:

可能是对于架构本身摸的不透彻吧,毕竟在x64位下其实遇到过相关的CTF题目依靠运行状态切换去实现ROP的;而Arch-flip技术是针对ARM的,而ARM在用户态没有提供响应的支持。所以啊,在研究过程中考虑架构之间的异同还是很重要的。


3. User-Mode Callback is Back

主讲嘉宾:Rancho 前腾讯安全湛泸实验室成员,现任职于华为终端

内容概述:

Rancho声称自己只是上来喝白酒的嘻嘻

因为是windows内核相关的知识,只能听个一知半解了。整体而言是这样一个故事:

windows 2000以后的打印机驱动包括如下组件

  1. 打印机图像DLL,如下图中的Printer Graphics DLL
  2. 打印机接口DLL,如下图的GDI Engine

整个配合的过程,存在很明显的问题

打印图像DLL和GDI渲染的协同工作

关键就是位于ring-0的打印机的GDI渲染驱动居然回调了位于ring-3的Printer打印的DLL (考虑到接口的协同才这样设计的),这是非常危险的,恶意的DLL所具有极大的攻击面

实际上windows机器中的用户态回调攻击是个很老的问题了,这里 rancho 分析出来能够遗留到至今也如下的原因有这样几点

  • 间接调用,并不容易通过交叉引用去发现这些函数
  • 函数命名,这几个相关的用户回调的前缀不满足之前研究者发现的规则
  • 非默认,在正常情况下这样的目标未被初始化,所以函数只会留空


思考感悟:

好吧,这个用户态回调攻击的出现比我使用计算机的时候还早。。果然阅读老的漏洞是很有必要的,一不小心就可以老树开新花了。

提醒一下,王宇老师在结束后对于user mode callback问题有一段总结,不要错过


4. 供应链攻击行为艺术大赏

主讲嘉宾:redrain 盘古安全团队成员

内容概述:

这应该是整个白酒会中最平易近人的一个议题了,主讲人花一小时糊出来的ppt,整个分享以趣事为主;强烈建议读者把直播看一遍~;总结的话我还真没有啥好说的,可能就喝白酒不要勉强吧 :P

思考感悟:

分享中提及的投毒,以及编译器自举的工程意味非常浓,不清楚学术界有没有相关工作,可能会花一些时间探索探索。


5. Security Research on Mercedes-Benz

主讲嘉宾:严敏睿,360 SkyGo-team成员,专攻汽车安全

内容概述:

非常硬核的分享,360针对奔驰车的安全在去开会的前一天刚刚好老师有一个分享,所以看到这个议题的时候觉得很亲切;

https://media.daimler.com/marsMediaSite/en/instance/ko/Mercedes-Benz-and-360-Group-to-join-forces-Mercedes-Benz-and-360-Group-with-its-Cyber-Security-Brain-work-together-to-strengthen-car-IT-security-for-industry.xhtml?oid=45208829media.daimler.com

当然,这一块的专业门槛有点高,在这里我只能描述性的做一下总结

车安全攻击面
  • 车安全的攻击面是很广阔的:如Wi-Fi、蓝牙、蜂窝网络等各式各样的传感器;Sky-go团队主要针对联网问题进行研究
  • 攻击影响整个国内的梅赛德斯系列,超过两百万台
  • 国内车的联网模块基本是HERMES的,方案曾从高通切换到了海思(HERMES基本把调试关闭了,主讲团队是通过吹芯片dump flash等方式还原文件实现的);并应用华为的通信模组
  • 两条可选的攻击路线(主讲团队利用的后一种):
    攻击云平台,奔驰的云在国内并不走专用网而是暴露在公网上,通过双向证书认证;这里是可以测试的点
    攻击车上系统,实际上手机控制车的流程是先联系后端服务器,然后服务器指令下到车上的联网模块,进一步转发到车载网络之中。实现方法可以通过修改文件系统,加载恶意程序从而root这个车终端的操作系统,进一步发送恶意指令。
  • 通过拿掉物联网设备的esim卡其实可以实现假身份上网!
  • 该团队的研究中发现其内网的安全防护程度很低,缺少验证;在已有root系统情况下可以很轻松的发送恶意指令
  • 该团队通过如图所示的攻击链,挖掘了共19个高危漏洞 (其中有关非后端的硬件漏洞可能需要多年才能修复

思考感悟:

一些不太好研究的系统更具有研究的价值,仔细一想,车安全似乎无法在高校的研究中轻松展开吧?这种程度的研究给人一种望尘莫及的赶紧 (pwn掉一辆车确实和pwn掉一部手机或者laptop不是一个级别的感受


6. IOS in 2020

主讲嘉宾:陈良,腾讯科恩实验室(前身为Keen Team)创始人成员之一,Thomas指定喝酒对象

内容概述:

陈良老师主要针对IOS系统于2020年的一些改进进行了总结,对于IOS系统没有太多了解,这里也就照搬一些要点了

可惜陈老师酒量不行也没睡好,其实展开好像可以讲很多很多
  • zone_require加强
    在iOS 13.6后,通过限制指针一定位于 ipc_port 的 zone 中来抵抗由Ian Beer在CVE-2018-4241中提出的fake port攻击,并进一步限制指针指向其他可利用的位置如共享内存等。
  • isolate kalloc zone机制
    iOS 14后为kalloc提供了不同的zone,动态数据的元数据、实际数据与内核中的一些拓展数据会分离存储,导致UAF变得相对困难
  • Data PAC指针验证
    于最新的iOS 14 beta中引入了Data PAC来保护一些关键的指针,如task中的一些字段,以及端口指针等
因为这里线上出现了luca,导致演讲被中断;陈良老师这里评论iOS 14的PAC针对vptr的保护实际上没有太大的作用的解释没有很清楚——大概是因为iOS实现的PAC的context强度不够,导致攻击者泄露指针后仍可以伪造

分享最后,老师分享了针对最新beta的完美越狱(昨天发布的版本今天就有成功的工具了,打穿了像Data PAC之类的保护


思考感悟:

同正式议题中IOS Wi-Fi升级相关的安全研究,现有的系统升级总是可能带来新的安全问题和热点;作为一个入门者,还是得加油达到可以具备去分析最新版本特性以及潜在风险的水平呀


7. Chromium Series in TCTF

主讲嘉宾:刘耕铭,腾讯科恩安全研究员,国内著名CTF联合战队A*0*E队长以及EEE战队队长,曾是浙江大学AAA战队队长 (老队长 !),在各类大型安全比赛中都取得过不凡成绩

内容概述:

老队长主要是做pwn的,现在的精力以Chrome及v8为主,此次分享以他TCTF出题过程前发现的0-day漏洞、出题过程时两道变三道的体验等;

考虑到自己不是做浏览器的,这边来总结老队长针对 PartitionAlloc free链实现的任意地址分配、借助metadata page泄露出全局区地址等感觉只会扯不清楚;如果读者感兴趣还是可以听听他的演讲(声音很好听的),并去搜索了解一下他提到的一些攻击方式,如覆盖 partitionalloc 的hook函数等,这些攻击的思路对于有一定程度的pwn选手都应该可以get到的。

针对Full chain题目的解答这里给出了总结:

TCTF Chrome Full chain solutions summary

其中老队长的预期解答首先实现了一个任意地址读写,利用传统利用链 (修改mojo_js的flag,刷新网页启动后利用mojo_js做IPC攻击;而另外一个思路如图,可以修改全局区的一个flag (is_mojo_js_enabled_) 值来完成对mojo_js的启动

注意第三步是通过覆盖 base::PartitionAllocHooks::free_override_hook_ 成空函数来防止回收写坏对象时候造成崩溃

而还有一个队伍的解法利用了最近提出的一个在野漏洞,给出相关链接如下

https://blog.perfect.blue/Chromium-Fullchainblog.perfect.blue


然后放一个老队长的博客链接 以及朋友圈

https://dmxcsnsbh.github.iodmxcsnsbh.github.io

思考感悟:

还是以膜拜为主吧,什么时候可以就一个领域进行CTF出题,并且在出题的过程中进一步发现新的漏洞,这才是到达了对这个领域了解的新境界了把。


闲谈

地铁34号线的故事,唉,这一次去上海找同学顺便吃饭,回程的时候再次“挂”在了3、4号线上。。不知道这种一条线上跑几个车的设计是怎么被提出来的 外加坐地铁的时候听组会,导致我直接坐3号线到了上海南站才发现出事了 ,想返程的时候却因为超过十点半所以坐不了4号线了

希望下一次别再犯同样错误了

编辑于 07-31

文章被以下专栏收录