AzureScape：ACI 容器中的 K8s 跨賬戶集群接管研究

0x01 漏洞描述

Azure 容器實(shí)例 ( ACI ) 是 Azure 的容器即服務(wù) ( CaaS ) 產(chǎn)品，ACI ) 使客戶能夠在 Azure 中運(yùn)行容器而無需管理底層服務(wù)器。最近有研究人員發(fā)現(xiàn)并向 Microsoft 披露了 ACI 中的安全漏洞。惡意的 Azure 用戶可能會(huì)利用這些問題逃逸到其他用戶的容器上執(zhí)行代碼，竊取部署到平臺(tái)的客戶敏感文件，并可能濫用 ACI 的基礎(chǔ)設(shè)施進(jìn)行挖礦。研究人員將該漏洞命名為 Azurescape ——公有云中的跨賬戶容器逃逸接管漏洞。

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

Azurescape 允許惡意用戶破壞托管 ACI 的多租戶 Kubernetes 集群，建立對(duì)其他用戶容器的完全控制。這篇文章描述了研究過程、漏洞分析，并提出了保護(hù) Kubernetes 的措施，重點(diǎn)是多租戶防止類似攻擊的緩解措施。

微軟在我們披露后不久修補(bǔ)了 ACI，現(xiàn)在還不知道 Azurescape 是否被在野利用。

0x02 Azure 容器實(shí)例

Azure 容器實(shí)例 ( ACI ) 于 2017 年 7 月發(fā)布，是大型云提供商提供的第一個(gè)容器即服務(wù) ( CaaS ) 產(chǎn)品。借助 ACI，客戶無需管理底層基礎(chǔ)結(jié)構(gòu)即可將容器部署到 Azure。ACI 負(fù)責(zé)擴(kuò)展、請(qǐng)求路由和調(diào)度，為容器提供無服務(wù)器體驗(yàn)。

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

Azure 官網(wǎng)對(duì) ACI 的描述如下：" 無需管理虛擬機(jī)或?qū)W習(xí)新工具即可快速開發(fā)應(yīng)用程序，它只是在容器中、在云中運(yùn)行的程序。"

在集群內(nèi)部，ACI 托管在客戶容器的多租戶集群上。剛開始是使用 Kubernetes 集群，在過去的一年里，微軟也開始在 Service Fabric 集群上托管 ACI。此處的漏洞會(huì)影響 Kubernetes 上的 ACI，本文的其余部分將僅參考該架構(gòu)。根據(jù)我們的測(cè)試，我們?cè)谄脚_(tái)上部署了數(shù)千個(gè)容器，在披露時(shí) Kubernetes 托管了大約 37% 的 ACI 新創(chuàng)建的容器。

該圖說明了托管在多租戶 Kubernetes 群集上的 Azure 容器實(shí)例，顯示了主節(jié)點(diǎn)上的 api 服務(wù)器如何與為三個(gè)不同客戶運(yùn)行的三個(gè)工作節(jié)點(diǎn)相關(guān)聯(lián)。 租戶邊界用紅色虛線表示。

圖 1. 托管在多租戶 Kubernetes 集群上的 ACI。

在 ACI 等多租戶環(huán)境中，你需要在租戶之間實(shí)施強(qiáng)邊界。在 ACI 中，該邊界是節(jié)點(diǎn)虛擬機(jī)。每個(gè)客戶容器都在專用的單租戶節(jié)點(diǎn)上的 Kubernetes pod 中運(yùn)行。這種 Kubernetes 多租戶方法通常稱為 node-per-tenant。

0x03 AzureScape 攻擊場(chǎng)景

ACI 會(huì)防止相鄰容器的惡意攻擊。由于幾乎任何人都可以將容器部署到平臺(tái)上，因此 ACI 必須確保惡意容器不會(huì)進(jìn)行破壞、泄漏信息、執(zhí)行代碼或以其他方式影響其他客戶的容器，這種攻擊影響就是跨賬戶或跨租戶攻擊。

Azure 容器實(shí)例中的跨賬戶攻擊場(chǎng)景圖解，展示了惡意客戶如何占用工作節(jié)點(diǎn)。

圖 2. 跨賬戶攻擊場(chǎng)景。

以下部分涵蓋了我們對(duì) ACI 中跨賬戶攻擊的研究。我們發(fā)現(xiàn)了一種跨租戶攻擊，惡意的 Azure 用戶可以通過這種攻擊進(jìn)行容器逃逸，獲取特權(quán) Kubernetes 服務(wù)帳戶令牌并接管 Kubernetes api-server，從而建立對(duì)多租戶集群和在其中運(yùn)行的所有客戶容器的完全控制。

0x04 ACI 容器逃逸

CaaS 產(chǎn)品很難研究。用戶只暴露了他們的容器環(huán)境，并且通過防火墻禁止訪問本地網(wǎng)絡(luò)。為了更好地了解 CaaS 平臺(tái)如何運(yùn)行我們的容器，我們創(chuàng)建了 WhoC。WhoC 是一個(gè)容器鏡像，它可以讀取執(zhí)行它的容器 runtime，基于 Linux 容器中一個(gè)很少討論的設(shè)計(jì)缺陷，允許它們讀取底層主機(jī)的容器 runtime。這個(gè)想法與 CVE-2019-5736 非常相似，不同之處在于 CVE-2019-5736 是讀取 runtime，它 WhoC 是覆蓋主機(jī)的 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，我們能夠檢索平臺(tái)中使用的容器 runtime。不出所料，我們發(fā)現(xiàn)了行業(yè)標(biāo)準(zhǔn)容器 runtime runC。

https://github.com/opencontainers/runc

讓我們措手不及的是 runC 的版本，如圖 3 所示。

屏幕截圖顯示了在 2016 年 10 月 1 日發(fā)布的 runC v1.0.0-rc2 上運(yùn)行的 Azure 容器實(shí)例。

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

RunC v1.0.0-rc2 于 2016 年 10 月 1 日發(fā)布，并且容易受到至少兩個(gè)容器逃逸漏洞的攻擊。

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

ACI 中存在這個(gè)舊版本的 runC，使用這個(gè)容器映像對(duì)其進(jìn)行優(yōu)化并將其部署到 ACI。通過 cve-2019-5736 成功突破容器，并獲得了一個(gè)在底層主機(jī)上以 root 身份運(yùn)行的反向 shell，主機(jī)是一個(gè) Kubernetes 節(jié)點(diǎn)（Node）。

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

一旦我們發(fā)現(xiàn) ACI 中存在這個(gè)舊版本的 runC，我們就采用了當(dāng)時(shí)開發(fā)的 PoC 容器映像，對(duì)其進(jìn)行了優(yōu)化并將其部署到 ACI。 我們成功地突破了容器，并獲得了一個(gè)在底層主機(jī)上以 root 身份運(yùn)行的反向 shell，結(jié)果證明它是一個(gè) Kubernetes 節(jié)點(diǎn)。 在這里，我們展示了利用 CVE-2019-5736 來逃避我們的 ACI 容器的過程的屏幕截圖。

圖 4. 利用 CVE-2019-5736 來逃逸 ACI 容器。

雖然實(shí)現(xiàn)了容器逃逸，但仍然在租戶邊界內(nèi)—— VM 節(jié)點(diǎn) 。CaaS 平臺(tái)可以抵御復(fù)雜的攻擊者，這些攻擊者可以通過內(nèi)核漏洞實(shí)現(xiàn)權(quán)限提升和容器逃逸。

該圖顯示了租戶邊界如何防范惡意客戶。 雖然我們逃離了我們的容器，但我們?nèi)匀辉谧鈶暨吔鐑?nèi)——節(jié)點(diǎn) VM。 CaaS 平臺(tái)旨在抵御復(fù)雜的攻擊者，這些攻擊者擁有內(nèi)核漏洞，可實(shí)現(xiàn)權(quán)限提升和容器突破。 惡意容器爆發(fā)是一種預(yù)期的威脅，通過節(jié)點(diǎn)級(jí)隔離可以容忍。

圖 5. 獲取節(jié)點(diǎn)權(quán)限后任然在 node 中。

0x05 探測(cè) K8s 節(jié)點(diǎn)環(huán)境

探測(cè)掃描節(jié)點(diǎn)可以驗(yàn)證當(dāng)前容器是唯一的客戶容器。使用 Kubelet 憑據(jù)，我們列出了集群中的 pod 和節(jié)點(diǎn)。該集群托管了大約 100 個(gè)客戶 pod，擁有大約 120 個(gè)節(jié)點(diǎn)。每個(gè)客戶都被分配了一個(gè) Kubernetes 命名空間，他們的 pod 在其中運(yùn)行；我們的容器 ID 是 caas-d98056cf86924d0fad1159XXXXXXXXXX。

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

可以看到節(jié)點(diǎn)的 Kubelet 允許匿名訪問，嘗試訪問相鄰節(jié)點(diǎn)上的 Kubelet。所有嘗試訪問相鄰節(jié)點(diǎn)的請(qǐng)求都超時(shí)了，可能是由于防火墻配置阻止了工作節(jié)點(diǎn)之間的通信。

節(jié)點(diǎn)在 kubernetes.azure.com/cluster 標(biāo)簽中引用了集群名稱，格式如下：CAAS-PROD-< LOCATION >-LINUX-< ID >。

圖 6. 集群名稱。

我們部署了幾個(gè)分支容器，它們?cè)诓煌?Kubernetes 集群節(jié)點(diǎn)上。發(fā)現(xiàn)每個(gè)集群節(jié)點(diǎn)都有唯一的集群 ID，范圍在 1-125 之間。這些集群 ID 表明托管了幾十個(gè)集群節(jié)點(diǎn)。

1.Kubernetes 1 day

接下來，我們檢查了集群的 Kubernetes 版本。

Azure 容器實(shí)例托管在運(yùn)行 Kubernetes v1.8.4、v1.9.10 或 v1.10.9 的群集上，如下所示。 這些版本于 2017 年 11 月至 2018 年 10 月期間發(fā)布，容易受到多個(gè)已知漏洞的攻擊。

圖 7. ACI Kubernetes 版本。

ACI 托管在運(yùn)行 Kubernetes v1.8.4、v1.9.10 或 v1.10.9 的集群上。這些版本于 2017 年 11 月至 2018 年 10 月期間發(fā)布，容易受到多個(gè)已知漏洞的攻擊。運(yùn)行較舊的 Kubernetes 版本有較大的風(fēng)險(xiǎn)，但它不一定會(huì)導(dǎo)致 ACI 中的安全問題。

回顧過去的 Kubernetes 漏洞，尋找可以通過被控節(jié)點(diǎn)提升權(quán)限或訪問其他節(jié)點(diǎn)的漏洞，目標(biāo)鎖定： CVE-2018-1002102。

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

2.Kubernetes CVE-2018-1002102

當(dāng)為 kubectl exec < pod > < cmd >命令提供服務(wù)時(shí)，api-server 會(huì)將請(qǐng)求推遲到適當(dāng)?shù)?Kubelet 的 / exec 端點(diǎn)。

CVE-2018-1002102 是 api-server 與 Kubelets 通信中存在的漏洞，可以實(shí)現(xiàn)重定向。通過將 api-server 的請(qǐng)求重定向到另一個(gè)節(jié)點(diǎn)的 Kubelet，惡意 Kubelet 命令可以在集群中傳播。圖 8 展示了漏洞的基本流程：

CVE-2018-1002102 的基本流程：1 ) 由 api-server 服務(wù)的命令，2 ) api-server 將請(qǐng)求延遲到適當(dāng)?shù)亩它c(diǎn)，3 ) 302 重定向，4 ) 通過集群傳播。

圖 8. CVE-2018-1002102 利用流程。

漏洞利用前提條件：

存在漏洞的 api-server 版本：

獲取一個(gè)節(jié)點(diǎn)權(quán)限：

通過 api-server 可以使被控節(jié)點(diǎn)與其他節(jié)點(diǎn)通信。例如，可以通過向被控節(jié)點(diǎn)上的 pod 發(fā)出 kubectl exec 來完成。

事實(shí)證明，ACI 滿足第三個(gè)前提條件。ACI 支持通過鏡像 kubectl exec 的 az container exec 命令在上傳的容器上執(zhí)行命令。

az container exec --name --exec-command

創(chuàng)建一個(gè)利用 CVE-2018-1002102 的自定義 Kubelet 映像，將傳入的 exec 請(qǐng)求重定向到其他節(jié)點(diǎn)上的 pod。為了最大限度地發(fā)揮作用，將其配置為以 api-server pod 為目標(biāo)，最后，運(yùn)行 az container exec my-ctr --exec-command /bin/bash，希望能在 api-server 容器上建立一個(gè) shell。

執(zhí)行命令失敗了，經(jīng)過一些調(diào)試，我們注意到重定向操作僅在目標(biāo)容器托管在同一節(jié)點(diǎn)上時(shí)才有效。這有效地消除了攻擊，因?yàn)槲覀儫o法傳播到其他節(jié)點(diǎn)。分析 CVE-2018-1002102 的補(bǔ)丁，確實(shí)對(duì)該漏洞的修復(fù)。

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

重新檢查到達(dá)節(jié)點(diǎn)的 exec 請(qǐng)求，請(qǐng)求可能會(huì)從 api-server IP 到達(dá)，如圖 8 所示。但是，求來自在默認(rèn)命名空間中運(yùn)行的 "bridge" pod。

重新檢查到達(dá)節(jié)點(diǎn)的 exec 請(qǐng)求后發(fā)現(xiàn)，這些請(qǐng)求源自在默認(rèn)命名空間中運(yùn)行的被稱為 " 網(wǎng)橋 " 的 pod，如圖所示。

圖 9.az container exec 會(huì)話期間的 Kubelet 連接。

我們發(fā)現(xiàn) ACI 將 exec 請(qǐng)求的處理從 api-server 轉(zhuǎn)移到自定義服務(wù)。這可能是通過將 az 容器 exec 命令路由到橋接容器而不是 api-server 來實(shí)現(xiàn)的。

我們發(fā)現(xiàn) ACI 將 exec 請(qǐng)求的處理從 api-server 轉(zhuǎn)移到自定義服務(wù)。 這可能是通過將 az 容器 exec 命令路由到橋接容器而不是 api-server 來實(shí)現(xiàn)的。

圖 10. Bridge Pod 處理 ACI 中的執(zhí)行程序。

網(wǎng)橋鏡像標(biāo)簽是 master_20201125.1，表明它是在 CVE-2018-1002102 之后更新的。從其最近的構(gòu)建時(shí)間和拒絕重定向 exec 請(qǐng)求來看，似乎 CVE-2018-1002102 的補(bǔ)丁已經(jīng) patch 到了 bridge 上。微軟應(yīng)該是注意到了此漏洞影響了他們的自定義網(wǎng)橋 Pod 并進(jìn)行了修補(bǔ)。

值得一提的是，CVE-2018-1002102 也可以在其他情況下被利用，例如，當(dāng)客戶端要求惡意 Kubelet 檢索容器日志（例如 kubectl 日志）時(shí)。這實(shí)際上與 ACI 相關(guān)，其中此功能是通過 az container logs 命令實(shí)現(xiàn)的。但與 exec 請(qǐng)求一樣，ACI 將日志檢索的處理推遲到適當(dāng)?shù)?log-fetch 專用 pod 上 。與 Bridge Pod 一樣，CVE-2018-1002102 的修復(fù)程序也被移植到 log-fetch Pod，以防止被利用。

0x06 獲取集群管理員權(quán)限

CVE-2018-1002102 不在討論范圍內(nèi)，但我們?cè)谡{(diào)試漏洞利用時(shí)確實(shí)注意到了一些奇怪的事情。到達(dá)節(jié)點(diǎn)的 exec 請(qǐng)求包含一個(gè) Authorization Header 頭，其中包含一個(gè) Kubernetes 服務(wù)帳戶令牌，如圖 11 所示。

到達(dá)節(jié)點(diǎn)的 exec 請(qǐng)求包含一個(gè) Authorization 標(biāo)頭，其中包含一個(gè) Kubernetes 服務(wù)帳戶令牌，如圖所示。

圖 11. Bridge 發(fā)送帶有服務(wù)帳戶令牌的 "exec" 請(qǐng)求。

在這里找到令牌令人驚訝。如前所述，集群中的 Kubelet 被配置為允許匿名訪問，因此請(qǐng)求不需要通過令牌進(jìn)行身份驗(yàn)證，也許是舊版本中遺留的令牌。

Kubernetes 服務(wù)帳戶令牌是未加密的 JSON Web 令牌 ( JWT ) ，因此它們是可解碼的。如下所示，接收到的令牌是 "bridge" 服務(wù)帳戶的服務(wù)帳戶令牌?？紤]到來自橋接 Pod 的請(qǐng)求，這是有道理的。

https://jwt.io/

收到的令牌是 " 網(wǎng)橋 " 服務(wù)帳戶的服務(wù)帳戶令牌。 考慮到來自橋接 Pod 的請(qǐng)求，這是有道理的。

圖 12. 已解碼的橋接服務(wù)帳戶令牌。

如果你要運(yùn)行 Kubernetes，一定要注意要將服務(wù)帳戶令牌發(fā)送給誰：任何收到令牌的人都可以自由使用它并偽裝成其所有者。令牌竊取者很可能對(duì)他們被盜令牌的權(quán)限非常感興趣。api-server 公開了兩個(gè)允許客戶端查詢其權(quán)限的 API，SelfSubjectAccessReview 和 SelfSubjectRulesReview。kubectl 提供了 kubectl auth can-i 作為訪問這些 API 的便捷方式。

以下是默認(rèn)命名空間中 "Bridge" 令牌的權(quán)限：

這顯示了默認(rèn)命名空間中 " 橋 " 令牌的權(quán)限。

圖 13. 橋接令牌權(quán)限——默認(rèn)命名空間。

查看其他命名空間，權(quán)限是一致的，表明它們是集群范圍的（而不是命名空間范圍的）。以下是 kube-system 命名空間中令牌的權(quán)限。嘗試確定允許我們?cè)诙嘧鈶艏褐袀鞑サ臋?quán)限：

這顯示了 kube-system 命名空間中令牌的權(quán)限，包括 pods/exec 權(quán)限，表明令牌可用于在集群中的任何 Pod 上執(zhí)行命令。

圖 14. 橋接令牌權(quán)限 - kube-system 命名空間。

經(jīng)驗(yàn)豐富的 Kubernetes 安全人員可能已經(jīng)確定了 pods/exec 權(quán)限，這表明該令牌可用于在集群中的任何 pod 上執(zhí)行命令——包括 api-server pod！圖 15 顯示了在 api-server 容器上打開 shell 的令牌：

這顯示了在 api-server 容器上打開 shell 的令牌。

圖 15. 使用網(wǎng)橋的令牌在 api-server 上彈出一個(gè) shell。

我們剛剛完成了一次跨賬戶攻擊。通過在 api 服務(wù)器上執(zhí)行代碼，我們現(xiàn)在是集群管理員了，可以完全控制多租戶集群和其中的所有客戶容器 : )

0x07 Azurescape 攻擊總結(jié)

讓我們總結(jié)一下惡意 Azure 客戶可能通過托管 ACI 的多租戶 Kubernetes 集群獲得管理權(quán)限的步驟：

將利用 CVE-2019-5736 的鏡像部署到 ACI。惡意鏡像在執(zhí)行時(shí)在底層節(jié)點(diǎn)上實(shí)現(xiàn)逃逸代碼執(zhí)行。

在節(jié)點(diǎn)上，監(jiān)聽 Kubelet 端口 10250 上的流量，并等待在 Authorization 標(biāo)頭中包含 JWT 令牌的請(qǐng)求。

發(fā)出 az container exec 以在上傳的容器上運(yùn)行命令。橋接 Pod 將向受感染節(jié)點(diǎn)上的 Kubelet 發(fā)送 exec 請(qǐng)求。

在節(jié)點(diǎn)上，從請(qǐng)求的 Authorization 標(biāo)頭中提取橋接令牌，并使用它在 api-server 上獲取 shell。

以下視頻演示了該攻擊：

https://youtu.be/YfZBwKP18CQ

惡意 Azure 用戶可以破壞托管 ACI 的多租戶 Kubernetes 集群。作為集群管理員，攻擊者可以在其他客戶容器中執(zhí)行命令、泄露部署到平臺(tái)的敏感信息和私有映像，或者部署加密挖礦程序。

0x08 獲取 Cluster 權(quán)限的另一種方法：Bridge SSRF

某些功能僅在 Kubernetes 上受支持，例如 gitRepo volume。如果 ACI 容器使用了此類功能，并且它部署在 Kubernetes 集群上，這意味著其他容器可能會(huì)控制 Kubernetes。私有虛擬網(wǎng)絡(luò)中的容器就是這種情況。

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

我們發(fā)現(xiàn)的第二個(gè)問題是網(wǎng)橋 Pod 中的服務(wù)器端請(qǐng)求偽造 ( SSRF ) 漏洞。

當(dāng)橋接 Pod 為 az 容器 exec< ctr > < cmd >命令提供服務(wù)時(shí)，它會(huì)向相應(yīng)的 Kubelet 的 /exec 端點(diǎn)發(fā)送請(qǐng)求。橋接器根據(jù) Kubelet 的 /exec 端點(diǎn)的 API 規(guī)范構(gòu)造請(qǐng)求，生成以下 URL：

https://< nodeIP >:10250/exec///?command=&error=1&input=1&output=1&tty=1

Bridge 必須以某種方式填充 中缺少的參數(shù)，< nodeIP >的值是從客戶 pod 的 status.hostIP 字段中檢索到的。發(fā)現(xiàn)這一點(diǎn)非常有趣，因?yàn)楣?jié)點(diǎn)有權(quán)更新其 pod 的狀態(tài)（例如，為了將其 pod 的 status.state 字段更新為 Running、Terminated 等）。

我嘗試使用受感染節(jié)點(diǎn)的憑據(jù)更改 pod 的 status.hostIP 字段，確實(shí)起作用了，但在一兩秒鐘后，api-server 將 hostIP 字段更正為其原始值。盡管更改沒有持續(xù)存在，但我們可以重復(fù)更新此字段。

我們編寫了一個(gè)小腳本來反復(fù)更新 pod 的狀態(tài)，并使用它來將 status.hostIP 字段設(shè)置為 1.1.1.1。然后發(fā)送了一個(gè) az container exec 命令。命令執(zhí)行失敗，驗(yàn)證網(wǎng)橋?qū)?exec 請(qǐng)求發(fā)送到 1.1.1.1 而不是真實(shí)節(jié)點(diǎn) IP。我們開始考慮哪些特制的 hostIP 可以誘使網(wǎng)橋在其他 pod 上執(zhí)行命令。

簡(jiǎn)單地將 pod 的 status.hostIP 設(shè)置為另一個(gè)節(jié)點(diǎn)的 IP 也沒有成功。Kubelets 只接受指向它們托管的容器的請(qǐng)求，即使 Bridge 將 exec 請(qǐng)求發(fā)送到另一個(gè) Kubelet 的 IP，URL 仍將指向我們的命名空間、pod 名稱和容器名稱。

然后我們意識(shí)到 api-server 實(shí)際上并沒有驗(yàn)證 status.hostIP 值是否是一個(gè)有效的 IP，并且會(huì)接受任何字符串——包括 URL 組件。經(jīng)過幾次嘗試，我們想出了一個(gè) hostIP 值，它會(huì)誘使網(wǎng)橋在 api-server 容器而不是我們的容器上執(zhí)行命令：

:10250/exec/kube-system//?command=&error=1&input=1&output=1&tty=1#

此 hostIP 值將導(dǎo)致網(wǎng)橋?qū)?exec 請(qǐng)求發(fā)送到以下 URL：

https:// :10250/exec/kube-system//?command=&error=1&input=1&output=1&tty=1 # :10250/exec///?command=&error=1&input=1&output=1&tty=1

我們將 pod 的 status.hostIP 設(shè)置為此值并通過 az container exec 執(zhí)行命令。攻擊成功了！我們拿到的不是容器的 shell，而是 api-server 容器的 shell。完整的攻擊可以在以下視頻中看到：

https://youtu.be/7Alea_9oZgU

欺騙 Bridge 打開 api-server 上的 shell。

這里的影響與之前的攻擊完全相同——對(duì)多租戶集群的完全管理控制。

0x09 研究總結(jié)

跨賬戶漏洞是公有云的 " 噩夢(mèng) "。Azurescape 證明它們比我們想象的更真實(shí)。云提供商在保護(hù)他們的平臺(tái)方面投入了大量資金，但不可避免地會(huì)存在未知的 0 day 漏洞并使用戶面臨風(fēng)險(xiǎn)。云用戶應(yīng)該對(duì)云安全采取深度防御方法，以確保控制和檢測(cè)漏洞，無論威脅來自外部還是來自平臺(tái)本身。