原文：
https://www.intezer.com/blog/cloud-security/royal-flush-privilege-escalation-vulnerability-in-azure-functions/
过渡到云服务的最常见好处之一就是保护资产的责任。但是云提供商无法幸免于安全性错误，例如漏洞或配置错误。这是 我们过去几个月在Azure Functions中发现的第二个特权升级（EoP）漏洞。
我们使用了该漏洞并将其报告给Microsoft安全响应中心（MSRC）。他们确定此行为对Azure Functions用户没有安全影响。由于我们调查的Docker主机实际上是HyperV来宾，因此它受到了另一个沙箱层的保护。
尽管如此，类似这样的情况仍然表明，漏洞有时是未知的，或者不受云用户的控制。建议采取两方面的方法来实现云安全性：做一些基础工作，例如修复已知的漏洞和加固系统以减少受到攻击的可能性，并实施运行时保护以检测/响应漏洞后利用和其他内存中的攻击，例如他们发生。
披露Azure Functions容器中的漏洞
Azure Functions容器以–privileged Docker标志运行，从而导致/ dev目录中的设备文件在Docker主机和容器guest虚拟机之间共享。这是标准的特权容器行为，但是，这些设备文件对“其他”文件具有“ rw”权限，如下所示，这是我们当前存在漏洞的根本原因。
Azure Functions容器与低特权应用程序 用户一起运行。容器的主机名包含单词Sandbox，这意味着以低特权包含用户对于它很重要。容器使用–privileged标志运行，这意味着如果用户能够升级为root用户，他们将能够使用各种Docker转义技术转义至Docker主机。
设备文件上的宽松权限不是标准行为。从我自己的本地特权容器设置中可以看出，默认情况下，/ dev中的设备文件不是很宽松：
Azure Functions环境包含52个带有ext4文件系统的“ pmem”分区。最初，我们怀疑这些分区属于其他Azure Functions客户端，但是进一步评估显示，这些分区只是同一操作系统使用的普通文件系统，包括pmem0（这是Docker主机的文件系统）。
使用debugfs读取Azure Functions Docker主机的磁盘
为了进一步研究如何利用此可写磁盘而不潜在地影响其他Azure客户，我们在本地容器中模拟了该漏洞，并与非特权用户'bob'一起建立了本地环境：
利用设备文件o + rw
在我们的本地设置中，/ dev / sda5 是根文件系统，它将成为我们的目标文件系统。
使用debugfs 实用程序，攻击者可以遍历文件系统，如我们上面成功演示的那样。debugfs 还通过-w 标志支持写模式，因此我们可以将更改提交到基础磁盘。重要的是要注意，写入已装入的磁盘通常不是一个好主意，因为它可能会导致磁盘损坏。
通过直接文件系统编辑利用
为了演示攻击者如何更改任意文件，我们希望获得对/ etc / passwd的控制权。首先，我们尝试 通过直接编辑文件系统块的内容，使用zap_block命令来编辑文件的内容。在内部，Linux内核将这些对* device文件* / dev / sda5的更改处理， 并且将它们写缓存在与对* regular文件* / etc / passwd的更改不同的位置。结果，需要将更改刷新到磁盘，但是此刷新由debugfs实用程序处理。
使用debugfs用'A'（0x41）覆盖/ etc / passwd内容
同样，Linux内核为最近加载到内存中的页面托管读取缓存。
不幸的是，由于与我们在写缓存中说明的约束相同，对/ dev / sda5的更改将不会传播到/ etc / passwd 文件的视图中，直到其缓存的页面被丢弃为止。这意味着，我们只能覆盖最近未从磁盘加载到内存的文件，或者等待系统重新启动以应用更改。
皇家同花顺
经过进一步研究，我们能够找到一种方法来指示内核放弃读取缓存，以便我们的zap_block 更改可以生效。首先，我们通过debugfs创建了 到容器的diff 目录的硬链接，以便更改可以辐射到我们的容器：
该硬链接仍然需要root权限才能编辑，因此我们仍然必须使用zap_block来编辑其内容。然后，我们使用posix_fadvise 来指示内核从读取缓存中丢弃页面（刷新它们，因此是该技术的名称），这受一个 名为pagecache management的项目的启发（来源：fadv.c ，我们对其进行了稍微编辑）。这导致内核加载我们的更改，我们终于能够将它们传播到Docker主机文件系统：
刷新读取缓存
Docker主机文件系统中的/ etc / passwd。刷新后我们可以看到“ AAA”字符串
概括
通过能够编辑属于Docker主机的任意文件，攻击者可以 通过类似地对/etc/ld.so.preload进行更改并通过容器的diff 目录提供恶意共享对象来启动预加载劫持。该文件可以预加载到Docker主机系统中的每个进程中（我们之前使用此技术记录了HiddenWasp恶意软件），因此攻击者将能够在Docker主机上执行恶意代码。
对漏洞利用的PoC进行总结：
后记
我们向Microsoft安全响应中心（MSRC）演示了此漏洞。他们的评估是，此行为对Azure Functions用户没有安全影响。由于我们调查的Docker主机实际上是HyperV来宾，因此它受到了另一个沙箱层的保护。
无论您如何努力保护自己的代码，有时漏洞都是未知的或无法控制的。您应该具有运行时保护，以在攻击者在您的生产环境中执行未经授权的代码时检测并终止。
本文迁移自知识星球“火线Zone”
