Azure Functions 提权漏洞分析

Azure Functions 是一种无服务器解决方案，可以使用户减少代码编写、减少需要维护的基础结构并节省成本。无需担心部署和维护服务器，云基础结构提供保持应用程序运行所需的所有最新资源。你只需专注于对你最重要的代码，Azure Functions 处理其余代码。Azure Functions允许您提供一个带有不同“钩子”的简单应用程序，以触发它运行。这些可以是简单的Web挂钩或其他基于云的服务上的事件（例如，写入OneDrive的文件）。 Azure Functions的一个很好的好处是它们可以轻松地与其他供应商的服务绑定，例如Twilio或GitHub。

过渡到云服务的一个最常见的好处是可以共同承担保护资产的责任，但是云提供商也不能避免安全漏洞，比如漏洞或错误配置。这是研究人员在过去几个月在Azure Functions中发现的第二次权限升级(EoP)漏洞。

今年2月份，安全公司Intezer研究人员发现微软的无服务器运算服务Azure Functions，存在一个特权提升漏洞，且程序代码可从Azure Functions DockerDocker逃脱（Escape）至Docker主机。但微软认为，这个漏洞不影响用户安全。

Azure Functions让用户不需要配置和管理基础设施，就能简单地开始执行程序代码，可由HTTP请求触发，并且一次最多只能执行数分钟处理该事件，用户的程序代码会在Azure托管的Docker中执行，无法逃脱受限的环境，但是这个Azure Functions的新漏洞，却可让程序代码逃脱至Docker主机。

当程序代码逃脱到了Docker，取得根访问权限，就足以破坏Docker主机，并获得更多的控制权，除了逃脱可能受到监控的Docker，还能转移到安全性经常被忽略的Docker主机。

这一次，Intezer研究人员是与微软安全响应中心(MSRC)合作并报告的新发现的漏洞。他们确定这种行为对Azure Functions用户没有安全影响。因为发现的Docker主机实际上是一个HyperV客户端，而它又被另一个沙箱层保护起来了。

不过，类似这样的情况仍然表明，漏洞有时是未知的，或者不受云用户的控制。推荐一种双管齐下的云安全方法：做一些基础工作，例如修复已知的漏洞和加固系统以减少受到攻击的可能性，并实现运行时保护，以便在漏洞利用和其他内存攻击发生时检测/响应它们。

Azure Functions Docker中的漏洞分析

Azure FunctionsDocker以-privileged Docker标志运行，从而导致/dev目录下的设备文件在Docker主机和Docker客户端之间共享。这是标准的特权Docker行为，然而，这些设备文件对“其他”文件具有“rw”权限，如下所示，这是我们提出的漏洞会发生的根本原因。

Azure Functions Docker与低权限的应用程序用户一起运行。Docker的主机名包含“沙箱”一词，这意味着将用户包含在低权限中是很重要的。容器使用–privileged标志运行，这意味着，如果用户能够升级为root用户，则他们可以使用各种Docker转义技术逃到Docker主机。

设备文件上的宽松权限不是标准行为，从我的本地特权Docker设置中可以看到，/dev中的设备文件默认情况下不是很宽松:

Azure Functions环境包含52个带有ext4文件系统的“pmem”分区。起初，我们怀疑这些分区属于其他Azure Functions客户端，但进一步评估表明，这些分区只是同一个操作系统使用的普通文件系统，包括pmem0，它是Docker主机的文件系统。

使用debugfs读取Azure FunctionsDocker主机的磁盘

为了进一步研究如何利用此可写磁盘而不会潜在地影响其他Azure客户，研究人员在本地容器中模拟了该漏洞，并与非特权用户“bob”一起建立了本地环境：

利用设备文件o+rw

在我们的本地设置中，/dev/sda5是根文件系统，它将成为我们的目标文件系统。

使用debugfs实用程序，攻击者可以遍历文件系统，如我们上面成功演示的那样。 debugfs还通过-w标志支持写入模式，因此我们可以将更改提交到基础磁盘。请务必注意，写入已挂载的磁盘通常不是一个好主意，因为它可能会导致磁盘损坏。

通过直接文件系统编辑利用

为了演示攻击者如何更改任意文件，我们希望获得对/ etc/passwd的控制权。首先，我们尝试通过直接编辑文件系统块的内容，使用zap_block命令来编辑文件的内容。在内部，Linux内核将这些变化处理到*device file* /dev/sda5，并且它们被写入缓存到与*regular file* /etc/passwd不同的位置。因此，需要刷新对磁盘的更改，但是这种刷新由debugfs实用程序处理。

使用debugfs用'A'（0x41）覆盖/etc/passwd内容

类似地，Linux内核为最近加载到内存中的页面托管了一个读取缓存。

不幸的是，由于与我们在写入缓存中说明的约束相同，对/dev/sda5的更改将不会传播到/etc/passwd文件的视图中，直到其缓存的页面被丢弃。这意味着，我们只能覆盖最近未从磁盘加载到内存的文件，或者等待系统重新启动以应用更改。

经过进一步研究，研究人员找到了一种方法来指示内核放弃读取缓存，以便他们的zap_block更改可以生效。首先，我们通过debugfs创建了一个到Docker的diff目录的硬链接，以便更改可以辐射到Docker：

该硬链接仍然需要root权限才能进行编辑，因此研究人员仍然必须使用zap_block来编辑其内容。然后，研究人员使用posix_fadvise指示内核从读取缓存中丢弃页面，这受一个名为pagecache management的项目的启发。这导致内核加载研究人员的更改，并最终能够将它们传播到Docker主机文件系统：

刷新读取缓存

Docker主机文件系统中的/etc/passwd，刷新后我们可以看到“AAA”字符串

总结

通过编辑属于Docker主机的任意文件，攻击者可以通过类似地对/etc/ld.so.preload进行更改并通过Docker的diff目录提供恶意共享对象来启动预加载劫持。该文件可以预加载到Docker主机系统中的每个进程中（之前使用此技术记录了HiddenWasp恶意软件），因此攻击者将能够在Docker主机上执行恶意代码。

对漏洞利用的PoC进行总结如下:

微软目前对此发现的评估是，这种行为对Azure Functions用户没有安全影响。因为我们探测的Docker主机实际上是一个HyperV客户端，所以它被另一个沙箱层保护。

无论你如何努力保护自己的代码，有时漏洞都是未知的或无法控制的。因此你应该具备运行时保护功能，以便在攻击者在你的运行环境中执行未经授权的代码时检测并终止攻击。