Kubernetes使用者許可權提升漏洞(CVE-2018-1002105)預警

Kubernetes · 發表 2018-12-05 19:06:33

摘要：報告編號：B6-2018-120501 報告來源：360-CERT 報告作者：360-CERT 更新日期：2018-12-05 0x00 事件背景 2018-12-03凌晨Kubernetes的開發者@liggitt 在Kubernetes 的issuse中公佈該...

報告編號：B6-2018-120501

報告來源：360-CERT

報告作者：360-CERT

更新日期：2018-12-05

0x00 事件背景

2018-12-03凌晨Kubernetes的開發者@liggitt 在Kubernetes 的issuse中公佈該漏洞的一些細節以及影響。

只要可以從Kubernetes API伺服器的網路中可以直接訪問聚合API伺服器，就可以提升許可權對任何聚合API伺服器端點進行API呼叫，以及對該聚合API伺服器執行任何API請求（例如Pod的建立以及執行任意命令並獲得返回結果）。在預設配置中，允許所有使用者（經過身份驗證和未經身份驗證的使用者）執行允許此許可權提升的API呼叫。

該漏洞由Rancher Labs的首席架構師兼聯合創始人@Darren Shepard發現。

0x01 影響範圍

Kubernetes v1.0.x-1.9.x
Kubernetes v1.10.0-1.10.10 (fixed in v1.10.11)
Kubernetes v1.11.0-1.11.4 (fixed in v1.11.5)
Kubernetes v1.12.0-1.12.2 (fixed in v1.12.3)

主要受影響的方面如下

可從Kubernetes API伺服器網路直接訪問的擴充套件API伺服器（如排程伺服器）的群集不希望對Kubelet API具有完全訪問許可權的使用者授予pod exec / attach / portforward許可權的群集

@liggitt指出目前沒有簡單的方法可以檢測是否被此漏洞攻擊。由於未經授權的請求是通過已建立的連線進行的，因此它們不會出現在Kubernetes API伺服器稽核日誌或伺服器日誌中。請求會記錄在kubelet或聚合的API伺服器日誌中，但是與正確授權和代理的請求無法區分開。

0x02 修復建議

官方推薦的最佳的修復方案是及時升級到

Kubernetes v1.10.11
Kubernetes v1.11.5
Kubernetes v1.12.3
Kubernetes v1.13.0-rc.1

下面是一些@liggitt 給出的緩解措施

針對匿名使用者的緩解措施 -> 可以按照如下方式對聚合伺服器進行配置：

暫停使用聚合的API伺服器（請注意，這將影響使用聚合伺服器提供的API的使用者）
通過將--anonymous-auth = false傳遞給kube-apiserver來禁用匿名請求（請注意，這可能會破壞kube-apiserver的負載均衡器或kubelet執行狀況檢查，並中斷kubeadm join設定流程）
刪除對所有聚合API的所有匿名訪問（包括由預設發現角色繫結授予的發現許可權）

針對經過身份驗證的使用者的緩解措施 -> 可以按照如下方式對聚合伺服器進行配置：

暫停使用聚合的API伺服器（請注意，這將影響使用聚合伺服器提供的API的使用者）
從不應具有對聚合API的完全訪問許可權的使用者中刪除對所有聚合API（包括由預設發現角色繫結授予的發現許可權）的所有訪問許可權（請注意，這可能會破壞使用者和控制器利用發現資訊對映API型別到URLs）

針對授權pod exec / attach / portforward的緩解 - > 可以按照如下方式對kubelet API進行配置：

從不應具有對kubelet API的完全訪問許可權的使用者中刪除pod exec / attach / portforward許可權

0x03 簡要分析

根據Issue中@liggitt的描述可以得知

kube-apiserver <-> kubelet 的連線是依靠 kube-apiserver的 TLS 憑證實現的，只要擁有已經建立的TLS連線, 那麼kubelet 就會認可來自kube-apiserver的請求並且完成相應的操作。預設情況下kubelet是允許執行所有API許可權的操作。

而該漏洞的產生也就是在 k8s.io/apimachinery/pkg/util/proxy/upgradeaware.go 中介面的邏輯有缺陷，導致使用者完成對該介面的訪問後即可獲得持續的TLS連線。

修復函式為 (h *UpgradeAwareHandler) tryUpgrade(w http.ResponseWriter, req *http.Request)

tryUpgrade() 由 ServeHTTP()進行呼叫，ServeHTTP() 用於處理代理響應請求，在 UpgradeRequestRoundTripper() 介面描述中，所有有關Upgrade的響應都會經由代理（Proxy）處理。此時代理，也就相當於一箇中間伺服器（Server）。

在使用者通過API Server向 Backend 發起請求時，API Server 會先進行一次是否為 Upgrade 請求判斷, 使用函式 httpstream.IsUpgradeRequest() , 對 HTTP 請求頭部是否含 Upgrade 欄位進行判斷，不含 Upgrade 的請求，則判斷失敗，結束。

ServeHTTP() 在處理過程中，使用了 http.Hijacker, Go語言的 Hijacker 可以用於接管請求，對請求訊息進行轉發。

此刻 Proxy(API Server) 是具有 Full access 許可權的，導致轉發的請求（由部分不具備高許可權的使用者發起/以及未授權的使用者）也具備了 Full access 許可權，造成提權漏洞

補丁圍繞著 rawResponseCode 進行，如果狀態碼不是101，則會在轉發請求前結束。

Upgrade 說明： HTTP/1.1 引入了 Upgrade 機制，允許將一個已建立的連線升級成新的，不相容的協議。需要對HTTP頭進行設定，狀態碼為101。

ofollow,noindex">Handle error responses from backends by liggitt · Pull Request #71412 · kubernetes/kubernetes

而根據這個commit的修復我們可以看到