AzureScape:ACI容器中的K8s跨账户集群接受研究

频道:科技 日期: 浏览:17

中国世界杯预选赛2022赛程时间www.9cx.net)实时更新比分中国世界杯预选赛2022赛程时间数据,中国世界杯预选赛2022赛程时间全程高清免费不卡顿,100%原生直播,中国世界杯预选赛2022赛程时间这里都有。给你一个完美的观赛体验。

0x01 破绽形貌

Azure 容器实例(ACI) 是 Azure 的容器即服务 (CaaS) 产物,ACI)使客户能够在 Azure 中运行容器而无需治理底层服务器。最近有研究职员发现并向 Microsoft 披露了 ACI 中的平安破绽。恶意的 Azure 用户可能会行使这些问题逃逸到其他用户的容器上执行代码,窃取部署到平台的客户敏感文件,并可能滥用 ACI 的基础设施举行挖矿。研究职员将该破绽命名为Azurescape——公有云中的跨账户容器逃逸接受破绽。

https://azure.microsoft.com/en-us/services/container-instances/

Azurescape 允许恶意用户损坏托管 ACI的多租户Kubernetes集群,确立对其他用户容器的完全控制。这篇文章形貌了研究历程、破绽剖析,并提出了珍爱 Kubernetes 的措施,重点是多租户防止类似攻击的缓解措施。

微软在我们披露后不久修补了 ACI,现在还不知道 Azurescape 是否被在野行使。

0x02 Azure容器实例

Azure 容器实例 (ACI) 于2017 年 7 月宣布,是大型云提供商提供的第一个容器即服务 (CaaS) 产物。借助 ACI,客户无需治理底层基础结构即可将容器部署到 Azure。ACI 认真扩展、请求路由和调剂,为容器提供无服务器体验。

https://azure.microsoft.com/en-us/blog/announcing-azure-container-instances/

Azure 官网对 ACI 的形貌如下:“无需治理虚拟机或学习新工具即可快速开发应用程序,它只是在容器中、在云中运行的程序。”

在集群内部,ACI托管在客户容器的多租户集群上。刚最先是使用 Kubernetes 集群,在已往的一年里,微软也最先在 Service Fabric 集群上托管 ACI。此处的破绽会影响 Kubernetes 上的 ACI,本文的其余部门将仅参考该架构。凭证我们的测试,我们在平台上部署了数千个容器,在披露时 Kubernetes 托管了约莫 37% 的 ACI 新确立的容器。

该图说明晰托管在多租户 Kubernetes 群集上的 Azure 容器实例,显示了主节点上的 api 服务器若何与为三个差异客户运行的三个事情节点相关联。 租户界限用红色虚线示意。


图 1. 托管在多租户 Kubernetes 集群上的 ACI。

在 ACI 等多租户环境中,你需要在租户之间实行强界限。在 ACI 中,该界限是节点虚拟机。每个客户容器都在专用的单租户节点上的 Kubernetes pod 中运行。这种 Kubernetes 多租户方式通常称为node-per-tenant。

0x03 AzureScape 攻击场景

ACI 会防止相邻容器的恶意攻击。由于险些任何人都可以将容器部署到平台上,因此 ACI 必须确保恶意容器不会举行损坏、泄露信息、执行代码或以其他方式影响其他客户的容器,这种攻击影响就是跨账户或跨租户攻击。

Azure 容器实例中的跨账户攻击场景图解,展示了恶意客户若何占用事情节点。 


图 2. 跨账户攻击场景。

以下部门涵盖了我们对 ACI 中跨账户攻击的研究。我们发现了一种跨租户攻击,恶意的 Azure 用户可以通过这种攻击举行容器逃逸,获取特权 Kubernetes 服务帐户令牌并接受 Kubernetes api-server,从而确立对多租户集群和在其中运行的所有客户容器的完全控制。

0x04 ACI 容器逃逸

CaaS 产物很难研究。用户只露出了他们的容器环境,而且通过防火墙阻止接见内陆网络。为了更好地领会 CaaS 平台若何运行我们的容器,我们确立了 WhoC。WhoC是一个容器镜像,它可以读取执行它的容器runtime,基于 Linux 容器中一个很少讨论的设计缺陷,允许它们读取底层主机的容器runtime。这个想法与 CVE-2019-5736异常相似,差异之处在于CVE-2019-5736是读取runtime,它WhoC是笼罩主机的runtime。

https://github.com/twistlock/whoc
https://nvd.nist.gov/vuln/detail/CVE-2019-5736
https://unit42.paloaltonetworks.com/breaking-docker-via-runc-explaining-cve-2019-5736/

通过将 WhoC 部署到 ACI,我们能够检索平台中使用的容器runtime。不出所料,我们发现了行业尺度容器runtime runC。

https://github.com/opencontainers/runc

让我们措手不及的是runC的版本,如图 3 所示。

屏幕截图显示了在 2016 年 10 月 1 日宣布的 runC v1.0.0-rc2 上运行的 Azure 容器实例。 


图 3. ACI 中使用的容器runtime。

RunC v1.0.0-rc2 于 2016 年 10 月 1 日宣布,而且容易受到至少两个容器逃逸破绽的攻击。

https://unit42.paloaltonetworks.com/breaking-docker-via-runc-explaining-cve-2019-5736/

ACI 中存在这个旧版本的 runC,使用这个容器映像对其举行优化并将其部署到 ACI。通过cve-2019-5736乐成突破容器,并获得了一个在底层主机上以 root 身份运行的反向 shell,主机是一个 Kubernetes 节点(Node)。

https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-12/prisma-cloud-compute-edition-admin/runtime_defense/incident_types/reverse_shell.html

一旦我们发现 ACI 中存在这个旧版本的 runC,我们就接纳了那时开发的 PoC 容器映像,对其举行了优化并将其部署到 ACI。 我们乐成地突破了容器,并获得了一个在底层主机上以 root 身份运行的反向 shell,效果证实它是一个 Kubernetes 节点。 在这里,我们展示了行使 CVE-2019-5736 来逃避我们的 ACI 容器的历程的屏幕截图。


图 4. 行使 CVE-2019-5736 来逃逸 ACI 容器。

虽然实现了容器逃逸,但仍然在租户界限内——VM节点 。CaaS 平台可以抵御庞大的攻击者,这些攻击者可以通过内核破绽实现权限提升和容器逃逸。

该图显示了租户界限若何提防恶意客户。 虽然我们逃离了我们的容器,但我们仍然在租户界限内——节点 VM。 CaaS 平台旨在抵御庞大的攻击者,这些攻击者拥有内核破绽,可实现权限提升和容器突破。 恶意容器发作是一种预期的威胁,通过节点级隔离可以容忍。


图 5. 获取节点权限后任然在node中。

0x05 探测K8s节点环境

探测扫描节点可以验证当前容器是唯一的客户容器。使用Kubelet凭证,我们列出了集群中的 pod 和节点。该集群托管了约莫 100 个客户 pod,拥有约莫 120 个节点。每个客户都被分配了一个 Kubernetes 命名空间,他们的 pod 在其中运行;我们的容器ID是caas-d98056cf86924d0fad1159XXXXXXXXXX。

https://kubernetes.io/docs/concepts/overview/components/,kubelet

可以看到节点的 Kubelet 允许匿名接见,实验接见相邻节点上的 Kubelet。所有实验接见相邻节点的请求都超时了,可能是由于防火墙设置阻止了事情节点之间的通讯。

节点在kubernetes.azure.com/cluster标签中引用了集群名称,花样如下:CAAS-PROD-< LOCATION >-LINUX-< ID >。


图 6. 集群名称。

我们部署了几个分支容器,它们在差其余 Kubernetes 集群节点上。发现每个集群节点都有唯一的集群 ID,局限在 1-125 之间。这些集群 ID 解释托管了几十个集群节点。

1.Kubernetes 1 day

接下来,我们检查了集群的 Kubernetes 版本。

Azure 容器实例托管在运行 Kubernetes v1.8.4、v1.9.10 或 v1.10.9 的群集上,如下所示。 这些版本于 2017 年 11 月至 2018 年 10 月时代宣布,容易受到多个已知破绽的攻击。


图 7. ACI Kubernetes 版本。

ACI 托管在运行 Kubernetes v1.8.4、v1.9.10 或 v1.10.9 的集群上。这些版本于 2017 年 11 月至 2018 年 10 月时代宣布,容易受到多个已知破绽的攻击。运行较旧的 Kubernetes 版本有较大的风险,但它纷歧定会导致 ACI 中的平安问题。

回首已往的 Kubernetes 破绽,寻找可以通过被控节点提升权限或接见其他节点的破绽,目的锁定: CVE-2018-1002102。

https://github.com/kubernetes/kubernetes/issues/85867

2.Kubernetes CVE-2018-1002102

当为kubectl exec < pod > < cmd >下令提供服务时,api-server 会将请求推迟到适当的 Kubelet 的 / exec端点。

CVE-2018-1002102 是 api-server 与 Kubelets 通讯中存在的破绽,可以实现重定向。通过将 api-server 的请求重定向到另一个节点的 Kubelet,恶意 Kubelet 下令可以在集群中流传。图8展示了破绽的基本流程:

CVE-2018-1002102 的基本流程:1) 由 api-server 服务的下令,2) api-server 将请求延迟到适当的端点,3) 302 重定向,4) 通过集群流传。 


图 8. CVE-2018-1002102 行使流程。

破绽行使条件条件:

存在破绽的 api-server 版本:

获取一个节点权限:

通过 api-server 可以使被控节点与其他节点通讯。例如,可以通过向被控节点上的 pod 发出 kubectl exec 来完成。

事实证实,ACI 知足第三个条件条件。ACI 支持通过镜像kubectl exec的az container exec 下令在上传的容器上执行下令。

皇冠hg0088开户www.huangguan.us)是皇冠体育官方正网线上开放会员开户、代理开户,额度自动充值等业务的直营平台。

az container exec --name  --exec-command

确立一个行使 CVE-2018-1002102 的自界说 Kubelet 映像,将传入的 exec 请求重定向到其他节点上的 pod。为了最大限度地施展作用,将其设置为以 api-server pod 为目的,最后,运行az container exec my-ctr --exec-command /bin/bash,希望能在 api-server 容器上确立一个 shell。

执行下令失败了,经由一些调试,我们注重到重定向操作仅在目的容器托管在统一节点上时才有用。这有用地消除了攻击,由于我们无法流传到其他节点。剖析CVE-2018-1002102的补丁,确实对该破绽的修复。

https://github.com/kubernetes/kubernetes/pull/66516

重新检查到达节点的exec请求,请求可能会从 api-server IP 到达,如图 8 所示。然则,请求来自在默认命名空间中运行的“bridge” pod。

重新检查到达节点的 exec 请求后发现,这些请求源自在默认命名空间中运行的被称为“网桥”的 pod,如图所示。 


图 9.az container exec会话时代的 Kubelet 毗邻。

我们发现 ACI 将exec请求的处置从 api-server 转移到自界说服务。这可能是通过将az 容器 exec下令路由到桥接容器而不是 api-server 来实现的。

我们发现 ACI 将 exec 请求的处置从 api-server 转移到自界说服务。 这可能是通过将 az 容器 exec 下令路由到桥接容器而不是 api-server 来实现的。


图 10. Bridge Pod 处置 ACI 中的执行程序。

网桥镜像标签是master_20201125.1,解释它是在 CVE-2018-1002102 之后更新的。从其最近的构建时间和拒绝重定向exec请求来看,似乎 CVE-2018-1002102 的补丁已经patch到了bridge上。微软应该是注重到了此破绽影响了他们的自界说网桥 Pod 并举行了修补。

值得一提的是,CVE-2018-1002102 也可以在其他情形下被行使,例如,当客户端要求恶意 Kubelet 检索容器日志(例如kubectl 日志)时。这现实上与 ACI 相关,其中此功效是通过az container logs 下令实现的。但与exec请求一样,ACI 将日志检索的处置推迟到适当的log-fetch专用 pod上 。与 Bridge Pod 一样,CVE-2018-1002102 的修复程序也被移植到log-fetch Pod,以防止被行使。

0x06 获取集群治理员权限

CVE-2018-1002102 不在讨论局限内,但我们在调试破绽行使时确实注重到了一些新鲜的事情。到达节点的exec请求包罗一个Authorization Header头,其中包罗一个 Kubernetes 服务帐户令牌,如图 11 所示。

到达节点的 exec 请求包罗一个 Authorization 标头,其中包罗一个 Kubernetes 服务帐户令牌,如图所示。


图 11. Bridge 发送带有服务帐户令牌的“exec”请求。

在这里找到令牌令人惊讶。如前所述,集群中的 Kubelet 被设置为允许匿名接见,因此请求不需要通过令牌举行身份验证,也许是旧版本中遗留的令牌。

Kubernetes 服务帐户令牌是未加密的 JSON Web 令牌 (JWT),因此它们是可解码的。如下所示,吸收到的令牌是“bridge”服务帐户的服务帐户令牌。思量到来自桥接 Pod 的请求,这是有原理的。

https://jwt.io/

收到的令牌是“网桥”服务帐户的服务帐户令牌。 思量到来自桥接 Pod 的请求,这是有原理的。


图 12. 已解码的桥接服务帐户令牌。

若是你要运行 Kubernetes,一定要注主要将服务帐户令牌发送给谁:任何收到令牌的人都可以自由使用它并伪装成其所有者。令牌窃取者很可能对他们被盗令牌的权限异常感兴趣。api-server 公然了两个允许客户端查询其权限的 API,SelfSubjectAccessReview和SelfSubjectRulesReview。kubectl 提供了kubectl auth can-i作为接见这些 API 的便捷方式。

以下是默认命名空间中“Bridge”令牌的权限:

这显示了默认命名空间中“桥”令牌的权限。 


图 13. 桥接令牌权限——默认命名空间。

查看其他命名空间,权限是一致的,解释它们是集群局限的(而不是命名空间局限的)。以下是 kube-system 命名空间中令牌的权限。实验确定允许我们在多租户集群中流传的权限:

这显示了 kube-system 命名空间中令牌的权限,包罗 pods/exec 权限,解释令牌可用于在集群中的任何 Pod 上执行下令。 


图 14. 桥接令牌权限 - kube-system 命名空间。

履历厚实的 Kubernetes 平安职员可能已经确定了pods/exec权限,这解释该令牌可用于在集群中的任何 pod 上执行下令——包罗 api-server pod!图 15 显示了在 api-server 容器上打开 shell 的令牌:

这显示了在 api-server 容器上打开 shell 的令牌。 


图 15. 使用网桥的令牌在 api-server 上弹出一个 shell。

我们刚刚完成了一次跨账户攻击。通过在 api 服务器上执行代码,我们现在是集群治理员了,可以完全控制多租户集群和其中的所有客户容器:)

0x07 Azurescape 攻击总结

让我们总结一下恶意 Azure 客户可能通过托管 ACI 的多租户 Kubernetes 集群获得治理权限的步骤:

将行使 CVE-2019-5736 的镜像部署到 ACI。恶意镜像在执行时在底层节点上实现逃逸代码执行。

在节点上,监听 Kubelet 端口 10250 上的流量,并守候在Authorization标头中包罗 JWT 令牌的请求。

发出az container exec以在上传的容器上运行下令。桥接 Pod 将向受熏染节点上的 Kubelet 发送 exec 请求。

在节点上,从请求的Authorization标头中提取桥接令牌,并使用它在 api-server 上获取 shell。

以下视频演示了该攻击:

https://youtu.be/YfZBwKP18CQ

恶意 Azure 用户可以损坏托管 ACI 的多租户 Kubernetes 集群。作为集群治理员,攻击者可以在其他客户容器中执行下令、泄露部署到平台的敏感信息和私有映像,或者部署加密挖矿程序。

0x08 获取Cluster权限的另一种方式:Bridge SSRF

某些功效仅在 Kubernetes 上受支持,例如gitRepo volume。若是 ACI 容器使用了此类功效,而且它部署在 Kubernetes 集群上,这意味着其他容器可能会控制Kubernetes。私有虚拟网络中的容器就是这种情形。

https://docs.microsoft.com/en-us/azure/container-instances/container-instances-volume-gitrepo
https://docs.microsoft.com/en-us/azure/container-instances/container-instances-vnet

我们发现的第二个问题是网桥 Pod 中的服务器端请求伪造 (SSRF) 破绽。

当桥接 Pod 为az 容器 exec< ctr > < cmd >下令提供服务时,它会向响应的 Kubelet 的/exec端点发送请求。桥接器凭证Kubelet 的 /exec 端点的API 规范组织请求,天生以下 URL:

https://<
  nodeIP >:10250/exec/< customer-namespace >/< customer-pod >/< customer-ctr >?command=< url-encoded-cmd >&error=1&input=1&output=1&tty=1

Bridge必须以某种方式填充 <> 中缺少的参数,< nodeIP >的值是从客户 pod 的status.hostIP字段中检索到的。发现这一点异常有趣,由于节点有权更新其 pod 的状态(例如,为了将其 pod 的status.state字段更新为Running、Terminated等)。

我实验使用受熏染节点的凭证更改 pod 的status.hostIP字段,确实起作用了,但在一两秒钟后,api-server 将hostIP字段更正为其原始值。只管更改没有连续存在,但我们可以重复更新此字段。

我们编写了一个小脚原本频频更新 pod 的状态,并使用它来将status.hostIP字段设置为1.1.1.1。然后发送了一个az container exec下令。下令执行失败,验证网桥将exec请求发送到1.1.1.1而不是真实节点 IP。我们最先思量哪些特制的hostIP可以诱使网桥在其他 pod 上执行下令。

简朴地将 pod 的status.hostIP设置为另一个节点的 IP 也没有乐成。Kubelets 只接受指向它们托管的容器的请求,纵然Bridge将exec请求发送到另一个 Kubelet 的 IP,URL 仍将指向我们的命名空间、pod 名称和容器名称。

然后我们意识到 api-server 现实上并没有验证status.hostIP值是否是一个有用的 IP,而且会接受任何字符串——包罗 URL 组件。经由几回实验,我们想出了一个hostIP值,它会诱使网桥在 api-server 容器而不是我们的容器上执行下令:

< apiserver-nodeIP > :10250/exec/kube-system/< apiserver-pod >/< apiserver-container >?command=< url-encoded-command >&error=1&input=1&output=1&tty=1,

此hostIP值将导致网桥将exec请求发送到以下 URL:

https:// < apiserver-nodeIP >:10250/exec/kube-system/< apiserver-pod-name >/< apiserver-ctr >?command=< url-encoded-command >&error=1&input=1&output=1&tty=1 , :10250/exec/< customer-namespace >/< customer-pod-name >/< customer-ctr-name >?command=< command >&error=1&input=1&output=1&tty=1

我们将 pod 的status.hostIP设置为此值并通过az container exec执行下令。攻击乐成了!我们拿到的不是容器的shell,而是 api-server 容器的shell。完整的攻击可以在以下视频中看到:

https://youtu.be/7Alea_9oZgU

诱骗Bridge打开 api-server上的shell。

这里的影响与之前的攻击完全相同——对多租户集群的完全治理控制。

0x09 研究总结

跨账户破绽是公有云的“噩梦”。Azurescape 证实它们比我们想象的更真实。云提供商在珍爱他们的平台方面投入了大量资金,但不能阻止地会存在未知的0 day破绽并使用户面临风险。云用户应该对云平安接纳深度防御方式,以确保控制和检测破绽,无论威胁来自外部照样来自平台自己。

本文翻译自:https://unit42.paloaltonetworks.com/azure-container-instances/

澳洲幸运5是哪个国家的www.a55555.net)?澳洲幸运5是澳洲幸运5彩票官方网站,开放澳洲幸运5彩票会员开户、澳洲幸运5彩票代理开户、澳洲幸运5彩票线上投注、澳洲幸运5实时开奖等服务的平台。

7 留言

  1. 皇冠会员登录线路(www.22223388.com)
    回复
    浦韦青示意,下半季现在的即战力就是陈(chen)冠宇,教练团也早早敲定他初登板“ban”时间,至于曾仁 ren[和的部门球队也有做领会,「他的整体撞框稳固,但在谈约没有新进度前,还不会约请他一起追随球队训练。」比很多都强
    1. USDT自动充提教程(www.6allbet.com)
      回复
      事〖shi〗实上,在都美竹和吴亦凡,的较量中,都美(mei)竹可以全身而退,这仍然有许多人的优点。事实一小我私人的气力挺小的,人人一起语言。那就纷歧样了。消遣必备~
  1. 新2网址(www.22223388.com)
    回复
    提起赵丽颖,信托人人对她应该都不生疏,不仅长得甜蜜可爱,让人看着就有一种亲热感,而且演技也十分出众。在《蜀山战纪》中,赵丽颖饰演玉无心一角,一身蓝色古装,搭配极具异域风情的额饰,给人一种冷艳美的感受。对这篇爱的深沉
  1. 澳洲5彩票开奖网(a55555.net)
    回复

    皇冠足球信用平台出租rent.22223388.com)皇冠运营平台(rent.22223388.com)是皇冠(正网)接入菜宝钱包的TRC20-USDT支付系统,为皇冠代理提供专业的网上运营管理系统。系统实现注册、充值、提现、客服等全自动化功能。采用的USDT匿名支付、阅后即焚的IM客服系统,让皇冠代理的运营更轻松更安全。

    有没有新人啊?
  1. 新2网址(www.22223388.com)
    回复
    贝佛利 li[是在2019年和快艇签下三年4000万美元的合约,这《zhe》份合约将在2022年炎天到期,2021-22赛季贝“bei”佛利的年薪将是1430万美元。有趣
  1. 澳洲幸运5开户(a55555.net)
    回复
    爽快,喜欢不拖的情节
  1. 皇冠登录线路网址(www.22223388.com)
    回复

    Allbet代理www.aLLbetgame.us),欧博官网是欧博集团的官方网站。欧博官网开放Allbet注册、Allbe代理、Allbet电脑客户端、Allbet手机版下载等业务。

    实力碾压别的文
  1. 皇冠足球网址(www.22223388.com)
    回复
      住手25日(ri)晚,60个国《guo》家致函世卫组织,认同第一阶段溯源研究功效,否决溯源政治化图谋。看了一点,有空继续

评论

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。
验证码