发现看议题材料也不容易啊,有些议题挺有技术深度的,而且内容还特长,长就算了,有些ppt其实只讲了不到一半的内容,另一半都得靠作者演讲才能知道,剩下的只能靠自己脑补或搜索资料了,我只能说真的费脑费时间。
议题名:hAFL1: Our Journey of Fuzzing Hyper-V and Discovering a 0-Day
开源工具:https://github.com/SB-GC-Labs/hAFL1
ppt都是图,没啥文字说明,也没有paper,所以只能算看个大概,后来找他们官网博客看了下。
专门去翻了下最新的Hyper-V漏洞奖金,非常可观,难怪最近那么多人盯着Hyper-V去挖洞,这次BlackHat就有2个Hyper-V相关议题,一个个都是上百页ppt,看得真有点费脑。
先来看下Hyper-V的内部架构和通信原理,主机运行在Root Partition,客机运行在Child Partition,为了向Child Partition提供硬件设备接口,Hyper-V提供了半虚拟化设备的扩展使用,主机与客机都可以修改硬件接口,主要是出于性能考虑。作者正是盯上半虚拟化设备vmswitch。每个半虚拟化设备由两部分组成:虚拟服务消费者VSC(netvsc.sys)与虚拟设备提供者VSP(vmswitch.sys),两者基于hypercalls通过VMBus进行内部通讯,VMBus提供收发主客机之间通信数据的收发缓冲区。
编写harness的方法,作者参考MSRC之前分享的文章“Fuzzing para-virtualized devices in Hyper-V”:https://msrc-blog.microsoft.com/2019/01/28/fuzzing-para-virtualized-devices-in-hyper-v/,最后找到vmswitch是使用VmbPacketAllocate和VmbPacketSend通过VMBus Channel(该指针可通过ndis.sys去查找)发送数据,然后编写个harness.sys在客机上运行用于fuzzing。
每个VSP都需要注册回调函数EvtVmbChannelProcessPacket去处理包数据,对应vmswitch回调函数VmsVmNickPvtKmclProcessPacket。vmswitch使用NVSP类型的数据包,它是通过VMBus传输的数据包专有格式。NVSP包类型有多种,有的负责设置VMBus收发缓冲区,有的执行VSP与VSC握手,有的用于发送主客机间的RNDIS消息。作者此次正是Fuzzing RNDIS消息的处理代码,不过作者没有公开hareness源码。
最后重点看下hAFL1的实现吧,hAFL1是基于kAFL开发的,名称中的1是指虚拟化等级,代表Hyper-V Host,由于对方是的Linux上运行,所以实际上此处Hyper-V Host是Linux主机上开启Hyper-V的Windows 10虚拟机,虚拟机里面的Hyper-V虚拟机才是L2(看作者也开源了hAFL2应该就是针对L2的Fuzzer)。
在创建hAFL1过程也遇到不少问题,作者整理了个列表,就不展开细说了:
然后结合libprotobuf-mutator支持protobuffer fuzzing,用于Fuzzing Hyper-V vmswitch半虚拟化设备,挖到vmswitch.sys上的一个驱动漏洞,可用于实现虚拟机逃逸。后面有空可以拿来试用下hAFL1,读读源码学习下。
议题名:Crashing Your Way to Medium-IL: Exploiting the PDB Parser for Privilege Escalation
以前就曾关注过PDB解析器(Dbghelp.dll)这个攻击面,但后来发现有人报漏洞给微软被忽略了,因为缺少实际攻击场景。没想到被来自"平底锅"的哥们"曲线救国"式的找到提权攻击场景了,利用程序崩溃会启动WerFault.exe,而它会使用Dbghelp.dll去解析pdb文件,关键是崩溃程序处于Low Integrity时,仍可启动Medium Integrity的WerFault.exe。所以,整个漏洞挖掘与利用的过程如下:
最后作者演示了IE沙盒逃逸的利用场景。
微软对此的修复方案也很暴力,直接禁止WerFault.exe解析pdb文件,连Dbghelp.dll上的解析漏洞都懒得修了。
议题名:Another Road Leads to the Host: From a Message to VM Escape on Nvidia vGPU
来自Tencent Blade Team的议题,通过上图可以知道主客机消息交互的流程,重点就在nvidia-vgpu-mgr上面,它加载libnvidia-vgpu.so来处理RPC消息:
nvidia.ko(guest) => nvidia-vgpu-vfio => nvidia-vgpu-mgr(root, libnvidia-vgpu.so) => nvidia.ko(host)
主客机的vGPU通讯通过VRPC消息交互,所以它是个fuzzing测试点,看fuzzer代码片段应该是借助libfuzzer写的,构造符合一定数据校验要求的RPC消息再进行变异测试,调用的API是通过逆向获取的,还有其参数构造。在 libnvidia-vgpu.so上面跑出一个nday,在新版中修复了,另外搞到几个nvidia-vgpu-mgr漏洞。最后利用ROP+信息泄露的组合完成利用,逃逸出虚拟机获得主机root权限。据说打算在github开源fuzzer,有兴趣的可以关注下https://github.com/tencentbladeteam。
议题名:Mobius Band: Explore Hyper-V Attack Interface through Vulnerabilities Internals
关于Hyper-V的架构在前面刚好介绍过,但该议题讲得相对细一点。以Linux客机为例,拿Linux内核源码讲解主客机基于VMBus的通讯原理。然后以历史漏洞为例,介绍Hyper-V利用与传统提权漏洞的区别:基于VMBus通讯的限制,主机ring0不能直接读客机内存,不能直接操作对象分配释放,也没有直接的API提供。
最后介绍了几个Hyper-V漏洞细节,主要是一些调试截图,没有太多文字描述,看着有些零散,如果有paper会好理解一些,自己也没动手调试过,只能看个大概。
重点看下作者总结的Hyper-V攻击面:
议题名:Diving Into Spooler: Discovering LPE and RCE Vulnerabilities in Windows Printer
最初spooler漏洞被用于10年前的Stuxnet攻击,但最近该服务漏洞也被披露了不少漏洞,看下今年的微软公告就知道了。
应用程序可以通过RPC与Spoolsv.exe交互,Spoolsv.exe是System用户权限的,如果存在漏洞就可用于提权。主要介绍了一些spooler服务漏洞成因,以及微软的修复方法,又是被如何绕过补丁刷CVE的过程。然后介绍一些RCE漏洞的利用,包括"PrintNightmare"(首次披露是CVE-2021-675,后来补丁被绕过获得CVE-2021-34527)漏洞,利用漏洞都是为了加载dll以高权限执行,由于是RPC调用,所以也可以算是远程代码执行。关于这两个漏洞的分析,推荐直接看下网上的分析文章:https://paper.seebug.org/1635/,因为这ppt内容太简短了,可能现场听比较容易理解些。最后建议不需要打印服务的,可以直接关闭它。
这些漏洞比较偏逻辑类的,应该是人工挖的,一开始看标题以为是漏洞挖掘,看了才发现是漏洞分析与利用。