1. 簡介

混沌工程（Chaos Engineering）是一門學科，專注於有意地在系統中注入故障，以建立彈性並在它們在生產環境中演變成中斷之前識別出弱點。隨著雲原生架構，特別是那些建立在 Kubernetes 上的架構變得普及，為混沌工程設計的工具也隨之演進，以滿足這些複雜的需求。Chaos Mesh 是雲原生運算基金會（Cloud Native Computing Foundation, CNCF）的一個孵化中專案，它是這樣的一個平台，為 Kubernetes 叢集提供了全方位的故障注入功能 [1]。

最近，在 Chaos Mesh 平台內發現了名為「Chaotic Deputy」的嚴重漏洞。這些漏洞，特別是 CVE-2025-59358、CVE-2025-59360、CVE-2025-59361 和 CVE-2025-59359，被評估為嚴重級別（CVSS 9.8），即使在預設的 Chaos Mesh 設定下，也可能使叢集內的攻擊者在 Kubernetes 叢集中的任何 pod 上執行任意程式碼 [1]。本報告旨在對這些漏洞進行詳細的技術檢查，探討其根本原因、潛在的利用途徑以及對 Kubernetes 環境的架構影響。

2. Chaos Mesh 架構概覽

為了理解「Chaotic Deputy」漏洞，首先必須掌握 Chaos Mesh 平台的基本架構。Chaos Mesh 功能為協調 Kubernetes 叢集內的各種故障模擬。其架構包含三個主要元件 [1]：

• Chaos Dashboard： 此元件提供了網頁使用者介面，用於視覺化和操作混沌實驗。它還整合了 RBAC（Role-Based Access Control，基於角色的存取控制）機制，用於權限管理。
• Chaos Controller Manager： 作為核心邏輯元件，Chaos Controller Manager 負責排程和管理混沌實驗。它包含了幾個 Custom Resource Definition (CRD) Controllers，例如 Workflow Controller、Scheduler Controller 和各種特定於故障的控制器。
• Chaos Daemon： 這是主要的執行元件，通常以 DaemonSet 模式運行，預設擁有特權。其主要功能是干擾叢集內特定的網路設備、檔案系統和 Kernel 以注入故障。

這些元件之間的互動對於 Chaos Mesh 的運作至關重要。特別是 Chaos Controller Manager，它與多種複雜的內部元件互動，由於其在協調跨 Kubernetes 叢集的混沌實驗中的核心作用，使其成為安全研究的重點。

2.1 Chaos Mesh 架構圖

下方架構圖直觀地展示了 Chaos Mesh 元件及其在 Kubernetes 叢集中的交互作用。圖中重點介紹了主要元素：Chaos Dashboard、Chaos Controller Manager、Chaos Daemon 以及 CRD Controller。此外，圖中也展示了攻擊向量：攻擊者的 pod 利用 Chaos Controller Manager (CVE-2025-59358) 中未經驗證的 GraphQL 伺服器，透過 Chaos Daemon 觸發故障注入，最終透過其他 CVE 在 Kubernetes pod/節點上執行任意程式碼。

3. Chaotic Deputy 漏洞的技術分析

「Chaotic Deputy」漏洞源於 Chaos Mesh 平台中的幾處安全設定錯誤和設計缺陷。本節詳細分解了每個已識別的 CVE。

3.1 CVE-2025-59358：GraphQL Server 缺少驗證

主要漏洞之一 CVE-2025-59358 涉及 Chaos Controller Manager 暴露的 GraphQL server 嚴重缺乏驗證。Chaos Controller Manager 的服務帳號被設定為 ClusterIP 類型，使其暴露的 port 可在整個叢集中存取。一個除錯工具，特別是 GraphQL server，預設在 Controller 上啟動，並且發現其 /query endpoint 沒有強制執行驗證 [1]。

來自 Chaos Controller Manager 的相關程式碼片段展示了這個設定：

....
if ccfg.ControllerCfg.CtrlAddr != "" {
    		go func() {
    			mutex := http.NewServeMux()
    			mutex.Handle("/", playground.Handler("GraphQL playground", "/query"))
    			mutex.Handle("/query", params.CtrlServer)
    			setupLog.Info("setup ctrlserver", "addr", ccfg.ControllerCfg.CtrlAddr)
    			setupLog.Error(http.ListenAndServe(ccfg.ControllerCfg.CtrlAddr, mutex), "unable to start ctrlserver")
    		}()
    	}
    	hookServer.Register("/validate-auth", &webhook.Admission{
    		Handler: apiWebhook.NewAuthValidator(ccfg.ControllerCfg.SecurityMode, authCli, mgr.GetScheme(),
    			ccfg.ControllerCfg.ClusterScoped, ccfg.ControllerCfg.TargetNamespace, ccfg.ControllerCfg.EnableFilterNamespace,
    			params.Logger.WithName("validate-auth"),
    		),
    	},
    	)
....
      

從程式碼中可以看出，如果 ccfg.ControllerCfg.CtrlAddr 被設定，將啟動一個 HTTP server。這個 server 處理對 / 和 /query 的請求。關鍵在於，暴露 GraphQL API 的 /query endpoint 在處理請求之前沒有強制執行驗證機制。這使得任何能夠存取 Chaos Controller Manager 網路叢集內的攻擊者，無需驗證即可與 GraphQL server 互動。然後，攻擊者可以指示 Chaos Daemon 在 Kubernetes 叢集內啟動故障注入。例如，可以透過在關鍵 pod 上使用 killProcesses mutation 來觸發阻斷服務（DoS）攻擊，例如 Kubernetes API server，導致整個叢集的中斷 [1]。

下面提供了一個使用 curl 觸發 killProcesses mutation 的攻擊範例：

curl -X POST -H "Content-Type: application/json" -d '{"query": "mutation KillProcessesInPod { pod(ns: \"kube-system\", name: \"kube-apiserver-minikube\") { killProcesses(pids: [\"1\"]) { pid command } } }"}' "http://chaos-controller-manager.chaos-mesh.svc:10082/query"        

這個命令展示了未經驗證的攻擊者如何向 Chaos Controller Manager 發送 GraphQL mutation，以終止指定 pod 內的程序（例如，在 kube-system 命名空間中的 kube-apiserver-minikube ），從而有效地造成 DoS。port 10082 是 GraphQL server 的預設 port。

3.2 CVE-2025-59360, CVE-2025-59361, 和 CVE-2025-59359：命令注入和權限提升

另外三個嚴重漏洞（CVE-2025-59360、CVE-2025-59361 和 CVE-2025-59359）與命令注入和權限提升有關。雖然文章沒有提供這些特定 CVE 的明確程式碼片段，但它強調了它們允許叢集內攻擊者注入 OS 命令。鑑於 Chaos Daemon 運行時擁有特權，成功的命令注入可能導致嚴重後果，包括任意程式碼執行和完全的叢集接管 [1]。

將 OS 命令注入到像 Chaos Daemon 這樣的特權元件中的能力尤其危險。攻擊者可以利用這一點來：

• 在運行 Chaos Daemon 的主機系統上執行任意命令。
• 存取敏感的檔案和設定。
• 竊取特權服務帳號 Token，進一步提升其在 Kubernetes 叢集內的權限。
• 操控其他 pods 和資源，有效地獲得對整個叢集的控制權。

這些漏洞，加上對 GraphQL server 未經驗證的存取，創造了一個強大的攻擊途徑。攻擊者可以先未經驗證地存取 GraphQL API（CVE-2025-59358），然後使用它來觸發故障注入，從而利用命令注入漏洞（CVE-2025-59360、CVE-2025-59361、CVE-2025-59359），以在特權 pods 上實現任意程式碼執行。

4. 偵測與因應措施

偵測 Chaos Mesh 部署是否容易受到「Chaotic Deputy」漏洞影響，涉及檢查 Chaos Mesh 的安裝版本以及 Chaos Controller Manager 的設定。可以使用以下命令進行偵測 [1]：

kubectl get pods -A --selector app.kubernetes.io/name=chaos-mesh -o=jsonpath="{range .items[*]}{.metadata.name}{\": \"}{range .spec.containers[*]}{.image}{\", \"}{end}{\'\\n\'}{end}"
kubectl describe pod chaos-controller-manager -n chaos-mesh | grep "CTRL_ADDR:"

如果 Chaos Mesh 的 image 版本早於 2.7.3，並且 Chaos Controller Manager 暴露了 port 10082（在描述中由 CTRL_ADDR: 指示），則該部署存在漏洞。強烈建議使用者立即將 Chaos Mesh 升級到 2.7.3 或更高版本。

對於無法立即升級的情況，可以透過重新部署 Helm chart 並禁用 chaosctl 工具和暴露的 port 來實施臨時因應措施。這可以透過以下 Helm 命令實現 [1]：

helm install chaos-mesh chaos-mesh/chaos-mesh -n=chaos-mesh --version 2.7.x --set enableCtrlServer=false

禁用 enableCtrlServer 有效地關閉了有漏洞的 GraphQL server，從而緩解了 CVE-2025-59358，並阻止攻擊者利用它來利用其他漏洞。然而，這種因應措施可能會影響 Chaos Mesh 依賴控制 server 的功能，而完全升級仍然是建議的解決方案。

5. 結論

Chaos Mesh 中的「Chaotic Deputy」漏洞強調了在雲原生環境中實施穩健安全實踐的極其重要性。未經身份驗證的 API 存取和命令注入缺陷的結合帶來了嚴重的風險，允許叢集內攻擊者破壞 Kubernetes 叢集。雖然混沌工程是增強系統彈性的寶貴實踐，但工具本身必須受到嚴格保護，以防止它們成為攻擊的媒介。

及時修補和遵守安全最佳實踐，例如最小化暴露的攻擊面和實施強大的驗證機制，至關重要。這些漏洞的披露和後續修復凸顯了開源社群內部持續進行安全研究和協作的必要性，以維護像 Chaos Mesh 這樣的關鍵基礎設施元件的完整性和安全性。

參考文章

1. Critical Chaos-Mesh vulnerabilities Kubernetes cluster takeover