從零開始的 Kubernetes 攻防指南

測試環(huán)境建議：測試環(huán)境的所有問題錢都能解決，我們可以直接在云廠商上購買一個(gè)包含多節(jié)點(diǎn)的 Kubernetes 容器集群；但如果只有一臺(tái) VPS 服務(wù)器或配置有限的虛擬機(jī)環(huán)境，那么我建議可以使用 minikube、kind 或 K3s 等工具來搭建一個(gè) Kubernetes 容器集群進(jìn)行測試。

注：本材料所有內(nèi)容僅供安全研究和企業(yè)安全能力建設(shè)參考，請勿用于未授權(quán)滲透測試和惡意入侵攻擊。

CNCF 在對云原生定義的描述中提到云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式 API。

我們今天所聊到的漏洞和利用手法也緊緊圍繞著上述的幾類技術(shù)和由云原生相關(guān)技術(shù)所演化出來的多種技術(shù)架構(gòu)進(jìn)行，包括但不限于容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施、聲明式 API、無服務(wù)架構(gòu)、函數(shù)計(jì)算、DevOps 等，并涉及研發(fā)團(tuán)隊(duì)在使用的一些云原生開源組件和自研、二次開發(fā)時(shí)常見的安全問題。不在 “云原生安全” 這個(gè)概念上做過多的延伸和擴(kuò)展，且提及所有的安全漏洞都在 “騰訊藍(lán)軍” 對內(nèi)對外的攻防演練和漏洞挖掘中有實(shí)際的利用經(jīng)驗(yàn)積累。

在實(shí)際的攻防中我們所進(jìn)行的攻擊路徑并非完全契合在 CIS2020 上總結(jié)的攻擊模型：

因?yàn)榇蟛糠智闆r下我們遇到的內(nèi)網(wǎng)并非完全基于容器技術(shù)所構(gòu)建的，所以內(nèi)網(wǎng)的起點(diǎn)并不一定是一個(gè)權(quán)限受限的容器，但攻擊的方向和目標(biāo)卻大同小異：為了獲取特定靶標(biāo)的權(quán)限、資金和數(shù)據(jù)，我們一般需要控制更多乃至全部的容器、主機(jī)和集群。

也由于業(yè)界云原生實(shí)踐的發(fā)展非常迅速，雖然進(jìn)入內(nèi)網(wǎng)之后我們所接觸的不一定是全是 Kubernetes 所編排下的容器網(wǎng)絡(luò)和架構(gòu)，但基于云原生技術(shù)所產(chǎn)生的新漏洞和利用手法往往能幫藍(lán)軍打開局面。

舉個(gè)例子，當(dāng)我們通過遠(yuǎn)控木馬獲取某個(gè)集群管理員 PC 上的 kubeconfig 文件 （一般位于 ~/.kube/config 目錄），此時(shí)我們就擁有了管理 Kubernetes 集群的所有能力了，具體能做的事情后面會(huì)有更詳細(xì)的探討。

如果此時(shí)該集群沒有設(shè)置嚴(yán)格的 security policy 且目標(biāo)企業(yè)的 HIDS 沒有針對容器特性進(jìn)行一定策略優(yōu)化的話，那創(chuàng)建一個(gè)能獲取 NODE 權(quán)限的 POD 或許就是一個(gè)不錯(cuò)的選擇，因?yàn)橹挥羞@樣獲取的 shell 才能更方便的在容器母機(jī)上進(jìn)行信息收集，例如 strace 母機(jī) sshd 進(jìn)程抓取我們想要的用戶名和密碼、使用 tcpdump 抓取內(nèi)網(wǎng)系統(tǒng)的管理員登錄態(tài)等，目前正在運(yùn)行的容器一般是沒有這些權(quán)限的。

以下是這種情況下我們常用的 POD yaml 配置：

如果對 Kubernetes 的 POD 不熟悉，其實(shí)上述的配置就比較類似于在想要 ROOT 權(quán)限的業(yè)務(wù)服務(wù)器上執(zhí)行以下 docker 命令:

docker?-H?${host_docker_sock}?run?-d?-it?--name?neartest_Kubernetes_hashsubix?-v?"/proc:/host/proc"?-v?"/sys:/host/sys"?-v?"/:/near_sandbox"?--network=host?--privileged=true?--cap-add=ALL?alpine:latest?/bin/sh?-c?tail?-f?/dev/null

執(zhí)行的結(jié)果和作用如下 (注：所有的掛載和選項(xiàng)并非都必須，實(shí)戰(zhàn)中填寫需要的權(quán)限和目錄即可，此處提供一個(gè)較全的參考)：

當(dāng)然上述大部分配置都會(huì)被多租戶集群下的 Kubernetes Security Policy 所攔截，且如果目前主機(jī)上的 HIDS 有一定容器安全能力的話，這類配置的容器創(chuàng)建行為也比較容易會(huì)被標(biāo)記為異常行為。

不過，顯然我們在真實(shí)的對抗中如果只是想達(dá)到執(zhí)行 strace 抓取 sshd 的目的，配置可以更加簡化一點(diǎn)，只需添加 SYS_PTRACE 的 capabilities 即可，我在演習(xí)中也正是這么做的。

因?yàn)榫哂?SYS_PTRACE 權(quán)限的容器并且進(jìn)行 kubectl exec 的行為在實(shí)際的研發(fā)運(yùn)維流程中非常常見，是 HIDS 比較不容易察覺的類業(yè)務(wù)型操作；另外也可以尋找節(jié)點(diǎn)上已有該配置的容器和 POD 進(jìn)行控制，同樣是不易被防御團(tuán)隊(duì)所察覺的。

接下來我們也會(huì)一個(gè)個(gè)討論這類漏洞和手法和我們實(shí)際在對抗中遇到的場景。同時(shí)，無論是在 CNCF 對云原生的定義里，還是大家對云原生技術(shù)最直觀的感受，大部分技術(shù)同學(xué)都會(huì)想到容器以及容器編排相關(guān)的技術(shù)，這里我們就以容器為起始，開啟我們今天的云原生安全探索之旅吧~，目錄如下所示：

完整的指南請參考 Git 倉庫地址 https://github.com/neargle/my-re0-k8s-security 了解更多信息。