远程云端执行：逐步探寻Azure云基础架构中的高危漏洞

一、概述

谈到云安全，我们就不得不提到，一部分客户往往盲目地信任云服务商自身提供的安全保障，而不再做额外的防护。纵观近几年来爆出的流行云漏洞，也许大家会认为，其中大多数漏洞都集中在客户端应用程序安全性上（包括不正确的配置或应用程序自身存在漏洞），而云服务商的基础架构本身则很少出现漏洞。但是，我们希望大家能够明白，云基础架构往往并不是绝对安全的。在本文中，我们将展示在Azure Stack上发现的多个攻击媒介和安全漏洞。

Check Point安全研究团队已经向Microsoft安全响应中心报告了本研究中发现的所有漏洞，同时以负责任的方式提供了解决方案，以确保其用户可以持续安全使用Azure Stack。

二、部署研究环境

对云组件进行安全研究往往比较困难，我们大多数情况下都在进行黑盒研究。但幸运的是，Microsoft有一个称为Azure Stack的本地Azure环境，主要提供给企业使用。此外，还有一个称为Azure Stack开发工具包（ASDK）的版本是免费的。我们只需要准备一台满足安装硬件要求的服务器，并遵循详细的安装指南进行安装即可。在安装完成后，我们将看到与Azure门户非常相似的用户门户和管理员门户。

默认情况下，ASDK带有一系列功能（核心组件），可以实现SQL Provider、APP Service等扩展。尽管如此，我们首先还是需要先看一下ASDK与Azure之间的不同。

Azure与ASDK之间的主要区别：

1、可扩展性：ASDK在资源有限的单个实例上运行，奇热并且其所有角色都作为由Hyper-V处理的独立虚拟机运行，这会导致一些内部体系结构存在差异。

2、ASDK不会像Azure那样运行最新版本的软件，而是会落后几个版本。

3、与Azure相比，ASDK具有非常有限的功能。

三、Azure Stack概述

首先，我们看到的是Azure Stack门户，该门户提供了一个简单可访问的UI，其中包括模版、PowerShell等等。这些组件用于部署和管理资源，并且是Azure Stack中的常用界面。它们建立在Azure资源管理器（ARM）上并与之交互。ARM决定可以处理的请求以及需要传递给其他层的请求。

分区请求代理包括Azure Stack中的核心资源提供程序，每个资源提供程序都包含一个与ARM层相互交互的API。资源提供程序是允许我们与底层进行通信的工具，其中包括可以通过门户访问的用户/管理员扩展。

下一层中包含与基础结构角色进行通信的基础结构控制器，包含一组内部API，这些API不对用户公开。

基础结构角色负责执行诸如计算、网络、存储等任务。

最后，基础结构角色中包含Azure Stack的所有管理组件，与基础硬件层进行交互，将硬件功能抽象为Azure Stack提供的上层软件服务。

ASDK基于Hyper-V，这意味着其所有角色在宿主服务器上都作为独立的虚拟机运行。基础架构包含独立的虚拟网络，可以将虚拟机与宿主机相隔离。

默认情况下，部署了多个基础结构角色，具体如下：

AzS-ACS01   Azure Stack存储服务

AzS-ADFS01  活动目录联合服务（ADFS）

AzS-CA01     Azure Stack角色服务的证书颁发机构服务

AzS-DC01     Azure Stack的活动目录、DNS和DHCP服务

AzS-ERCS01  紧急恢复控制台虚拟机

AzS-GWY01  边缘网管服务，例如：用于租户网络的VPN站点到站点连接

AzS-NC01    网络控制器，用于管理Azure Stack网络服务

AzS-SLB01    在Azure Stack中为租户和Azure Stack基础结构服务提供负载均衡多路复用服务

AzS-SQL01   用于Azure Stack基础结构角色的内部数据存储

AzS-WAS01  Azure Stack管理员门户和Azure资源管理服务

AzS-WASP01       Azure Stack用户（租户）门户和Azure资源管理服务

AzS-XRP01   Microsoft Azure Stack的基础结构管理控制器，包括计算、网络和存储资源提供程序

（来源：https://docs.microsoft.com/en-us/azure-stack/asdk/asdk-architecture）

如果我们将上图的核心抽象层拆分为主虚拟机：

资源管理层：AzS-WAS01、AzS-WASP01

资源提供层+基础结构控制层：AzS-XRP01

接下来，我们来看一个具体的示例，在示例中将具体说明上图中所有抽象层是如何协同工作的。

如果租户想要停止Azure Stack中的虚拟机，那么在内部会执行什么样的操作呢？

1、租户可以使用用户门户/CLI/PowerShell执行此操作，所有这些接口最终都会向运行在Azs-WASP01中的ARM（Azure资源管理器）发送描述相应操作的HTTP请求。

2、ARM执行必要的检查（例如：检查所需资源是否存在，或者是否属于该租户），然后尝试执行该操作。ARM有一些无法自行处理的操作，例如计算、存储等。因此，它会讲带有附加参数的请求转发到处理虚拟机计算操作（运行在Azs-XRP01上）的相应资源提供程序。

3、在最终关闭Hyper-V集群中的虚拟机之前，还存在一个内部的API请求链，其结果将在请求链中反馈给租户。

接下来，我们将详细描述在内部服务中发现的一些问题，这些问题可以导致我们获取到租户和基础设施机器的屏幕截图。

四、获取屏幕截图和信息泄漏漏洞（CVE-2019-1234）

Service Fabric Explorer是预先安装在计算机中的Web工具，它作为资源提供和基础结构控制层（AzS-XRP01）的角色。该工具可以让我们能够查看构建为Service Fabric 应用程序的内部服务（位于资源提供层）。

当我们尝试从Service Fabric Explorer访问服务的URL时，我们注意到其中有一些是不需要进行身份验证的，而通常情况需要进行证书身份验证或HTTP身份验证。

由此，我们就产生了一些问题：

*这些服务为什么不要求认证？

*暴露了什么API？

这些服务是使用C#编写的，并且其源代码不是公开的，因此我们需要使用反编译器来进行研究，这就需要我们了解Service Fabric应用程序的结构。

其中，有一个不需要身份验证的服务是“DataService”。我们首先需要找到该服务在Azs-XRP01计算机上的位置。通过运行WMI查询列出正在运行的进程，我们就很容易发现这一点：

其结果展现了主机上所有Service Fabric服务的位置，包括DataService。在DataService代码文件夹中执行目录列表会显示出很多DLL，其名称往往表示其作用：