漏洞攻擊
過度授權的容器如何暴露 AWS 登入憑證
在 Amazon EKS 當中，過度授權或組態設定錯誤的容器很可能讓敏感的 AWS 登入憑證暴露於封包監聽 (packet sniffing) 和 API 欺騙 (API spoofing) 之類的威脅當中，突顯出企業需要採取最低授權原則以及主動式防護來偵測並降低這些風險。
摘要
- Kubernetes 環境中的容器假使發生組態設定錯誤或授予過度權限的情況，很可能讓駭客未經授權而取得敏感的 AWS 登入憑證，使得環境暴露於權限提升與惡意活動的風險當中。
- Trend™ Research 發現了駭客經由過度授權的容器來發動攻擊的情境，包括：利用封包監聽來探查未加密 HTTP 流量以取得純文字登入憑證，以及利用網路設定來攔截授權金鑰並提升權限來欺騙 API。
- AWS 的責任共同分擔模型突顯了協同合作的重要性，服務供應商須負責確保基礎架構的安全，但客戶也有責任管理容器化應用程式內的權限設定，以確保環境安全。
- Trend Vision One™ Container Security 可讓企業強制實施主動式資安政策來偵測及防範容器過度授權的情況，這有助於防範封包監聽與 API 欺騙之類的攻擊情境，同時還能縮小整體攻擊面、降低資安風險。
Kubernetes 容器平台在雲端扮演著關鍵的角色，能以高效率的方式大規模協調及管理容器化應用程式，它能將部署、擴充及營運自動化，非常適合微服務與各種工作負載使用。其主要效益包括：雲端可攜性、提高資源利用率來改善成本效率、透過自動化與自我修復來加速開發循環，還有簡化分散式系統的管理，這些全部加起來，就能實現彈性、可擴充的應用程式。
Amazon Elastic Kubernetes Service (EKS) 是一項託管式服務，可簡化在 Amazon Web Services (AWS) 和企業內環境執行 Kubernetes 的工作。它將 Kubernetes 控制層的管理自動化，確保高可用性與擴充性，同時還能與其他 AWS 服務無縫整合來提供網路、資安及儲存。如此一來，使用者就能專心部署及管理容器化應用程式。
組態設定錯誤或過度授權的容器，容易衍生重大的資安風險，因為這將為駭客提供未經授權的存取與控制權，進而掌控環境內的敏感資料與系統資源。因此，採取措施來確保組態設定正確並限制容器僅擁有必要的權限，對於維護一個安全的容器化基礎架構至關重要。
本文檢視駭客如何利用過度授權的容器來監聽封包和欺騙 API，並示範駭客如何利用這類組態設定錯誤直接在容器化應用程式內取得敏感的 AWS 登入憑證，藉此點出雲端環境的一大隱憂。
此外，我們也將示範如何使用 Trend Vision One™ 來偵測及回應過度授權的情況，在 Trend Vision One 的 Container Protection (容器保護) 區域中強制貫徹客製化政策設定。
Amazon EKS Pod Identity 服務遭利用
Amazon EKS Pod Identity 是 AWS 推出的一項功能，用來簡化 EKS 叢集內執行的 Pod 取得 AWS 登入憑證的程序。它提供了 IAM Roles for Service Accounts (IRSA) 之外的另一種替代方式及輔助性作法來讓您從 Kubernetes 應用程式內部安全地存取 AWS 資源，如 S3 儲存貯體 (bucket) 或 DynamoDB 資料表。
在設定 Pod Identity 時，首先必須在 Amazon EKS 叢集上安裝 eks-pod-identity-agent (代理程式) 附加元件。此代理程式會在 kube-system 命名空間內以 DaemonSet 的方式運作，確保每個工作節點上都會執行一份代理程式。
代理程式會對外暴露一個簡單的 API 來接收 Authorization (授權) 標頭當中的 Kubernetes 服務帳號金鑰 (token)，並呼叫一個特定的 AWS API 動作：eks-auth:AssumeRoleForPodIdentity。這個 API 是暴露在一個 link-local (鏈路本地端) 位址 (IPv4 為 169.254.170.23，IPv6 為 [fd00:ec2::23]) 的連接埠 80 上。
amazon-eks-pod-identity-webhook 變異准入控制器 (mutating admission controller) 會自動更新來將 AWS_CONTAINER_CREDENTIALS_FULL_URI 和 AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE 兩個環境變數注入使用 Pod Identity 相關服務帳號的 Pod。這些環境變數將透過 AWS SDK 來辨識。
當 Pod 當中的某個應用程式使用 AWS SDK 來對 AWS 服務發出請求時，SDK 會自動找到相關的環境變數，然後從節點上執行的 EKS Pod Identity 代理程式取得臨時的登入憑證。接著，代理程式會與 eks-auth:AssumeRoleForPodIdentity API 互動來為相關的 IAM 角色取得所需的登入憑證。
封包監聽攻擊情境
EKS Pod Identity 代理程式會在每個節點上執行，並經由未加密 HTTP 在本機 IP 位址上暴露一個 API。
如此將帶來資安風險，因為任何採用「hostNetwork: true」設定的 Pod 都可監聽節點上的網路流量，進而攔截 API 端點 169.254.170.23:80 發送的任何登入憑證。由於 AWS 環境並未將這些登入憑證綁定至特定資產，因此駭客可利用這些登入憑證在該環境內取得更高的權限。
一個使用標準 tcpdump 工具的簡易概念驗證 (PoC) 就能證明登入憑證是以純文字傳輸。由於 AWS 的登入憑證並未綁定某台主機，因此第三方可利用這些登入憑證來取得更高的權限。
API 欺騙情境
光從啟用了「hostNetwork」設定的容器移除 CAP_NET_RAW 的能力，並無法徹底防範這項風險，因為可能還有其他允許網路介面操作的權限 (如 CAP_NET_ADMIN) 被啟用。只要有某個不受控的 Pod 能操控網路介面卡 (NIC) 的設定，那它就能藉由刪除處理程序所綁定的本地端鏈路 IP 位址來停用 eks-pod-identity-agent 的 HTTP 背景處理程序 (daemon)。如此一來，駭客就能掌控 169.254.170.23:80 上執行的 HTTP 服務，並部署自己的 HTTP 伺服器。這台伺服器將可攔截內送 HTTP 請求當中的授權金鑰 (Authorizaton token)，然後用來取得有效的 AWS 登入憑證。
我們用 Python 撰寫了一段概念驗證程式碼，並使用 pyroute2 這類常用函式庫來示範上述攻擊手法。
結論與建議
本文點出在 Kubernetes 環境內使用 Amazon EKS Pod Identity 來簡化 AWS 資源的存取時應考量的一些重要資安問題。組態設定錯誤 (尤其是授予容器過多的權限) 很可能讓 AWS 登入憑證暴露在外並衍生重大風險，包括讓駭客在雲端環境內提升權限，以及執行未經授權的動作。
我們透過封包監聽與 API 欺騙情境來示範駭客可能如何利用過度授權的容器來攔截或操弄敏感的登入憑證。這些漏洞突顯出遵守最低授權原則的重要性，如此才能確保容器組態設定不會逾越界線，同時也盡量減少駭客的攻擊機會。
廠商揭露
上述兩項攻擊技巧皆已經由 Trend Zero Day Initiative ™ (ZDI) 漏洞懸賞計畫通報給 Amazon，編號為 ZDI-CAN-26891。AWS 的聲明如下：
「我們的團隊已完成調查，並判定您通報的行為並非安全問題，而是節點本身信任邊界內預期的行為，屬於責任分擔模型當中的客戶端責任。節點或叢集操作人員有責任確保擁有較高權限的應用程式應該受到適當的規範。節點取得 Pod Identity 角色的能力原本就在意料之內，同時也符合信任邊界的模型，如 EKS Pod 資安最佳實務原則與責任共同分擔文件所述。」
使用 Trend Vision One 來發掘及防範容器過度授權的情況
主動管理容器的能力是保護容器化環境的重要一環。在設定容器時應採取最低授權原則，這一點對於盡量縮小攻擊面並降低潛資安風險至關重要。
偵測容器內的過度授權情況
Trend Vision One™ Container Security 可讓企業定義並強制實施政策來偵測 (並選擇性封鎖) 權限超越預期的容器。前述攻擊情境要能實現的基本條件就是容器擁有過度的能力 ，例如：CAP_NET_RAW、CAP_NET_ADMIN，或是 hostNetwork 旗標為 true 的 Pod。
政策設定可在 Trend Vision One 主控台上的 Cloud Security -> Container Protection (雲端防護 -> 容器保護) 找到，這裡提供了各種組態設定選項。要解決上述過度授權的問題，請在 Pod 屬性區域內勾選「Log」(寫入記錄檔) 或「Block」(封鎖)「containers that run in the host network namespace」(在主機網路命名空間內執行的容器) 以及「containers with capabilities that do not conform with a Baseline policy」(能力不符合基準政策的容器) 選項。
如需有關建立與使用 Kubernetes 政策的詳細資訊，請參閱以下 Trend Vision One 文件：
- https://docs.trendmicro.com/en-us/documentation/article/trend-vision-one-kubernetes-prot-policy
- https://docs.trendmicro.com/en-us/documentation/article/c3124722-5232-484a-a42d-3ed454227a6d-kubernetes-protection-policies
政策一旦設好之後就會自動偵測違規的情況，如下圖所示：
