前言

攻擊者視角聊聊K8S叢集安全（上）中總結了在 K8S 叢集中對 K8S 元件、節點對外服務、業務 pod 的攻擊方法，以及容器逃逸的方法，對應圖1的攻擊點1~7。本篇將繼續介紹圖 1 中攻擊點 8~12，即橫向攻擊、對K8S管理平臺的攻擊、對映象庫的攻擊以及對第三方元件的攻擊。

圖1- K8S 叢集攻擊點

K8S 叢集攻擊點（8~12）

攻擊點8~9：橫向攻擊

1 攻擊其他服務

叢集中往往會有一些透過 ClusterIP 暴露在內部的 Service，這些服務在叢集外部是掃描不到的，但是在內部pod中透過前文提到的資訊蒐集方法就有可能發現一些敏感服務，比如透過掃描埠或檢視環境變數等。

早些時候，我們在一次內部滲透測試中就在目標 pod 的環境變數中發現了 mysql服務的地址，如圖2：

圖2-pod 環境變數中的 Mysql 資訊

並透過嘗試弱口令成功登入了 mysql 資料庫：

圖3-弱口令登入 Mysql 資料庫

2 攻擊API Server

K8S叢集的 pod 和 API Server 通訊是透過 ServiceAccount 的 token 驗證身份的，這裡存在一個攻擊點就是如果 pod 的 ServiceAccount 許可權過大，便可以以高許可權和 API Server 通訊，則有可能檢視叢集的一些敏感資訊或者執行高許可權操作，甚至進一步控制叢集。

token 預設儲存在 pod的 /run/secrets/kubernetes.io/serviceaccount/token 檔案，在實際攻擊中，API Server 的地址一般可以在 pod 內透過環境變數直接檢視，如圖 4：

圖4-pod 環境變數中的 API Server 資訊

說到內網 ip 地址，另外補充一下，如果要在 pod 內攻擊當前節點的 kubelet，ip 地址一般可以直接用 docker0 網橋的 ip：172.17.0.1。圖5演示了在 pod 內訪問當前節點 kubelet 的 10250 埠：

圖5-pod 內訪問當前節點 kubelet 的 10250 埠

3 中間人攻擊

中間人攻擊是一種經典的攻擊方式，我們知道在 K8S 叢集中 pod 之間也需要透過網路外掛如 Flannel、Calico 和 Cilium 等實現網路通訊，那麼 K8S 叢集內部的網路通訊有沒有可能存在中間人攻擊呢？答案是有可能的。

在預設配置下的 K8S 叢集中，如果攻擊者拿到了某個 pod 的許可權，接下來就有可能透過中間人攻擊，對其他 pod 實現 DNS 劫持[1]。

另外，早些年 K8S 也曝出過中間人攻擊的漏洞，比如CVE-2020-8554、CVE-2020-10749。

攻擊點10：攻擊 K8S 管理平臺

除了官方推出的 Dashboard，還有很多 K8S 管理平臺，比如 Rancher、KubeSphere、KubeOperator 等，K8S 管理平臺可攻擊的點除了最常見的Dashboard 未授權訪問，還有弱口令登入。

如圖6是 Rancher 的管理介面，若透過弱口令成功登入到管理後臺，後續和Dashboard 未授權一樣，可以透過建立特權容器然後逃逸。

圖6-透過 Rancher 建立特權容器

Rancher 等管理平臺是直接控制著整個叢集的，一旦出現安全問題，危害十分嚴重。從安全的角度講，管理平臺應該儘量避免暴露在外網。

攻擊點11：攻擊映象庫

1 上傳惡意映象

上傳惡意映象也叫映象投毒，指的是攻擊者透過上傳惡意映象到公開倉庫或受害者本地倉庫，然後將惡意映象偽裝成正常映象以引導受害者使用該映象建立容器，從而實現入侵。根據入侵的目的一般可將惡意映象分為兩種：入侵容器的惡意後門映象和入侵宿主機的惡意 EXP 映象。

（一）惡意後門映象

這類惡意映象主要是為了控制容器，一般是在受害者使用映象啟動容器後，就會向攻擊者反彈一個容器的 shell。這種情況下攻擊者可能是為了部署挖礦程式或者攻擊容器內執行的業務。

（二）惡意 EXP 映象

這類惡意映象已經不滿足於只入侵容器，因為藏在其中的 Exploit 往往是為了利用容器逃逸漏洞的，其意在獲得宿主機的控制權。

2 利用 Nday 攻擊映象庫

這裡指的是攻擊受害者本地的映象倉庫，如 Harbor、Nexus 等。Harbor 映象庫曾經就存在提權漏洞，危害十分嚴重。

以下是網上[2]統計的 Harbor 自發布以來的6年時間裡曝出的漏洞，供參考：

表1-Harbor 漏洞

其中 CVE-2020-13794 可以列舉使用者資訊，駭客進一步可以進行暴力破解，雖然不算高危漏洞，但卻被認為是影響面最大的漏洞[2]，巧的是，我們之前的一次滲透測試中就遇到了存在CVE-2020-13794的 Harbor 映象庫。

下面簡單演示一下該漏洞的驗證：

1.先在 Harbor 上註冊兩個賬戶 cstest 和 cstest2，

2.然後在本地攻擊機執行如下命令：

curl -X GET "http://[victim-ip]/api/users/search?username=_" -H "accept: application/json" --user cstest:Test123456

3. 看到返回了所有使用者的 id 及 username：

圖7-CVE-2020-13794 演示

攻擊點12：攻擊第三方元件

K8S 生態中還會使用一些第三方元件，比如服務網格、API 閘道器等，這些元件也有可能存在漏洞，比如開源 API 閘道器 Apache APISIX 的 RCE 漏洞、服務網格Istio 的未授權訪問或 RCE 漏洞等。本文篇幅有限，不再詳細討論，感興趣的讀者可自行去了解。

總結

目前雲原生攻防技術及產品處於快速發展階段，社群中已經湧現出很多非常優秀的利用工具和檢測工具，這些工具的出現極大地降低了攻擊的門檻，且隨著雲安全受到更多人的關注，也出現了越來越多新的攻擊技術，如何保障雲上安全成為了業界普遍關心的問題。

本文（上篇和下篇）共系統總結了K8S叢集中常見的12個攻擊點，並結合實踐經驗，討論了雲原生場景下存在的各種風險。相較於傳統內網場景，可見該場景下的架構更加複雜，攻擊面也更多。在面對這樣複雜的雲原生應用安全場景時，相關安全人員首先應該從整體上把握雲場景下業務架構的安全體系，從攻擊的角度出發，以攻思防，梳理系統可能面臨的風險，並秉持縱深防禦、最小許可權的防禦理念和原則，打造更全面的雲安全防護體系。

深信服創新研究院雲安全團隊將持續探索前沿雲攻防技術，為保障使用者的雲業務安全持續賦能。

參考連結

1.https://github.com/danielsagi/kube-dnsspoof

2.http://blog.nsfocus.net/harbor-2/