何淇丹（Flanker），我们一般叫他冠军。有BAT 3家公司的工作经历，目前负责一个知名美股上市公司整体安全。现在他还没满26岁，这个发展速度远超同龄人，而他的故事远没有结束...
近期，我们邀请资深安全专家在“金融业企业安全建设实践”微信群，进行在线直播分享。本期，我们邀请到的嘉宾是何淇丹（Flanker）来给大家分享高阶漏洞攻防演进和现实威胁。如需查阅更多嘉宾分享，请关注本公众号。
【活动预告】漏洞之王：漫谈高阶漏洞攻防演进和现实威胁
【分享嘉宾】何淇丹（Flanker）
【嘉宾简介】毕业于浙江大学少年班和香港科技大学，蓝莲花战队早期核心成员，前腾讯科恩实验室高级研究员，资深安全专家，现任某美股上市公司安全总监。专注于安全攻防研究和大规模应用、系统安全防御体系研究建设。曾获Pwn2Own Mobile和PC双料冠军、BlackHat Pwnie Award最佳客户端漏洞提名、Master of Pwn称号，Google Android Security Top Researcher称号。多次在BlackHat & DEFCON & CanSecWest & RECon & PoC & QCON等发表演讲。
【活动时间】11月15日周五晚上20:00-21:00，60分钟
【活动形式】嘉宾通过文字形式，在“金融业企业安全建设实践”微信群内就“漏洞之王：漫谈高阶漏洞攻防演进和现实威胁”话题直播分享（约四十钟），之后是互动提问和回答，约二十分钟
请大家安排好时间，准备好问题，积极参与。
以下是实录：
大家好，我是Flanker。很荣幸受君哥邀请，来为大家分享一些从底层攻击的角度回头看防御的想法
漏洞之王：漫谈高阶端漏洞攻防演进和现实威胁
为什么取这个标题？在这里解释一下：
传统的端点入侵方式依赖于钓鱼网站或文档、可执行文件、CHM等作为载体，欺骗没有防御意识的目标主动下载和执行，或泄露自己的认证凭据。针对警惕性高的目标或成熟组织，这套方法存在很大的局限性。
高阶端漏洞通过多个无交互漏洞链组合，目标可能在完全无感的情况下设备即被控制，造成机密数据泄露或成为进一步渗透的跳板。
Flanker
故称之为漏洞之王
在每年的Pwn2Own大赛中，研究者都会针对最新设备演示此类攻击，并和ZDI合作及时将发现的这些0day报告给厂商，像Google Bug Bounty Program最高可为一套完整的利用链支付20万美元，而国内这两年组织举办了对标Pwn2Own的天府杯大赛，奖金更甚于Pwn2Own。而在漏洞军火市场中，这些漏洞则可能会以0day的身份成为军火库的一部分，价值更是水涨船高。
根据 what - how -why 原则，我们现在来展开：
1、What - See what your enemy can do
NSOGroup就是其中的佼佼者，其销售的取证工具包Pegasus号称远程情况下，无需点击/一次点击（目标打开邮件、链接或接收消息）即可获取目标手机最高权限，每套售价1000万-5000万美元，对外销售要先取得以色列军火出口许可。
庞大严密的商业化精密机器，将天才精妙的漏洞挖掘、漏洞利用转换为如导弹般高度工业化的精确武器。
Flanker
我们先看下wikileaks披露的2013年pegasus的产品说明书，看下他们2013年做到了什么样的水平。
在此给大家几分钟来阅读下这两张图片：
Peagus可以帮助操作人员在只知道对方手机号或者邮件地址的情况下，通过直接推送攻击消息触发漏洞，或者推送攻击链接，目标打开后触发漏洞，从而获得其移动设备的所有权限，持续性读取检测短信、相册、位置、浏览记录等等，实现全自动化远程攻击和监控。
看起来非常的神奇，那么这种攻击是如何实现的？
2、How - how do they do it?
任何人类编写的软件都会有漏洞，具体到移动设备上，以下的远程入口都是可以攻击的：
Browser
SMS/MMS/iMessage
IM(WhatsApp, Facetime, Wechat，Facebook等)
Wifi
Baseband
以被研究最多的浏览器为例，现代网页日趋复杂，又对性能有着很高的要求，灵活的JS和HTML相关最终都会落到本地代码（C++）来进行解析渲染，这自然导致了各种内存破坏漏洞的层出不穷。目前最流行的浏览器引擎， Google V8 + Blink的代码库绝大部分由C++编写，checkout之后源代码库高达数G，
即使强如Google，超过25000台机器组成的clusterfuzz集群24/7进行fuzz测试，也无法完全杜绝漏洞的发生。
Flanker
例如CVE-2016-5198: V8为了加快JS引擎的执行速度，会将JS中的热点区域通过编译器优化和预测技术预先翻译成本地机器码，同时根据预测的信息略去必要的边界检查以提升效率。但如果发现函数不满足预测，则会回退到解释模式重新翻译。其中的一个模式是谁修改了对象，谁负责标记通知其他使用函数进行优化。
而这个漏洞就在于一个悖论，如果修改对象的函数本身也被JIT了会怎么样？在上述这种情况下，v8的JIT引擎出现了属性访问的混淆。在复杂的内存布局之后，我们将其转换为一个越界漏洞，修改了一个js arraybuffer的长度，实现全地址读写和shellcode执行，进而获得了浏览器渲染进程内的任意代码执行，最终需要的内存布局如下图所示。这也是我们在Mobile Pwn2Own 2016中攻破Nexus所使用的三个漏洞之一。
但这个故事到这里远没有结束。在早些年浏览器的问题频繁出现后，各大厂商很快开始追寻一个守则：
let"s confine software, so even it"s compromised it only hasrestricted access to the system，即最小权限最大分割原则.
在消灭漏洞之外，通过不同层次的沙箱限制漏洞被利用后所能获得的权限。Google采取的是多进程分立，通过IPC、代理机制，将复杂的代码限制在严格的沙箱中，沙箱内只能访问很有限的外部服务、内核调用，无法获取到任何信息，甚至连动态库都不能加载等等。
Chrome采取的沙盒架构如下图所示：
safari则如下：
攻击者必须找到一个或多个额外的漏洞来实现沙箱逃逸，例如攻击broker、攻击有限的内核系统调用、系统服务等。
在macOS/iOS上，在攻破了Safari renderer之后，攻击者需要进一步审计和fuzz Safari沙箱内可以调用到的内核入口（驱动服务，MIG调用，privileged servers等）。Android生态则更为复杂些：对于标准设备（例如Pixel，Nexus等），攻击者需要寻找Chrome sandbox中能够触及到的组件（例如binder服务、Chrome broker、内核漏洞等）。而对于非标准设备而言，由于其他厂商对设备安全的掌控能力没有Google那么强，通常会给攻击者带来意外的惊喜。
除了沙箱之外，现代操作系统和编译器上在初代的ASLR DEP stack cookie等防御上，又不断增加了SMEP/SMAP、PXN、CFG、CFI甚至于最近ARM 8.3引入的Pointer Authentication等。这也对漏洞的品相和利用提出了挑战，导致漏洞发现和利用的难度和价格水涨船高。
2016年Pwn2Own我们使用的CVE-2016-1815，通过fuzz我们发现macOS/iOS显卡驱动在处理特定的矩阵转换会出现4字节的写IEEE754浮点数的错位，为了绕过kASLR、SMEP/SMAP的防御，我们最终把内存布局成了下面这个样子：
在2017年Mobile Pwn2Own上，我们在Samsung Galaxy S8上综合了7个漏洞，分别攻破了V8引擎、Samsung Internet Browser沙箱、Android沙箱，达到最终控制目标手机的结果。
回到实际的场景中，2016年被披露的NSOGroup Trident攻击链利用了CVE-2016-4655，4656，4657，包括一个safari漏洞、一个内核信息泄漏漏洞和一个内核内存破坏漏洞。
在今年Google TAGworking with Google Project Zero的报告中，同样披露了一套在野的完整iPhone 0day exploit，组成也基本相同。例如其使用的内核漏洞是CVE-2019-6225（同时由三个独立方发现），task_swap_mach_voucher处理不当导致ipc_voucher出现UAF，最终fake出task for pid 0，获得内核任意地址读写。Project Zero同样发现了NSOGroup使用的CVE-2019-2215，Android Binder驱动中的UAF可用于沙箱逃逸并直接获取内核权限。
在浏览器之外，其他富功能特性，例如Facetime、iMessage、Whatsapp等最近也成为了被关注的重点。这些漏洞利用通常不再需要绕过复杂的沙箱，而且可能更为隐蔽。例如，NSOGroup曾经利用过Whatsapp的RTCP（音视频流）功能的堆溢出漏洞，而Project Zero和盘古在今年陆续披露了针对Facetime和iMessage的漏洞利用。这类问题的触发甚至不需要用户交互。
3、Why - 为什么这类0day无法被彻底消灭？
现代软件操作系统和应用是一个复杂的体系，这些问题的根源最终都追溯到冯诺伊曼体系中数据即代码，代码即数据的设计原罪上。新的漏洞和利用方式推进着厂商实现新的架构演进和业界引入新的mitigation，新的防御又会促生新的攻击和利用方式，整体来说攻击难度是越来越高的。
在体系化安全方面，Google明显胜于Apple一筹，例如Chrome的设计经过不断的重构，其沙箱体系已经被公认为最难攻破的浏览器设计，攻击面缩减到了极致。而Apple的Safari至今没能实现分离render和kernel graphics driver。但Android受生态链拖累，各个vendor的分支通常不能及时合入上游补丁，反而成为了短板。此外Apple在硬件上下了很多功夫，某种程度上推进硬件mitigation反而更快。
”Project Zero’s mission is to make 0day hard”。
Flanker
4、相信也是很多人最关注的，回到防御方的角度：
企业应该如何保护自己的高管、关键人员和设备免受此类攻击的威胁？
一个较为悲观的事实是，虽然在PC平台上EPP、AV、EDR等重兵把守，在移动设备上我们尚没有很好的方式去做到实时监测。但还是有可以做的：
MDM方案可以在enterprise级别统一禁用部分功能和应用来有效缩小攻击面。由于攻击者可以获取到内核权限，传统的类似于Mo****iron的解决方案并不能很好地保护机密数据。
TEE技术的定制化发展，将数据保护从normalworld拔高到secure world，可以提高攻击者的攻击门槛（当然，TEE也有可能有漏洞）。
受限于移动端的检测能力，严格的网络隔离和后置barrier同样是必须的。
此外，基于stock Pixel定制的移动设备可以针对性地对弱点组件实施加固，例如在开源社区一直在推进hardened linux kernel的grsecurity (https://github.com/hardenedlinux/grsecurity-101-tutorials/blob/master/kernel_mitigation.md)，以及有独立商业产品的CopperHead OS。这方面的努力在于backport上游较为激进的mitigation，和削减不必要的特性减少攻击面。
当然，很多时候企业更大的问题在于补丁状态的维持上，非最新的设备会导致攻击难度大大降低（从0day下降到Nday），但造成的后果却一样严重。
总结：
以上为大家介绍了准军火化和军火化高阶漏洞利用链的组成和演进、其会带来的现实危害，以及可以防御的几个角度。
其实这次分享也是希望给大家拓宽下思路，防的角度能借鉴下已有的体系化演进经验，攻的角度蓝军可以有更多手段。像chrome的沙箱设计，就是非常好的软件工程安全体系范例。
我们跟国外最大的差距不是防御细节上，而是整个防御体系设计上，包括软件工程本身教育都缺乏基础的安全分立概念。其实需要大家的整个水位提升了，才有可能做top sec的东西出现，比如提高软件设计的防护水平。
这种意识也会反映到内部安全体系建设上，chrome的沙箱 zerotrust 其实都是一脉相承的。
Credits：
本文中内容感谢漏洞相关发现方和KeenLab的相关前同事们。
Reference:
https://googleprojectzero.blogspot.com/2019/01/voucherswap-exploiting-mig-reference.html
https://googleprojectzero.blogspot.com/2019/08/in-wild-ios-exploit-chain-1.html
https://www.blackhat.com/us-19/briefings/schedule/index.html#the-most-secure-browser-pwning-chrome-from--to--16274
https://www.blackhat.com/us-16/briefings/schedule/index.html#subverting-apple-graphics-practical-approaches-to-remotely-gaining-root-3388
https://cansecwest.com/slides/2017/CSW2017_QidanHe-GengmingLiu_Pwning_Nexus_of_Every_Pixel.pdf
http://blogs.360.cn/post/IPC%20Voucher%20UaF%20Remote%20Jailbreak%20Stage%202.html#0x27faketfp0
https://bugs.chromium.org/p/project-zero/issues/detail?id=1942
https://www.blackhat.com/us-19/briefings/schedule/index.html#towards-discovering-remote-code-execution-vulnerabilities-in-apple-facetime-15436
https://www.blackhat.com/us-19/briefings/schedule/index.html#attacking-iphone-xs-max-14444
解答环节
1、说到补丁状态的维持，是否有比较好的监控方式？
如果是Apple Volume Purchase统一采购的，这个可以依托MDM。
Android的问题在于分支厂商太多，本身各个厂商的补丁状态就不太一致，Google现在其实就在推进绕过vendor直接下发补丁。
2、mo****iron所代表的MDM不行，可以说国内所有所谓的零信任方案(实质是MDM沙箱)或EMM都无法解这个问题，这个理解对吗？TEE是指？
因为攻击者完成沙箱逃逸获得内核权限后，所有用户态的防御都是无效的了。
TEE是Trustzone，相当于独立于OS的更高级别world。
3、有个问题想请教一下：对于手机厂商的浏览器来说，使用的是chromium内核，官方的漏洞很多更新也比较快。跟随内核版本升级现实难度太大，只能跟随打补丁，而补丁又很难做到全覆盖，有一些是cve，而有一些又是bugid。有啥建议吗？
这个其实之前chromium的commit会附带testcase的，一般结合asan做一个半自动化的exploitability analysis，可利用度高的需要优先修复。
4、请教大神一个问题，现在单纯针对单一企业进行复合0day利用攻击的案例多吗？因为也是想搞清楚，单纯一般的企业，做好打补丁工作以外，针对0day的纵深防御还需要投入多少 ？
peagus一套卖几百万到上千万，我相信还是有企业值这个价钱的，只是我们不知道而已。
5、请教一下，针对此类攻击行为，有无可能在仅有数据侧发现，也就是省级，市级出口骨干路由上发现，而无终端参与。如可能，实现难度有多大？
这个其实最大的问题在于https，和如何构建一个足够大的对应移动端虚拟化的沙箱集群。exploit在行为上还是会有特征的。
6、对于核心高管，日常的电话、短信、微信聊天，价值就足够大了。而移动端攻击, 往往针对的是高价值个人，感觉没法防护啊。有没有好的能适合大多数企业的防护建议?
如果纯终端的话，其实copperhead os那条路是可能可以走得通的，定制设备。
7、问下flanker，你是怎么走上这条路的？
这个要感谢之前 Keen的老同事们，在合适的时间点遇到了合适的人们，加上自身的兴趣。
8、问下flanker，从专注技术挖漏洞的技术型人员转向企业整体的安全负责人，认为其中的困难有哪些？有什么体会？需要注意什么？
这个整体确实感慨还是蛮多的，不过这个问题比较specific，可以私下交流。
9、现在看到的很多apt报告还是基于pc侧的比较多，攻击移动端开展apt的案例多吗？如果不多，是被什么局限住了？
其实还是感知能力上。
10、请教问题：大神分享之后感觉没什么安全了。那你在安全负责人的角度关注、提升自身企业安全的，安全要提高到什么高度？大多数企业的安全都是合规安全而已。
两位其实提的就又回到那个安全哲学的问题了。。。安全要投入多少价值，要看需要保护的东西有多少价值。
11、这类攻击是如何发现的？
之前国外披露的NSOGroup的案例一般都是国家级别攻击。目标在发现异常链接或消息后主动联系相关人士进行了分析，以及Google的Threat Analysis Group在流量中发现的。
12、请问NSOgroup商业化的做法和国内实验室的做法有什么区别呢？
区别很大，实验室一般是针对比赛的要求，比如最新版来适配一套exp，比如弹出计算器即可。NSOGroup是一套完整的工具包，包括探针，利用，持续获取信息，需要考虑现实中各种复杂的情况，在界面和功能上还需要适配执法人员的需求---易用。实验室要是做到这个程度，其实有风险的，也没必要。毕竟实验室只是技术研究，nso是要恰饭的。
国内其实也有nsogroup类似的，不过这个就不展开说了。
上次被Google TAG发现的就是……还引发了Apple和Google的口水仗，Apple指责Google制造恐慌，Google指责Apple遮遮掩掩。
最后，放一下TK的点评：
也就这样在这个方向上跟踪了很多年的人才能讲清楚。
TK
声明：本文来自君哥的体历，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
