0x01 研究概述

在 Hyper-V 的虚拟网络交换机驱动程序 ( vmswitch.sys ) 中发现了一个严重漏洞。

该漏洞是使用我们命名为hAFL1的Fuzzer发现的，我们将其开源出来了(https://github.com/SB-GC-Labs/hAFL1) 。

hAFL1 是 kAFL 的修改版本，可以对 Hyper-V 半虚拟化设备进行模糊测试，并增加了结构感知、详细的崩溃监控和覆盖率指导。

Hyper-V 是Azure （微软的公有云）的底层虚拟化技术。

该漏洞允许远程代码执行(RCE) 和拒绝服务(DoS)。利用它，攻击者可以使用 Azure 虚拟机控制整个公有云平台，并在 Hyper-V 主机上运行任意代码。

该漏洞首次出现在2019 年 8 月的vmswitch版本中，该漏洞可能已经存在一年多。

2021 年 5 月，微软为漏洞CVE-2021-28476分配了9.9 的 CVSS 评分，并为其发布了补丁。

0x02 vmswitch.sys

为什么目标是 Hyper-V？越来越多的公司正在将其工作负载的主要部分迁移到公有云，例如 AWS、GCP 和 Azure。公有云为用户提供了灵活性，让他们无需管理自己的裸机服务器。然而，这些云本质上基于共享基础架构——共享存储、网络和 CPU 能力。这意味着管理程序中的任何漏洞都会产生更广泛的影响；它不仅会影响一台虚拟机，而且可能会影响其中的许多虚拟机。

Hyper-V 是 Azure 的底层虚拟化技术，我们决定以它的虚拟交换机 ( vmswitch.sys ) 为目标，因为它是云功能的核心关键组件。

为什么选择模糊测试？在开发模糊测试工具和静态分析 Hyper-V 的网络驱动程序vmswitch.sys 之间，我们选择了第一个。原因很简单——代码规模。手动审计挖掘漏洞很枯燥乏味，我们希望一个好的 fuzzer 能够找到不止一个Crashs。

在 Hyper-V 术语中，主机操作系统在Root Partition 中运行，客户操作系统在Child Partition 中运行。为了向子分区提供与硬件设备的接口，Hyper-V 广泛使用了半虚拟化设备。通过半虚拟化，VM 和主机都使用修改后的硬件接口，从而带来更好的性能。一种这样半虚拟化设备是网络交换机，这是我们的研究目标。

Hyper-V 中的每个半虚拟化设备都包含两个组件：

1、在子分区中运行的虚拟化服务使用者 ( VSC )。netvsc.sys是网络 VSC。

2、在根分区中运行的虚拟化设备提供程序 ( VSP )。vmswitch.sys是网络 VSP。

这两个组件通过 VMBus（一种基于超级调用的分区内通信协议）相互通信。VMBus 使用两个环形缓冲区——一个发送缓冲区和一个接收缓冲区来在客户和主机之间传输数据。

Hyper-V 中的半虚拟化网络由 netvsc（使用者）和 vmswitch（提供者）组成。

Fuzzing 是一种自动化软件测试技术，涉及提供无效或随机数据作为计算机程序的输入。fuzzer 生成输入，将它们发送到其目标并监控目标上的崩溃或意外行为。模糊测试的核心组件是harness，它负责将输入直接发送到目标。harness与目标紧耦合；它必须通过目标通常使用的通信通道发送输入。为了使模糊测试过程高效，现代Fuzzer实现了几个附加功能。第一个是覆盖指导——能够准确跟踪执行了哪些代码流并相应地改变新输入，目的是增加目标程序中访问的代码量。另一个重要功能是崩溃监控——获取有关模糊测试过程中发生的任何崩溃的详细信息的能力。此类信息可以是堆栈跟踪或触发崩溃的代码行。最后是结构意识; fuzzer 生成符合特定结构（例如网络协议、文件格式等）的输入，而不是发送完全任意的输入。这增加了通过基本验证在早期阶段处理输入而不是丢弃输入的机会。我们使用 fuzzing infrastructure 来指代包含上述组件以执行模糊测试过程的任何软件项目。

0x03 harness

我们的目标是拥有一个能够向vmswitch发送输入的模糊测试基础框架。此外，希望我们的 fuzzer 是可以实现覆盖引导，并提供详细的崩溃报告，准确指出发生崩溃的原因。最后，结构意识对我们来说也很重要，以vmswitch接受的格式发送输入，而不是使用任意输入浪费时间和资源。

开发Fuzzer的第一阶段是设计harness。我们从MSRC 博客文章中汲取灵感，该文章详细介绍了 VPCI（Hyper-V 的半虚拟化 PCI 总线）的模糊测试。由于这个目标与我们的相似，我们开始使用相同的步骤。

https://msrc-blog.microsoft.com/2019/01/28/fuzzing-para-virtualized-devices-in-hyper-v/

Microsoft 帖子中提出的想法很简单——找到 VSC 使用的 VMBus 通道，并使用此通道使用已知的、记录在案的 API 将数据发送到 VSP 。我们的目标是将这些步骤应用于我们的目标：查找netvsc使用的VMBus通道，并使用此通道使用VmbPacketAllocate和VmbPacketSend将数据发送到vmswitch。

1.查找 VMBus 通道

netvsc是在 Hyper-V 子分区的客户操作系统中运行的NDIS驱动程序，并公开虚拟化网络适配器。作为虚拟适配器初始化过程的一部分，netvsc分配了一个名为MiniportAdapterContext 的结构（这是作为函数NvscMicroportInit 的一部分发生的）。MiniportAdapterContext 的偏移量 0x18是我们的 VMBus Channel指针。

作为 netvsc 中初始化过程的一部分，VMBus Channel指针被写入 MiniportAdapterContext 结构。

有了这些新知识，我们编写了一个在子分区上运行的专用驱动程序 ( harness.sys )。它遍历所有 NDIS 微型端口适配器，找到我们想要模糊测试的适配器（通过对其名称进行字符串匹配）并从适配器上下文结构中获取 VMBus Channel指针。有了netvsc使用的 VMBus 通道，驱动程序就会允许我们向vmswitch发送数据。

通过ndis.sys驱动寻找VMBus通道的过程

2.vmswitch

Hyper-V 中的每个 VSP 都必须实现和注册数据包处理回调EvtVmbChannelProcessPacket。每当新数据包到达 VSP 时，都会调用此函数。在vmswitch 中，这个回调函数是VmsVmNicPvtKmclProcessPacket 。

vmswitch需要NVSP类型的数据包，这是一种用于通过 Hyper-V 的 VMBus 传输的数据包的专有格式。有许多 NVSP 数据包类型；有些负责设置VMBus 的发送和接收缓冲区，有些负责执行VSP 和VSC 之间的握手（例如交换NDIS 和NVSP 版本），有些用于在客户和主机之间发送RNDIS 消息。

RNDIS通过抽象控制和数据通道定义了主机和远程 NDIS 设备之间的消息协议。在 Hyper-V 设置中，“host”是客户 VM，“RNDIS 设备”是vmswitch或外部网络适配器，“抽象通信通道”是 VMBus。

我们决定将我们的模糊测试工作集中在处理 RNDIS 消息的代码流上，原因有两个：

1、有很多代码处理 RNDIS 消息。

2、在vmswitch中发现的相当多的漏洞都在 RNDIS 数据包处理中。

处理 RNDIS 消息的函数是VmsVmNicPvtVersion1HandleRndisSendMessage ，它直接会从VmsVmNicPvtKmclProcessPacket 调用。

要使用 RNDIS 消息Fuzzing vmswitch，我们必须调用这些函数并将 RNDIS 消息传递给它。

3.发送 RNDIS 消息

void VmsVmNicPvtKmclProcessPacket(
  VMBCHANNEL Channel,
  VMBPACKETCOMPLETION Packet,
  PVOID Buffer,
  UINT32 BufferLength,
  UINT32 Flags
)
{...}

VmsVmNicPvtKmclProcessPacket接受五个参数：VMBus Channel 指针、数据包对象、缓冲区及其长度以及flags。buffer 参数用于将数据包元数据发送到vmswitch。它由4个字段组成：

1、msg_type – NVSP 消息类型

2、channel_type – 0 表示数据，1 表示控制

3、send_buf_section_index – 写入数据的发送缓冲区部分的索引。回想一下，VMBus 通过两个环形缓冲区传输数据；此字段指定数据的确切位置

4、send_buf_section_size – 发送缓冲区中数据的大小

数据包处理回调的 Buffer 参数中的不同字段

起初，必须通过 VMBus 向缓冲区发送数据。但是经过一段时间的研究，我们找到了另一种发送 RNDIS 消息的方法，不涉及 VMBus 向缓冲区发送数据。可以分配内存，将数据复制到其中，然后创建指向已分配缓冲区的内存描述符列表（或MDL）。发现这种方式对我们来说更方便，因为它使我们无需将 RNDIS 消息复制到发送缓冲区。

要使用 MDL 发送 RNDIS 消息，上面的缓冲区指定以下值：

●msg_type = NVSP_MSG1_TYPE_SEND_RNDIS_PKT

●channel_type= 1

●send_buf_section_index = -1（表示使用MDL）

●send_buf_section_size = 0（使用 MDL 时忽略此参数）

MDL 本身附加到数据包对象。

此时，不仅能够向vmswitch发送任意输入，而且确切地知道要发送哪些数据包以及如何发送它们，以便执行 RNDIS 代码流。有了这一功能，我们的harness可以触发vmswitch的n day漏洞 ：CVE-2019-0717。

0x04 Harness 与 Fuzzer 连接

该过程的下一步是将我们的工具集成到一个模糊测框架中，不需要完全自己实现——编写超级调用、设计突变引擎、解码覆盖跟踪等。有几个选项可用，但我们选择了kAFL 似乎最适合我们的需求——Fuzzing内核模式驱动程序。

我们的Fuzzer有三个级别的虚拟化（用“LN”表示级别 N）。L0 – 裸机服务器 – 将在 Linux 的内置管理程序 KVM 上运行 kAFL。然后将创建我们的 Hyper-V 主机 (L1)——一个运行 Windows 10 且启用了 Hyper-V 的虚拟机。在我们的 Hyper-V 主机之上，将运行两台机器 (L2)：root分区，vmswitch将在其中执行，以及一个子分区，我们将从中运行我们的harness和Fuzzing vmswitch。

hAFL1 设置 -：vmswitch 在root分区（L2）内运行，harness在子分区（L2）内运行。

问题是kAFL 不支持嵌套虚拟化，而我们的设置是基于嵌套虚拟化的——我们在 KVM 之上的 Hyper-V 主机之上有一个客户操作系统。通过这样的设置，kAFL 无法直接与在 L2 中运行的组件进行通信。更准确地说，这意味着vmswitch缺乏覆盖信息，并且无法将fuzz有效载荷（输入）从 kAFL 发送到我们的harness。

因此，为了适应 kAFL，我们必须重新设置。如果我们不能从 L2 fuzz，那我们就试试能不能从 L1 fuzz 。实际上，这意味着必须找到一种方法来从 L1 内而不是从root分区内运行vmswitch。然后，我们只需从与vmswitch相同的虚拟化级别运行我们的工具。

幸运的是，我们找到了一个巧妙的解决方法。事实证明，当启用 Hyper-V 功能并禁用 Intel VTx 时，Windows 以回退模式启动，其中 Hyper-V 无法运行，但vmswitch仍会加载到内核内存中！但是，不存在root和子分区，因为 Hyper-V 不运行，所以我们只剩下 L1。这正是我们想要的，现在可以在单个Windows VM 上运行工具并调用我们的目标函数VmsVmNicPvtVersion1HandleRndisSendMessage 。

遇到的下一个问题是缺少 VMBus 通道。完全运行时，vmswitch使用 VMBus 通道与其使用者（netvsc实例）进行通信。但是由于 Hyper-V 处于非活动状态，并且没有正在运行的 VM，因此vmswitch没有这样的 VMBus 通道可供使用。我们需要找到一种方法来为vmswitch提供一个 VMBus 通道，或者让它自己初始化一个。

经过一段时间的逆向，我们在vmswitch 中发现了一个名为VmsVmNicMorph的特殊函数，它完全可以做到这一点——它为vmswitch初始化一个新的 VMBus 通道。然而，简单地调用这个函数会导致蓝屏，因为它试图调用与 VMBus 相关的函数，而 VMBus 并没有运行。我们决定patch所有 VMBus 逻辑。因为 VMBus 是一个独立的通信层，不会干扰正在发送的数据。你可以把它想象成 OSI 网络层模型：VMBus 是传输层，独立于vmswitch，应用层。也就是说，我们可以放弃执行 VMBus 逻辑，而仍然为vmswitch接收适当的 VMBus 通道对象使用。

还有一个问题需要解决。一个名为PatchGuard的 Windows 功能阻止了对签名内核模式代码的更改。所以如果我们想修改vmswitch 中的指令，必须禁用 PatchGuard。为此，我们使用了一个名为EfiGuard的开源工具，它为我们提供了相关功能：它禁用了内核补丁保护和驱动程序强制签名，允许我们在机器上运行我们未签名的harness驱动程序。

https://github.com/Mattiwatti/EfiGuard

我们在构建 hAFL1 过程中的问题和解决方案

当前的设置与我们最初设想的完全不同。vmswitch直接在 Windows 10 主机上运行（而不是在root分区内），我们的harness驱动程序 ( harness.sys ) 运行在同一级别而不是在子分区内。用户模式harness进程通过超级调用从 kAFL 接收fuzz有效载荷，并使用 IOCTL 将它们传递给我们的harness驱动程序。回顾一下——Hyper-V 无法使用，因为 VT-x 被禁用了。但是我们的fuzzer运行了，将模糊测试输入发送到vmswitch并获取覆盖信息以推动fuzzing过程向前发展。

hAFL1 设置 ：vmswitch 在 L1 内运行，我们的harness也在L1中运行。

0x05 Fuzzing改进

下面是我们对Fuzzer框架中加入的更多逻辑和功能。

1.覆盖引导

kAFL 利用Intel-PT在整个模糊测试迭代中跟踪指令指针的值，并改变输入以增加它命中的基本块的数量。为了仅从某个进程的上下文harness）中跟踪执行，kAFL 使用CR3 过滤，只有当 CR3 寄存器值与 CR3 过滤器值匹配时，它才会记录执行跟踪。

https://software.intel.com/content/www/us/en/develop/blogs/processor-tracing.html
https://software.intel.com/content/www/us/en/develop/documentation/debug-extensions-windbg-pt-user-guide/top/commands/commands-for-configuration/ip-filter-configuration.html

但是访问基本块的数量太少，即使是单个数据包也应该通过比Fuzzer UI 显示的更多的基本块进行传播。

分析发现，vmswitch以异步、多线程的方式处理数据包。数据包首先经过短暂的同步处理，然后作为工作项推送到队列中，等待由专用系统工作线程处理。显然，该线程与我们的harness具有不同的 CR3 值。这就是为什么 fuzzer 在它源自工作线程时根本不跟踪执行。为了克服这个问题，我们禁用了 CR3 过滤。这不会污染跟踪结果，因为只有我们在vmswitch 中触发了代码。

https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/system-worker-threads

最后，为了监控vmswitch的覆盖率，我们编写了一个 Python脚本将 Intel-PT 数据从 kAFL 格式转换为 IDA 的Lighthouse插件格式。

https://github.com/SB-GC-Labs/hAFL1/blob/main/tools/convert_kAFL_coverage_to_lighthouse.py
https://github.com/gaasedelen/lighthouse

vmswitch 覆盖率使用 IDA 的 Lighthouse 插件实现可视化

2.Crashs监控

为了能够有效地监控分析崩溃，Fuzzer有必要生成详细的崩溃报告。但是，kAFL 没有提供很多 Windows 目标中的崩溃信息。例如，它不会输出触发崩溃的目标代码中的堆栈跟踪或确切偏移量，我们需要自己实现这个逻辑。

我们使用了 Xen 代码库的一部分来获取堆栈跟踪和模块信息。然后，编写了两个 KVM 超级调用，将这些信息从 L1 发送回 kAFL。最后，我们实现并注册了一个特殊的 BugCheck 回调来调用这些 KVM 超级调用。

有了这些条件，我们能够获得有关vmswitch 中发生的每次崩溃的详细信息——一个完整的堆栈跟踪，包含函数名称和偏移量，如下截图所示。

来自 hAFL1 的详细崩溃报告，显示了堆栈跟踪、函数名称和其中的偏移量。

3.结构意识

为了更快地进行模糊测试，我们希望Fuzzer生成与目标期望的格式相匹配的输入。在我们的例子中，这些输入是 RNDIS 消息。

我们使用协议缓冲区定义了 RNDIS 消息，并使用libprotobuf-mutator 对它们进行了变异。为了将我们自定义的、基于协议缓冲区的变异策略集成到 kAFL 中，必须创建一个新状态并将其添加到 kAFL 的状态机中，这是一个管道。任何fuzz有效载荷都通过此管道由 kAFL 的内置变异器进行变异。

https://developers.google.com/protocol-buffers
https://github.com/google/libprotobuf-mutator
https://github.com/SB-GC-Labs/hAFL1/blob/main/README.md

0x06 漏洞挖掘

在 hAFL1 运行两个小时后，发现了一个关键的 CVSS 9.9 的 RCE 漏洞。

hAFL1 图形用户界面，接口与 kAFL 相同，但可以通过添加新的基于协议缓冲区的变异策略进行扩展。

https://github.com/SB-GC-Labs/hAFL1

该漏洞存在于vmswitch.sys ——Hyper-V 的网络交换机驱动程序中。它是通过从访客虚拟机向 Hyper-V 主机发送特制数据包来触发的，可被利用以实现 DoS 和 RCE。

该漏洞首次出现在 2019 年 8 月的版本中，表明该漏洞已在生产环境中存在了一年半以上。它影响了 Windows 7、8.1 和 10 以及 Windows Server 2008、2012、2016 和 2019。

Hyper-V 是 Azure 的管理程序；因此，Hyper-V 中的漏洞会导致 Azure 中的漏洞，并可能影响公有云的整个区域。从 Azure VM 触发拒绝服务将使 Azure 基础架构的主要部分崩溃，并关闭共享同一主机的所有虚拟机。

通过更复杂的利用链，该漏洞可以授予攻击者远程代码执行能力，通过控制主机和在其上运行的所有虚拟机，攻击者可以访问存储在这些机器上的个人信息，运行恶意软件等。

0x07 背景知识

1.vmswitch

在 Hyper-V 术语中，主机操作系统在“root分区”中运行，而客户操作系统在“子分区”中运行。为了向子分区提供与硬件设备的接口，Hyper-V 广泛使用了半虚拟化设备。通过半虚拟化，VM 知道它是虚拟的；VM 和主机都使用修改后的硬件接口，从而带来更好的性能。一种这样的半虚拟化设备是网络交换机，这是我们的研究目标。

每个半虚拟化设备由两个组件组成：

1、在子分区中运行的虚拟化服务使用者 (VSC)。netvsc.sys是网络 VSC。

2、在根分区中运行的虚拟化设备提供程序 (VSP)。vmswitch.sys是网络 VSP。

这两个组件通过 VMBus（一种基于超级调用的分区内通信协议）相互通信。

VSC 和 VSP 分别运行在根分区（Hyper-V 主机）和客户分区（客户 VM）上。

2.通讯协议

netvsc（网络使用者）使用NVSP类型的数据包通过 VMBus与vmswitch（提供者）通信。这些数据包有多种用途：初始化和建立两个组件之间的 VMBus 通道、配置各种通信参数以及将数据发送到 Hyper-V 主机或其他 VM。NVSP 包括许多不同的数据包类型；其中之一是用于发送 RNDIS 数据包的NVSP_MSG1_TYPE_SEND_RNDIS_PKT 。

3.RNDIS 和 OID

RNDIS通过抽象控制和数据通道定义了主机和远程 NDIS 设备之间的消息协议。在 Hyper-V 设置中，“主机”是客户 VM，“远程 NDIS 设备”是 vmswitch 或外部网络适配器，“抽象通信通道”是 VMBus。

RNDIS 也有各种消息类型——init、set、query、reset、halt等。当 VM 希望设置或查询其网络适配器的某些参数时，它会向vmswitch发送OID 请求——带有相关对象的消息标识符(OID) 及其参数。此类 OID 的两个示例是用于设置适配器 MAC 地址的OID_GEN_MAC_ADDRESS和用于设置适配器当前多播地址列表的OID_802_3_MULTICAST_LIST 。

RNDIS 设置消息结构，来自 RNDIS 规范。OID 是数据包的必填字段之一。

4.虚拟交换扩展

vmswitch，Hyper-V 的虚拟交换机，也被称为“Hyper-V 可扩展交换机”。它的扩展是 NDIS 过滤器驱动程序或 Windows 过滤平台 (WFP) 驱动程序，它们在交换机内部运行，可以捕获、过滤或转发处理的数据包。Hyper-V 可扩展交换机具有 OID 请求的控制路径，如下图所示：

Hyper-V 可扩展交换机扩展作为交换机控制路径的一部分

0x08 漏洞分析

1.臭名昭著的 OID

一些 OID 请求发往外部网络适配器，或连接到vmswitch 的其他网络适配器。此类 OID 请求包括例如硬件卸载、互联网协议安全 (IPsec) 和单root I/O 虚拟化 (SR-IOV) 请求。

当这些请求到达vmswitch接口时，它们被封装并使用OID_SWITCH_NIC_REQUEST类型的特殊 OID 沿可扩展交换机控制路径向下转发。新的 OID 请求形成为NDIS_SWITCH_NIC_OID_REQUEST结构，其成员OidRequest指向原始 OID 请求。生成的消息通过vmswitch控制路径，直到到达其目标驱动程序。流程如下图所示。

Hyper-V 可扩展交换机控制路径中的 OID 请求封装。

Microsoft 记录的 NDIS_SWITCH_NIC_OID_REQUEST 结构

2.漏洞代码

在处理 OID 请求时，vmswitch 会跟踪其内容以进行日志记录和调试；这也适用于OID_SWITCH_NIC_REQUEST 。但是，由于其封装结构，vmswitch需要对此请求进行特殊处理，并取消引用 OidRequest以跟踪内部请求。该缺陷是，vmswitch从未验证的值OidRequest，并因此取消引用无效指针。

以下步骤导致 vmswitch 中的漏洞函数：

1、消息首先由 RndisDevHostControlMessageWorkerRoutine 处理——一个通用的 RNDIS 消息处理函数。

2、vmswitch识别设置请求并将消息传递给更具体的处理程序 - RndisDevHostHandleSetMessage。

3、稍后，消息被传递到 VmsIfrInfoParamsNdisOidRequestBuffer。该函数负责使用IFR （跟踪记录器）跟踪消息参数，这是一种 Windows 跟踪功能，可以实时记录二进制消息。

4、最后，数据包到达 VmsIfrInfoParams_OID_SWITCH_NIC_REQUEST，它专门跟踪 OID_SWITCH_NIC_REQUEST 类型的请求及其各自的结构 NDIS_SWITCH_NIC_OID_REQUEST。

导致bug的函数调用链，处理特定 OID 的 RNDIS 请求消息的跟踪。

3.实现利用

netvsc，网络虚拟服务消费者 (vsc) 。不发送带有OID_SWITCH_NIC_REQUEST 的OID 请求。尽管如此，设计缺陷会导致vmswitch接受并处理此类请求，即使它来自客户 VM。这允许我们通过直接从客户 VM发送带有OID_SWITCH_NIC_REQUEST 的 RNDIS设置消息来触发跟踪机制中的任意指针取消引用漏洞。

这种漏洞可以作为两种利用场景的基础。如果OidRequest成员包含无效指针，Hyper-V 主机将直接崩溃。另一种选择是使主机的内核从内存映射设备寄存器中读取，进一步实现代码执行。Hyper-V 主机上的 RCE 将使攻击者能够随心所欲读取敏感信息、以高权限运行恶意负载等。

0x09 研究总结

该漏洞是由于虚拟机管理程序任意指针取消引用与设计缺陷造成的，该缺陷允许客户和主机之间的通信通道过于宽松。

CVE-2021-28476 等漏洞证明了共享资源模型（例如公有云）带来的风险。事实上，在共享基础设施的情况下，即使是简单的错误也可能导致毁灭性的结果，如拒绝服务和远程代码执行。

软件中的漏洞是不可避免的，这句话也适用于公有云基础设施。这加强了混合云战略的重要性，该战略不会将所有鸡蛋放在一个篮子里或一个区域中的所有实例上。这种方法将有助于迅速从 DoS 攻击中恢复，适当的分段将防止在某些机器被攻破后集群被控制。

本文翻译自：https://www.guardicore.com/labs/hafl1-our-journey-of-fuzzing-hyper-v-and-discovering-a-critical-0-day/及https://www.guardicore.com/labs/critical-vulnerability-in-hyper-v-allowed-attackers-to-exploit-azure/如若转载，请注明原文地址