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

在即將到來的2024年，了解這些新型攻擊對于企業云安全和數據安全防護至關重要。以下，我們將詳細介紹這些新型攻擊如何開展，以及應采取何種防御措施：

一、猩紅鐵攻擊

猩紅鐵攻擊（Scarleteel）的入口點是托管在K8s環境中的Jupyter筆記本web應用，其目標是訪問云存儲中的加密敏感數據并挖掘加密貨幣。攻擊者還利用了一個名為Peirates的開源K8s滲透測試工具，以及一個名為Pacu的類似工具，用于尋找進入AWS云環境的開放入口。

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

防御措施

如果你不使用Jupyter筆記本應用，就不易受到此類攻擊影響。但還有許多其他可被利用的web應用漏洞，因此，首先要確保修復可被攻擊者利用的特定云錯誤配置。如果你運行EKS，請查看IMDSv1和IMDSv2的安裝位置，并在攻擊發生之前讓藍隊用Peirates和Paco等滲透測試工具對K8s環境進行安全評估。

運行時功能可能會檢測到Pandora惡意軟件，但不會將它與云和K8s環境中發生的更廣泛的攻擊和活動聯系起來，因此它無法阻止整個攻擊。

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

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

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

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

但是，如果你運行EKS和Kubernetes v1.13及更高版本，則默認pod安全策略允許特權Pod。在EKS中，你必須刪除此策略才能啟用用戶自定義策略，這一額外步驟可能會增加你意外創建特權Pod的機會。

在Monero挖礦攻擊中，黑客利用最初的K8s錯誤配置后會產生大量運行時活動。鎖止這些活動可以防止惡意運行時擴散到其他Pod和集群。

禁止非法主機掛載路徑和錯誤配置導致的特權Pod是最重要的兩個預防措施。需要注意的是，如果你的KSPM(Kubernetes安全策略管理)是輪詢間隔的，那么你可能會錯過間隔之間的攻擊活動。

防范措施

如果發現攻擊，首要任務是控制爆炸半徑，因為攻擊是在K8s環境中實時發生的，而不是在運行時。如果你的運行時防護包括限制Monero幣挖礦的規則，可以阻止攻擊的最后一步，但不能阻止初始階段的入侵。

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

最重要的保護措施是防止從Daemonsets創建惡意工作負載。此外，監測工具能發揮一定防護作用，因為許多加密幣挖礦行為是通過監測意外流量峰值發現的。

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

三、RBAC-Buster攻擊

配置錯誤的服務器會允許特權用戶發出未經身份驗證的請求。在RBAC-Buster攻擊中，攻擊者為了在K8s環境中獲得立足點，會嘗試掃描配置錯誤的API服務器，然后通過特權訪問列出機密信息并并發現kube-system命名空間。

攻擊者會在命名空間中創建了一個擁有管理權限的新ClusterRole和一個新的服務帳戶，將兩者綁定在一起以并將ClusterRole的管理權限授予服務帳戶。

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

此類攻擊的前提是：KubernetesAPI服務器不僅發生暴露，而且還接受特權用戶的請求。其余的攻擊都是通過這種特權訪問來進行的。

防范措施

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

四、防止未來的攻擊

發現RBAC-Buster的團隊表示，他們發現60%的暴露集群中都至少有一個活躍的攻擊活動正在進行（雖然這并不意味著這些集群都處于暴露狀態）。顯然，攻擊者正在積極尋找漏洞、配置錯誤以及各種入侵K8s環境的方法。

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

在下一波攻擊到來之前，如果你僅依賴準入控制或運行時事件的逆向工程檢測，可能會導致無法檢測威脅，或者檢測太慢。你需要一個實時的、綜合的K8s風險視圖。

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