AzureFunctions是一种无服务器解决方案，使用户能够编写更少的代码、减少要维护的基础设施并节省资金。无需担心部署和维护服务器，云基础架构提供保持应用程序运行所需的所有最新资源。您只需专注于对您最重要的代码，AzureFunctions会处理其余部分。AzureFunctions允许您提供具有不同“挂钩”的简单应用程序以触发它运行。这些可以是其他基于云的服务上的简单网络挂钩或事件（例如，写入OneDrive的文件）。AzureFunctions的一个很好的好处是它们可以很容易地绑定到其他供应商的服务，例如Twilio或GitHub。过渡到云服务最常见的好处之一是共同承担保护资产的责任，但云提供商也不能幸免于安全漏洞，例如错误或配置错误。这是过去几个月研究人员在AzureFunctions中发现的第二次提权(EoP)漏洞。今年2月，安全公司Intezer的研究人员发现，微软的无服务器计算服务AzureFunctions存在提权漏洞，程序代码可以从AzureFunctionsDocker逃逸（Escape）到Docker主机。但微软认为该漏洞不会影响用户安全。AzureFunctions允许用户简单地开始执行程序代码，而无需配置和管理基础设施。它可以由HTTP请求触发，一次只能执行几分钟以处理事件。用户的程序代码将在Azure托管的Docker中执行，无法逃脱受限环境，但AzureFunctions中的这一新漏洞允许程序代码逃逸到Docker主机。当程序代码逃逸到Docker并获得root权限后，就足以破坏Docker主机，获得更多的控制权。除了可以逃脱可能被监控的Docker之外，还可以转移到安全性经常被忽视的Docker主机上。这一次，Intezer研究人员与Microsoft安全响应中心(MSRC)合作并报告了新发现的漏洞。他们确定此行为对AzureFunctions用户没有安全影响。因为发现的Docker主机实际上是一个HyperV客户端，它被另一层沙盒保护。尽管如此，像这样的情况表明漏洞有时是未知的或不受云用户控制的。推荐一种双管齐下的云安全方法：做好基础工作，例如修复已知漏洞和加固系统以降低攻击的可能性，并实施运行时保护以检测/响应漏洞利用和其他内存攻击。AzureFunctionsDocker漏洞分析AzureFunctionsDocker使用-privilegedDocker标志运行，导致/dev目录下的设备文件在Docker主机和Docker客户端之间共享。这是标准的特权Docker行为，但是，这些设备文件对“其他”文件具有“rw”权限，如下所示，这是我们提出的漏洞的根本原因。AzureFunctionsDocker以低权限应用程序用户运行。Docker的主机名包含“沙箱”一词，这意味着包含低权限用户很重要。该容器使用--privileged标志运行，这意味着如果用户能够升级到root，他们可以使用各种Docker转义技术转义到Docker主机。设备文件的松散权限不是标准行为，正如我从我的本地特权Docker设置中看到的那样，默认情况下/dev中的设备文件不是很宽松：AzureFunctions环境包含52个“pmem”和ext4文件系统分区。起初，我们怀疑这些分区属于其他AzureFunctions客户端，但进一步评估发现这些分区只是同一操作系统使用的普通文件系统，包括pmem0，它是Docker主机的文件系统。使用debugfs读取AzureFunctionsDocker主机的磁盘为了进一步研究如何在不影响其他Azure客户的情况下利用这个可写磁盘，研究人员模拟了本地容器中的漏洞，该容器由非特权用户“bob”本地环境构建：利用设备文件o+rw在我们的本地设置中，/dev/sda5是根文件系统，它将成为我们的目标文件系统。使用debugfs实用程序，攻击者可以像我们上面成功演示的那样遍历文件系统。debugfs还通过-w标志支持写入模式，因此我们可以将更改提交到底层磁盘。重要的是要注意写入已安装的磁盘通常不是一个好主意，因为它会导致磁盘损坏。通过直接文件系统编辑进行利用为了演示攻击者如何更改任意文件，我们希望获得对/etc/passwd的控制权。首先，我们尝试通过直接编辑文件系统块的内容，使用zap_block命令来编辑文件的内容。在内部，Linux内核处理对*设备文件*/dev/sda5的这些更改，并将它们写入缓存到与*常规文件*/etc/passwd不同的位置。因此，需要刷新对磁盘的更改，但此刷新由debugfs实用程序处理。使用debugfs用'A'(0x41)覆盖/etc/passwd内容同样，Linux内核为最近加载到内存中的页面托管一个读取缓存。不幸的是，由于与我们在写缓存中所述的相同的限制，对/dev/sda5的更改将不会传播到/etc/passwd文件的视图，直到其缓存页面被丢弃。这意味着，我们只能覆盖最近没有从磁盘加载到内存中的文件，或者等待系统重启来应用更改。经过进一步研究，研究人员找到了一种方法来指示内核删除读取缓存，以便他们的zap_block更改生效。首先，我们通过debugfs创建了一个到Docker的diff目录的硬链接，以便更改可以辐射到Docker：这个硬链接仍然需要root权限才能编辑，因此研究人员仍然必须使用zap_block来编辑它的内容。然后，研究人员使用posix_fadvise来指示内核从读取缓存中丢弃页面，灵感来自一个名为页面缓存管理的项目。这导致内核加载研究人员的更改，并最终能够将它们传播到Docker主机文件系统：刷新Docker主机文件系统中的读取缓存/etc/passwd，刷新后我们可以看到通过编辑Arbitrary总结的“AAA”字符串属于Docker主机的文件，攻击者可以通过类似地更改/etc/ld.so.preload并通过Docker的diff目录提供恶意共享对象来启动预加载劫持。该文件可以预加载到Docker主机系统中的每个进程中（HiddenWasp恶意软件之前已使用该技术进行了记录），因此攻击者将能够在Docker主机上执行恶意代码。该漏洞利用的PoC总结如下：微软目前对此发现的评估是，此行为对AzureFunctions用户没有安全影响。因为我们探测的Docker主机实际上是一个HyperV客户端，它受到另一层沙盒的保护。无论您如何努力保护您的代码，有时漏洞都是未知的或超出您的控制范围。因此，当攻击者在您的运行时环境中执行未经授权的代码时，您应该采取运行时保护措施来检测和阻止攻击。本文翻译自：https://www.intezer.com/blog/cloud-security/royal-flush-privilege-escalation-vulnerability-in-azure-functions/
