云攻防课程系列（六）：虚拟化安全攻防

近日，绿盟科技星云实验室与北京豪密科技有限公司联合推出了一项云攻防技术培训课程。该课程旨在根据客户需求，为客户提供专题培训，帮助客户熟悉常见的云安全架构，并提供云攻防技术理解，同时结合模拟攻击实验提升攻防能力。该课程参与学员涵盖了特殊行业的单位、国企等十多家单位。课程共分为六个章节，分别就云计算基础、云上攻击路径、云上资产发现与信息收集、云服务层攻防、云原生安全攻防以及虚拟化安全攻防进行了详细介绍。

本系列文章旨在以科普为目的面向各位读者推出。本文是该系列的第六篇，主题为虚拟化安全攻防，主要包括虚拟化安全风险和虚拟机逃逸技术两部分。

本部分主要参考自NIST.SP.800-125Ar1 [3]。

在一个Hypervisor平台中：

1. 虚拟机是不可信的，包括虚拟机操作系统和所有用户态应用程序。

2. Hypervisor平台中的设备驱动是不可信的，除非它们带有安全证书。

3. 提供虚拟机隔离的Hypervisor核心组件是可信的。

4. 对于II型Hypervisor来说，宿主机操作系统是可信的。

5. Hypervisor宿主的硬件是可信的。

然而，宿主机硬件其实并非完全可信。一些侧信道攻击可能会影响到共享的硬件资源，例如，Spectre和Meltdown两个CPU级别的漏洞[5]可能会导致敏感信息泄露。

从Hypervisor安全的角度去考虑时，上述模型定义无可厚非。然而，如果从全局视角来看，信任模型是相对的。更准确地说，信任模型应该建立在责任共担模型基础上。就云计算环境下的两大角色——云计算服务提供商（Cloud Service Provider，简称CSP）和用户来说，信任模型让两者对立，责任共担模型则让两者约定和协商。如此而言，责任共担模型的不同场景应该对应不同的信任模型。信任和安全，完全要看谁负责和对谁而言。宿主环境是否可信的问题和对此的需求也衍生出了可信计算、机密计算等技术。

Hypervisor的五个基础功能如下：

1. 虚拟机进程隔离（HY-BF1）：实现虚拟机调度，虚拟机内进程的CPU、内存管理，多处理器间上下文切换等功能；管理支持直接内存访问（DMA）的设备。

2. 设备调解和访问控制（HY-BF2）：管理虚拟机对设备的访问。

3. 虚拟机命令的直接执行（HY-BF3）：直接执行来自虚拟机的命令（适用于半虚拟化）。

4. 虚拟机生命周期管理（HY-BF4）：包括虚拟机镜像的创建和管理、虚拟机状态控制、虚拟机迁移和快照、虚拟机监视和策略实施等。

5. Hypervisor平台管理（HY-BF5）：包括资产定义、Hypervisor软件模块的配置项设置和模块更新等。

根据NIST.SP.800-125Ar1，Hypervisor的三个威胁来源如下：

1. 来自Hypervisor宿主机所在企业网络（HY-TS1）。

2. 来自恶意或被攻陷的虚拟机（HY-TS2）：威胁传播通道可能是共享的Hypervisor内存或Hypervisor建立的内部网络。

3. 来自虚拟机Web管理端和管理控制台（HY-TS3）。

其中，HY-TS1和HY-TS3在传统服务器环境中已经存在，HY-TS2是虚拟化环境独有的。

其实，上述威胁来源分析结果和以容器和Kubernetes为基础的云原生环境十分类似。然而，虽然HY-TS3在传统服务器环境中也存在，但是近年来虚拟机Web管理端多次曝出重大安全漏洞（如VMware VCenter的CVE-2021-21985 [1]和CVE-2021-21972 [2]），十分值得研究人员重视。

这里提到的三个潜在威胁，指的是来自恶意或被攻陷的虚拟机的威胁，它们分别是：

1. 进程隔离性的破坏——虚拟机逃逸（HYP-T1）：这是Hypervisor面临的主要威胁，也是虚拟化安全研究的重点和热点。其潜在原因有两个：

a. Hypervisor设计漏洞。

b. 恶意或脆弱的设备驱动。

2. 网络隔离性的破坏（HYP-T2）：如IP、MAC伪造、通信劫持等，通常针对虚拟机所在的虚拟化网络段。

3. 拒绝服务（HYP-T3）：错误配置的或恶意虚拟机可能会导致宿主机资源的大量消耗，导致其他虚拟机或宿主机拒绝服务。

前文我们提到，针对Hypervisor虚拟机进程隔离功能（HY-BF1）的主要威胁是进程隔离性的破坏（HYP-T1），原因之一是Hypervisor设计上可能存在的潜在漏洞。因此，本节列出的五个潜在设计漏洞均指的是可能导致HYP-T1威胁的漏洞。另外，这五处是推理分析的结果，并不是说一定有实际的漏洞存在（事实上，确实有不少相关的CVE漏洞存在）。

事实上，在NIST.SP.800-125Ar1中，前四个设计漏洞被列在“针对HY-BF1的潜在威胁”部分，第五个则被列在“针对HY-BF2的潜在威胁”部分。为了方便大家从整体上把握，我们把这五个设计漏洞单独提炼出来形成本节。这说明不同基础功能及威胁之间并非完全割裂，也是我们前面说五大基础功能之间的关系并非平坦简单的缘由。

1. 虚拟机控制结构VMCS（HY-DV1）：用来存储虚拟机状态的数据结构，VMCS的潜在问题可能会导致Hypervisor内存泄露。

2. 敏感指令处理（HY-DV2）：如果未能正确捕获、处理虚拟机发出的特权指令，它们就有可能被直接执行。

3. 内存管理单元MMU（HY-DV3）：Hypervisor的软件实现的MMU为虚拟机分配影子页表，避免虚拟机直接访问硬件MMU。该软件MMU的潜在问题可能会导致任意地址空间数据泄露。

4. I/O内存管理单元IOMMU（HY-DV4）：Hypervisor借助硬件IOMMU来约束进行直接“内存访问”（DMA）的设备驱动和进程。如果缺乏这一管控，虚拟机可能会通过DMA来修改物理内存（常见的攻击向量）。

5. 支持DMA的硬件设备（HY-DV5）：对于支持DMA的硬件设备来说，由于虚拟机能够控制设备，它能够通过对设备编程实现在宿主机物理内存上执行DMA操作（这样一来，通过HY-BF1中MMU实现的隔离管控功能也失去作用了）。

HY-BF1（虚拟机进程隔离）功能面临的潜在威胁

针对Hypervisor虚拟机进程隔离功能（HY-BF1）的主要威胁是进程隔离性的破坏（HYP-T1），上一节已经对相关的设计漏洞进行说明，此处不再赘述。

HY-BF2（设备调解和访问控制）功能面临的潜在威胁

设备虚拟化的三种常见方式为：

1. 模拟（Emulation）

2. 半虚拟化（Para-virtualization）

3. 设备透传（Passthrough）或自虚拟化（Self-Virtualizing）

其中，半虚拟化面临的威胁将在下一节（HY-BF3）的威胁分析中进行讲述；设备透传涉及到的DMA则可能导致HY-BF1的破坏，在上一节也已经分析过。

HY-BF3（虚拟机命令的直接执行）功能面临的潜在威胁

HY-BF3适用于半虚拟化。这里的问题是，如果缺乏对来自虚拟机指令的有效验证，这些指令可能直接被宿主机执行。这进而又会导致HY-BF1的破坏。

HY-BF4（虚拟机生命周期管理）功能面临的潜在威胁

HY-BF4面临的威胁主要有两个：

1. 镜像库中的非标准虚拟机镜像可能使用的是未及时更新的操作系统，从而引入HYP-T1到HYP-T3等威胁。

2. 由非标准镜像或快照启动的虚拟机实例可能引入HYP-T1到HYP-T3等威胁。

初看起来，上述两点似乎能够合并为一点，但是从虚拟机生命周期管理的角度来看，它们确实是不同的阶段。

HY-BF5（Hypervisor平台管理）功能面临的潜在威胁

HY-BF5涉及的威胁基本等同于传统环境下的远程管理面临的威胁，不再展开讲述。

虚拟机逃逸（Virtual Machine Escape）是一种网络安全攻击技术，指的是攻击者通过利用虚拟机（VM）内的漏洞或设计缺陷，实现从虚拟机内部向宿主机（Host）的操作系统进行攻击。在现代云计算环境中，虚拟机通常用于将多个用户或应用程序隔离在单个物理硬件上，确保它们的安全和隐私。然而，如果攻击者成功实施虚拟机逃逸攻击，他们便能突破这种隔离，进而访问和操控宿主机上的其他虚拟机或整个系统，对其进行破坏或窃取数据。

虚拟机逃逸攻击的原理很大程度上依赖于虚拟化技术的实现方式。虚拟化技术通常由Hypervisor负责，其主要任务是管理和调度多个虚拟机之间的资源分配。在虚拟机逃逸攻击中，攻击者寻找并利用虚拟机监视器的漏洞或设计缺陷，绕过虚拟机与宿主机之间的隔离层，实现对宿主机的操作系统及其资源的访问和控制。

现实中的虚拟机逃逸攻击研究的实施手段各异，但通常包括以下几种类型：

1. 利用虚拟机监视器的漏洞，如缓冲区溢出、整数溢出等，攻击者通过这些漏洞实现代码执行，最终获得宿主机的控制权限。

2. 利用虚拟设备或驱动程序的设计缺陷，攻击者可能通过虚拟网络接口、虚拟磁盘等设备逃出虚拟机环境。

3. 利用虚拟机管理工具和接口的安全漏洞，例如虚拟机控制台、虚拟机迁移等，攻击者可能在不被察觉的情况下实现虚拟机逃逸。

目前全球尚未见到公开发布的在野虚拟机逃逸漏洞利用攻击报告。截至目前，每年国内外顶级黑客大赛、黑客会议上都会有虚拟机逃逸漏洞利用 的相关挑战项目或议题。虚拟机逃逸是一个小众但持续的研究热点。其较高的 挑战难度和较大的破坏性吸引了许多国内外的顶尖安全研究者。为了防范这类攻击，安全专家和厂商需要持续关注并修复虚拟化技术中的安全漏洞，同时加强虚拟环境的监控和审计。

CVE-2020-14364是一个存在于QEMU 5.2.0版本以前的USB模拟模块的越界读写漏洞。QEMU是一款开源的虚拟化解决方案，旨在通过软件模拟硬件设备，从而实现多个操作系统在同一物理机上的并行运行。QEMU在云计算、虚拟化和嵌入式领域具有广泛的应用。

此漏洞主要影响QEMU中的USB设备模拟部分。在处理来自虚拟机的USB数据包时，QEMU中USBDevice结构体的setup_len成员超过了它的data_buf[4096]缓冲区长度，从而在do_token_in和do_token_out两个处理例程中分别造成越界读写。该漏洞可能导致QEMU进程崩溃，造成拒绝服务，或导致虚拟机中的攻击者能够在宿主机上以QEMU进程权限执行任意代码。

该漏洞有多种利用思路。其中一种利用思路如下：

在课程中，逃逸成功后，我们能够收到来自宿主机上的反弹shell：

最后，我们将常见的虚拟化攻击路径及相关技术进行一下归纳。

在下图这样一个也许真实也许虚幻、但是技术上可以实现的架构中，攻击者可能需要先break in，然后层层突破，不断break out。不过，这里仅仅考察了单节点环境，没有涉及横向移动：

就时下而言，PWN的狭义定义通常主要包括二进制程序和二进制协议实现的漏洞利用，技术上可以大概分为用户态（userland）PWN和内核态（kernel）PWN。在这一语义环境下，结合相关技术原理与实践经验，我们发现：

1. 容器逃逸、用户态权限提升、内核RCE（如攻击Linux TIPC模块漏洞）和虚拟机逃逸（如攻击KVM）都会涉及到内核PWN。反过来说，内核漏洞利用知识与技术可以是这三者的前提或基础。

2. 用户态RCE、用户态权限提升和虚拟机逃逸（如攻击QEMU）都会涉及到用户态PWN。就用户态而言，容器逃逸部分涉及的用户态程序漏洞多出于逻辑问题、对系统机制（如符号链接、Seccomp和Namespaces）的考虑与使用不周等，相对来说比较杂。

3. 内核态PWN场景通常需要考虑内核态的漏洞缓解机制，不需要考虑用户态的漏洞缓解机制（如ASLR、Stack Canary和PIE）；用户态场景通常需要考虑用户态的漏洞缓解机制，不需要考虑内核态的漏洞缓解机制。

4. 用户态PWN与内核态PWN有很多共通的漏洞利用技术或利用思想，如ROP与kROP；也有很多相似的漏洞缓解机制，如ASLR与KASLR。然而，其细节又有所不同。例如，虽然内核态KASLR的熵更小，但是一旦绕过KASLR失败，后果很可能是内核崩溃，对于意图非DoS的攻击者来说得不偿失。在这里，前因与后果形成了补足和制衡。

再从广义角度来看，如果我们将PWN定义为某种形式的入侵，那么上图涉及的不同环节都可以归到用户态PWN和内核PWN。当然，每个分类都更加抽象，其内部的漏洞利用技术之间的差异就更大了。

本文作者根据课程内容，简要介绍了虚拟化及虚拟化安全的基本知识技术，旨在科普相关知识，帮助更多读者了解虚拟化安全。

最后笔者推荐由星云实验室牵头对外发布的一些参考资料，希望可以给各位读者带来帮助。

本公众号原创文章仅代表作者观点，不代表绿盟科技立场。所有原创内容版权均属绿盟科技研究通讯。未经授权，严禁任何媒体以及微信公众号复制、转载、摘编或以其他方式使用，转载须注明来自绿盟科技研究通讯并附上本文链接。

关于我们