Azure Functions 提权漏洞分析,azure ad介绍-ESG跨境

Azure Functions 提权漏洞分析,azure ad介绍

Azure函数提升能力的脆弱性分析

Azure Functions是一个无服务器的解决方案，可以让用户减少代码编写，减少要维护的基础结构，节省成本。不需要担心服务器的部署和维护。Cloud 基础架构提供了保持应用运行所需的所有最新资源。你只需要关注对你来说最重要的代码，Azure Functions会处理剩下的。Azure Functions允许你提供一个带有不同“钩子”的简单应用程序来触发它运行。这些可以是简单的Web挂钩或其他基于云的服务上的事件(例如，写入OneDrive的文件)。Azure函数的一个很好的优势是，它们可以很容易地绑定到其他供应商的服务，比如Twilio或GitHub。

过渡到云服务的一个最常见的好处是，他们可以分担保护资产的责任，但云提供商无法避免安全漏洞，如漏洞或错误配置。这是Azure Functions的研究人员在过去几个月里发现的第二个权限提升(EoP)漏洞。

今年2月，安全公司Intezer的研究人员发现，微软的无服务器计算服务Azure Functions存在一个权限提升漏洞，程序代码可以从Azure Functions DockerDocker逃逸到Docker host。但微软认为这个漏洞并不影响用户安全。

Azure Functions允许用户简单地开始执行程序代码，而无需配置和管理基础设施。它可以由HTTP请求触发，每次只能执行几分钟来处理这个事件。用户的程序代码会在Azure托管的Docker中执行，逃不出受限环境。然而，Azure函数的这个新漏洞允许程序代码逃到Docker主机。

当程序代码逃到Docker时，获得root权限就足以摧毁Docker主机，获得更多控制权。除了逃离可能被监控的Docker，还可以转移到安全性往往被忽略的Docker主机。

这一次，英特尔研究人员正与微软安全响应中心(MSRC)合作，报告新发现的漏洞。他们确信这种行为对Azure Functions用户没有安全影响。因为被发现的Docker主机实际上是一个HyperV客户端，而且是由另一个沙盒层保护的。

然而，像这样的情况仍然表明，漏洞有时是未知的或不受云用户的控制。推荐一种双管齐下的云安全方法:做一些基础的工作，比如修复已知漏洞和加固系统以降低被攻击的可能性，以及实施运行时保护以在漏洞和其他内存攻击发生时检测/响应它们。

Azure Functions Docker中的漏洞分析

Azure FunctionsDocker使用privileged Docker标志运行，这使得/dev目录中的设备文件在Docker主机和Docker客户端之间共享。这是标准的特权码头工人行为。但是，这些设备文件对“其他”文件具有“rw”权限，如下所示。这就是我们提出的漏洞的根本原因。

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

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

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

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

为了进一步研究如何在不潜在影响其他Azure客户的情况下利用这个可写磁盘，研究人员在本地容器中模拟了该漏洞，并与无特权用户“bob”建立了一个本地环境:

使用设备文件o+rw

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

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

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

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

使用debugfs用(0x41)覆盖/etc/passwd的内容

类似地，Linux内核为最近加载到内存中的页面提供一个读缓存。

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

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

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

刷新缓存

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

摘要

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

漏洞利用的概念验证总结如下:

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

无论您如何努力保护您的代码，有时漏洞是未知的或不可控的。因此，当攻击者在您的运行时环境中执行未经授权的代码时，您应该具有运行时保护功能来检测和终止攻击。

及参考资料来源:https://www . intezer . com/blog/cloudsecurity/royalflushprivilegeescalationvulnerabilityinazurefunctions/

特别声明：以上文章内容仅代表作者本人观点，不代表ESG跨境电商观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与ESG跨境电商联系。