Kubernetes中kube-proxy漏洞CVE-2020-8558的示例分析

這篇文章主要介紹Kubernetes中kube-proxy漏洞CVE-2020-8558的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

前言

研究人員在Kubernetes節點的網絡組件kube-proxy中發現了一個嚴重的安全漏洞（CVE-2020-8558），而這個安全漏洞會將Kubernetes節點的內部服務暴露在外。在某些情況下，這個漏洞還有可能將api-server暴露在外，這將允許未經認證的攻擊者獲取Kubernetes集群的完整控制權限。在這種情況下，攻擊者將能夠竊取目標集群中存儲的敏感信息，部署加密挖礦軟件，或移除線上服務等等。

該漏洞會暴露目標Kubernetes節點的“localhost服務”，這個服務原本是一個僅可以從節點內部或節點本身訪問的服務，但該漏洞現在會將其暴露給本地網絡或運行在該節點上的Pods。本地主機所綁定的服務原本只能允許受信任的本地進程與之交互，因此通常不需要身份驗證就可以請求服務了。如果你的節點在運行“localhost服務”時沒有要求強制進行身份驗證的話，你也將會受到該漏洞的影響。

簡而言之，漏洞CVE-2020-8558將允許攻擊者訪問目標Kubernetes集群中的insecure-port，并獲取到目標集群的完整控制權。

kube-proxy

kube-proxy是一個運行在Kubernetes集群中每一個節點上的網絡代理，它的任務就是管理Pods和服務之間的連接。Kubernetes服務會暴露一個clusterIP，并且可能由多個后端Pods組成以實現均衡負載。一個服務一般由三個Pods組成，每一個都擁有其自己的IP地址，但是它們只會暴露一個clusterIP，假設是“10.0.0.1”。Podas在訪問目標服務時，會將數據包發送給它的clusterIP，也就是“10.0.0.1”，但隨后數據包必須重定向給其中一個Pods。

在這里，kube-proxy的作用就是為每一個節點提供路由表服務，這樣才能保證請求能夠正確路由至其中一個Pods。

罪魁禍首 - route_localnet

kube-proxy可以通過sysctl文件來配置多個網絡參數，其中一個就是net.ipv4.conf.all.route_localnet，而它就是導致這個漏洞出現的罪魁禍首。根據sysctl文檔的描述：“route_localnet：路由時不需要將回環地址設定為目的地址，這樣就可以使用127/8作為本地路由地址，默認為FALSE。”

針對IPv4地址，回環地址由127.0.0.0/8塊（127.0.0.1-127.255.255.255）組成，一般我們使用的是127.0.0.1，并將“localhost”映射到該地址，針對本地服務的數據包將通過回環網絡接口發送至IP 127.0.0.1。

設置route_localnet時，需要指示內核不要將地址127.0.0.1/8 IP定義為“martian”，那么這里的“martian”是什么意思呢？比如說，有些數據包在抵達一個網絡接口時，可以聲明它們的源IP地址或目的IP地址，假設抵達的數據包源IP地址為255.255.255.255，那么這個數據包本應該不存在，因為255.255.255.255這個地址時一個用于標識廣播地址的保留地址。此時，你的內核就無法確定了，只能判定這個數據包來自未知地方，應該被丟棄。

“Martian”數據包往往意味著有人在試圖通過網絡攻擊你，在上面的例子中，攻擊者可能想要你的服務去響應IP 255.255.255.255，并讓路由來廣播響應信息。但是在一些復雜的路由場景中，你可能想要內核去允許某些特定的“martian”包通過，這就是route_localnet的作用了。它可以讓內核不要將地址127.0.0.1/8 IP定義為“martian”包。kube-proxy能夠讓route_localnet支持各種路由包，那么在沒有部署適當安全機制的情況下，攻擊者將能夠通過本地網絡并利用route_localnet來執行各種攻擊了。

Localhost-only服務

Linux允許進程去監聽一個指定的IP地址，這樣就可以讓它們跟地址對應的網絡接口進行綁定了。內部服務通常會使用這種功能來監聽127.0.0.1，一般來說，這樣可以確保只有本地進程能夠訪問該服務。但是由于route_localnet的存在，外部數據包將同樣能夠抵達127.0.0.0/8。

訪問內部服務

在這種情況下，如果攻擊者嘗試訪問目標設備的內部服務，則需要構建一個目的IP為127.0.0.1，并且目的MAC地址為目標設備MAC地址的惡意數據包。如果目的IP無效，惡意數據包只能依賴于第二層（基于MAC）路由來抵達目標設備了。因此，即使目標用戶啟用了route_localnet，那么只有處于本地網絡中的攻擊者才能夠訪問目標設備的localhost服務。

當目標設備接收到惡意數據包之后，route_localnet將允許這個包通過，因為這個包的目的IP為127.0.0.1，那么它將被允許訪問localhost服務。下表中顯示的是惡意包的結構：

由于kube-proxy的存在，集群中的每一個節點都啟用了route_localnet。因此，節點本地網絡中的每一臺主機都將能夠訪問節點的內部服務。如果你的節點在運行內部服務時沒有部署身份認證機制，那你將會受到該漏洞的影響。值得一提的是，除了節點內部網絡中的相鄰主機之外，運行在節點內的Pods同樣能夠訪問其內部服務。

漏洞修復

Unit 42團隊將該漏洞報告給了Kubernetes安全團隊，該團隊表示如果集群啟用了api-server insecure-port，則該漏洞的嚴重程度為高危，未啟用則為中危。幸運的是，該漏洞的影響僅限于大部分托管Kubernetes服務，例如Azure Kubernetes Service（AKS），Amazon的Elastic Kubernetes Service（EKS）和Google Kubernetes Engine（GKE）。

該漏洞影響Kubernetes 1.1.0版本至1.16.10版本，1.17.0版本至1.17.6版本，和1.18.0版本至1.18.3版本。Kubernetes 1.18.4版本，1.17.7版本和1.16.11版本已修復該漏洞。

以上是“Kubernetes中kube-proxy漏洞CVE-2020-8558的示例分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！