隨著技術(shù)的發(fā)展，K8s（Kubernetes）面臨的安全威脅也在快速演變。2023年涌現(xiàn)了一系列針對(duì)K8s的新型攻擊，例如Dero和Monero加密幣挖礦、猩紅鐵攻擊（Scarleteel）和RBAC-Buster攻擊等。此類攻擊通常以web應(yīng)用漏洞為入口，然后在K8s環(huán)境中橫向移動(dòng)。

在即將到來的2024年，了解這些新型攻擊對(duì)于企業(yè)云安全和數(shù)據(jù)安全防護(hù)至關(guān)重要。以下，我們將詳細(xì)介紹這些新型攻擊如何開展，以及應(yīng)采取何種防御措施：

一、猩紅鐵攻擊

猩紅鐵攻擊（Scarleteel）的入口點(diǎn)是托管在K8s環(huán)境中的Jupyter筆記本web應(yīng)用，其目標(biāo)是訪問云存儲(chǔ)中的加密敏感數(shù)據(jù)并挖掘加密貨幣。攻擊者還利用了一個(gè)名為Peirates的開源K8s滲透測(cè)試工具，以及一個(gè)名為Pacu的類似工具，用于尋找進(jìn)入AWS云環(huán)境的開放入口。

在猩紅鐵攻擊中，攻擊者能夠在云環(huán)境中“絲滑”移動(dòng)，從K8s托管的web應(yīng)用直接跳到云端，然后再回到K8s。而防御者卻往往沒有完整的攻擊鏈環(huán)境視圖，只能分別查看云安全、網(wǎng)絡(luò)應(yīng)用安全和K8s安全，然后努力拼湊整體攻擊行動(dòng)和目標(biāo)的視圖。

防御措施

如果你不使用Jupyter筆記本應(yīng)用，就不易受到此類攻擊影響。但還有許多其他可被利用的web應(yīng)用漏洞，因此，首先要確保修復(fù)可被攻擊者利用的特定云錯(cuò)誤配置。如果你運(yùn)行EKS，請(qǐng)查看IMDSv1和IMDSv2的安裝位置，并在攻擊發(fā)生之前讓藍(lán)隊(duì)用Peirates和Paco等滲透測(cè)試工具對(duì)K8s環(huán)境進(jìn)行安全評(píng)估。

運(yùn)行時(shí)功能可能會(huì)檢測(cè)到Pandora惡意軟件，但不會(huì)將它與云和K8s環(huán)境中發(fā)生的更廣泛的攻擊和活動(dòng)聯(lián)系起來，因此它無法阻止整個(gè)攻擊。

二、Dero/Monero加密幣挖礦攻擊

在Dero幣挖礦攻擊中，攻擊者首先掃描Kubernetes API，查看身份驗(yàn)證設(shè)置是否允許任何人匿名訪問，以及集群的RBAC配置是否允許在該集群中創(chuàng)建Pod。滿足這些條件后，攻擊者將部署Daemonset，利用集群中的惡意映像創(chuàng)建自己的Pod。

Monero幣挖礦攻擊的第一個(gè)步驟與Dero相同，然后，攻擊者會(huì)訪問Kubernetes API并刪除Dero Pod并通過Daemonset部署自己的特權(quán)Pod。特權(quán)Pod會(huì)嘗試掛載主機(jī)目錄以逃離容器，并下載可以隱藏礦工的rootkit。隨后，攻擊者開始在主機(jī)上安裝自定義挖礦服務(wù)。

與Dero攻擊不同，Monero挖礦攻擊涉及權(quán)限提升和容器逃逸技術(shù)，因此，特權(quán)Pod是K8s需要避免的最嚴(yán)重的安全問題之一。（由于K8s Pod安全標(biāo)準(zhǔn)的基準(zhǔn)策略不允許特權(quán)Pod，因此默認(rèn)配置下不太可能發(fā)生。）

但是，如果你運(yùn)行EKS和Kubernetes v1.13及更高版本，則默認(rèn)pod安全策略允許特權(quán)Pod。在EKS中，你必須刪除此策略才能啟用用戶自定義策略，這一額外步驟可能會(huì)增加你意外創(chuàng)建特權(quán)Pod的機(jī)會(huì)。

在Monero挖礦攻擊中，黑客利用最初的K8s錯(cuò)誤配置后會(huì)產(chǎn)生大量運(yùn)行時(shí)活動(dòng)。鎖止這些活動(dòng)可以防止惡意運(yùn)行時(shí)擴(kuò)散到其他Pod和集群。

禁止非法主機(jī)掛載路徑和錯(cuò)誤配置導(dǎo)致的特權(quán)Pod是最重要的兩個(gè)預(yù)防措施。需要注意的是，如果你的KSPM(Kubernetes安全策略管理)是輪詢間隔的，那么你可能會(huì)錯(cuò)過間隔之間的攻擊活動(dòng)。

防范措施

如果發(fā)現(xiàn)攻擊，首要任務(wù)是控制爆炸半徑，因?yàn)楣羰窃贙8s環(huán)境中實(shí)時(shí)發(fā)生的，而不是在運(yùn)行時(shí)。如果你的運(yùn)行時(shí)防護(hù)包括限制Monero幣挖礦的規(guī)則，可以阻止攻擊的最后一步，但不能阻止初始階段的入侵。

雖然大多數(shù)API設(shè)置都會(huì)禁止匿名訪問，但攻擊者往往能找到其他方式來入侵API。例如，惡意內(nèi)部人員可能會(huì)植入后門或挖礦軟件，開發(fā)人員可能無意中將服務(wù)帳戶令牌或kubeconfig文件簽入公共git存儲(chǔ)庫(kù)，從而使集群面臨風(fēng)險(xiǎn)。

最重要的保護(hù)措施是防止從Daemonsets創(chuàng)建惡意工作負(fù)載。此外，監(jiān)測(cè)工具能發(fā)揮一定防護(hù)作用，因?yàn)樵S多加密幣挖礦行為是通過監(jiān)測(cè)意外流量峰值發(fā)現(xiàn)的。

由于此類攻擊會(huì)使用鏡像創(chuàng)建惡意Pod，因此設(shè)置一個(gè)阻止從不受信任鏡像來源創(chuàng)建工作負(fù)載的準(zhǔn)入控制策略可以有效阻止攻擊。但需要注意的是，你要么必須全面執(zhí)行該策略，要么采用實(shí)時(shí)KSPM檢測(cè)解決方案來準(zhǔn)確了解問題所在，然后在修復(fù)代碼中的配置時(shí)有針對(duì)性地使用準(zhǔn)入控制器。

三、RBAC-Buster攻擊

配置錯(cuò)誤的服務(wù)器會(huì)允許特權(quán)用戶發(fā)出未經(jīng)身份驗(yàn)證的請(qǐng)求。在RBAC-Buster攻擊中，攻擊者為了在K8s環(huán)境中獲得立足點(diǎn)，會(huì)嘗試掃描配置錯(cuò)誤的API服務(wù)器，然后通過特權(quán)訪問列出機(jī)密信息并并發(fā)現(xiàn)kube-system命名空間。

攻擊者會(huì)在命名空間中創(chuàng)建了一個(gè)擁有管理權(quán)限的新ClusterRole和一個(gè)新的服務(wù)帳戶，將兩者綁定在一起以并將ClusterRole的管理權(quán)限授予服務(wù)帳戶。

攻擊者會(huì)尋找AWS密鑰來訪問云服務(wù)提供商，然后使用Daemonset部署惡意Pod，使用容器映像在整個(gè)集群中進(jìn)行加密幣挖礦。

此類攻擊的前提是：KubernetesAPI服務(wù)器不僅發(fā)生暴露，而且還接受特權(quán)用戶的請(qǐng)求。其余的攻擊都是通過這種特權(quán)訪問來進(jìn)行的。

防范措施

為了橫向傳播，攻擊者使用與Dero挖礦活動(dòng)中相同的Daemonset技術(shù)，這提醒我們要防止從Daemonsets創(chuàng)建惡意工作負(fù)載。防御者需要檢查API服務(wù)器配置并審核RBAC權(quán)限以防范此攻擊。

四、防止未來的攻擊

發(fā)現(xiàn)RBAC-Buster的團(tuán)隊(duì)表示，他們發(fā)現(xiàn)60%的暴露集群中都至少有一個(gè)活躍的攻擊活動(dòng)正在進(jìn)行（雖然這并不意味著這些集群都處于暴露狀態(tài)）。顯然，攻擊者正在積極尋找漏洞、配置錯(cuò)誤以及各種入侵K8s環(huán)境的方法。

大多數(shù)K8s集群都是“臨時(shí)集群”，可訪問時(shí)間窗口僅有數(shù)小時(shí)。今天的漏洞和暴露也許明天就會(huì)對(duì)攻擊者關(guān)閉。這也意味著如果你使用的輪詢間隔無法隨著時(shí)間的推移顯示這些變化，緩解措施將是一場(chǎng)噩夢(mèng)。

在下一波攻擊到來之前，如果你僅依賴準(zhǔn)入控制或運(yùn)行時(shí)事件的逆向工程檢測(cè)，可能會(huì)導(dǎo)致無法檢測(cè)威脅，或者檢測(cè)太慢。你需要一個(gè)實(shí)時(shí)的、綜合的K8s風(fēng)險(xiǎn)視圖。

最后，雖然縱深防御是K8s的最佳安全實(shí)踐方法，但如果縱深防御不能提供所有協(xié)作組件的綜合視圖，防御者仍然會(huì)落后于攻擊者一步。