淺談云上攻防——CVE-2020-8562漏洞為k8s帶來的安全挑戰 - 網安 - 專業的網絡安全產業、社區、知識平臺

前言

2021年4月，Kubernetes社區披露了一個編號為CVE-2020-8562的安全漏洞，授權用戶可以通過此漏洞訪問 Kubernetes 控制組件上的私有網絡。

通過查閱此漏洞披露報告可發現，這個漏洞擁有較低的CVSS v3評分，其分值僅有2.2分，與以往披露的Kubernetes高危漏洞相比，這個擁有較低評分的漏洞極其容易被安全研究人員以及運維人員所忽視。但經過研發測試發現，在實際情況中，這個低風險的漏洞卻擁有著不同于其風險等級的威脅：在與云上業務結合后，CVE-2020-8562漏洞將會為云廠商帶來不可忽視的安全挑戰。

在這篇文章中，云鼎實驗室將為大家帶來業內首個CVE-2020-8562漏洞分析報告，一同來看一下這個被忽視的低風險漏洞引發的“血案”。

CVE-2020-8555漏洞簡述

Kubernetes為了緩解CVE-2020-8555等歷史漏洞帶來的安全問題，對APIServer Proxy請求進行域名解析以校驗請求的IP地址是否處于本地鏈路 (169.254.0.0/16) 或 localhost (127.0.0.0/8) 范圍內，Kubernetes通過此方式禁止由用戶觸發的對Services，Pods，Nodes，StorageClass對象的內網Proxy訪問權限。

但是在完成校驗并通過校驗之后，Kubernetes立即進行第二次域名解析，此次域名解析后并不再進行IP地址的校驗，這將導致上述校驗存在繞過問題，如果一個DNS服務器不斷返回不同的非緩存解析請求，攻擊者可以利用此方式繞過Kubernetes的API Server Proxy IP地址限制，并訪問內網ControlPlane管控組件。

詳細的漏洞細節可參見如下圖Issue所示：

圖 1 CVE-2020-8562漏洞細節

Issue地址如下：

https://github.com/kubernetes/kubernetes/issues/101493

在正式開始介紹這個漏洞是如何對Kubernetes集群帶來危害之前，我們先來看看這個漏洞中應用到主要攻擊技巧：DNS重綁定攻擊（DNS Rebinding）。

DNS重綁定攻擊

DNS重綁定攻擊技術的實現主要依賴于攻擊者可將其自建的DNS服務器中DNS TTL配置為設置為0或者極小值。DNS TTL表示DNS記錄的生存時間,數值越小, DNS記錄在DNS服務器上緩沖的時間越小。

在攻擊者將DNS TTL數值設置為一個極小值時，當受害目標第一次訪問惡意域名時并發起域名解析請求時，惡意DNS服務器會返回一個ip地址A；當受害目標第二次發起域名解析請求時，卻會得到ip地址B的解析結果。具體的原理，我們可以通過一道CTF題目，深入了解一下：

$dst = @$_GET['KR'];
$res = @parse_url($dst);
$ip = @dns_get_record($res['host'], DNS_A)[0]['ip'];
...
$dev_ip = "54.87.54.87";
if($ip === $dev_ip) {
    $content = file_get_contents($dst);
    echo $content;
}

這道CTF題目需要參賽者訪問內網127.0.0.1地址并獲取存儲于其中的Flag。

從代碼中可見，題目將會判斷參賽者傳入的域名解析后的ip，并僅允許訪問54.87.54.87地址的內容。

如何繞過題目中的條件語句，利用到的就是DNS重綁定攻擊技術。

從上文代碼段可見，程序通過以下代碼來執行第一次DNS解析以獲取ip：

$ip = @dns_get_record($res['host'], DNS_A)[0]['ip'];

假設此時參賽者傳入的域名為www.a.com，將會進行如下的解析：

圖 2首次DNS解析流程

此時www.a.com域名解析出來的ip為54.87.54.87。

程序繼續往下執行，執行到了如下代碼塊：

$dev_ip = "54.87.54.87";

if($ip === $dev_ip){}

此時ip參數為54.87.54.87，滿足條件分支判斷，程序執行進入if條件分支。

隨后，程序執行到如下語句：

$content = file_get_contents($dst);

注意，此時file_get_contents方法內的參數為參賽者控制的域名dst,而非ip地址。

也就是說，程序執行file_get_contents方法時，需要獲取此域名的ip地址解析。由于攻擊者將DNS TTL設置的數值極其小，從程序第一次獲取ip到執行file_get_contents方法處時，DNS緩存早已失效，CTF服務器此時需要重新發起域名解析請求以獲取www.a.com的ip，此時參賽者修改DNS解析結果以完成DNS重綁定攻擊，見下圖：

圖 3重綁定DNS解析

此時獲取到的解析ip值為127.0.0.1，參賽者通過此方式繞過限制并訪問127.0.0.1資源，實現重綁定攻擊。

KuBernetes中DNS重綁定攻擊的應用

Kubernetes為了防止用戶對Services，Pods，Nodes，StorageClass對象的內網Proxy進行非法訪問，采用了域名解析的方式解析并校驗Proxy請求的IP地址是否位于本地鏈路 (169.254.0.0/16) 或 localhost (127.0.0.0/8) 范圍內。

Kubernetes通過此方式防止惡意內網資源的Proxy訪問行為，但是Kubernetes在校驗通過之后，會進行第二次域名解析，獲取IP地址訪問而不再進行IP地址的校驗。

聯想到上一章節的DNS重綁定攻擊方式：攻擊者可以控制DNS解析的IP地址，在第一次校驗時返回一個合法值，隨后在第二次獲取IP地址時，返回一個本地鏈路或 localhost地址，詳見下圖：

圖 4 Kubernetes中DNS重綁定流程

通過這個技術方式，攻擊者可以繞過apiserver proxy的內網限制，構造惡意請求訪問集群中的資源。

這種攻擊技術將為云服務商帶來了極大的安全問題：大多數云服務商提供Kubernetes托管版集群服務，采用此服務的用戶Master節點將由云廠商創建并托管，如果攻擊者通過方式訪問到本地鏈路 (169.254.0.0/16) 或 localhost (127.0.0.0/8)地址，則有可能訪問同為托管模式下其他用戶的apiserver。

CVE-2020-8562漏洞原理

首先，使用云廠商提供的Kubernetes托管版集群服務創建一個集群。在此場景下，我們創建的集群的Master節點將與其他采用托管服務的用戶一并，由云廠商創建并托管管理，這為后續的利用提供了先決條件。

圖 5 Kubernetes托管版集群服務

在集群創建完畢后，通過編寫如下yaml來創建一個名為cve-2020-8562的node，見下圖：

圖 6 使用yaml創建node

通過上圖可見，在此yaml中，將只能在集群內進行路由的節點的IP地址InternalIP設置為攻擊者可控的www.attacker.com。

創建完畢后，可以通過kubectl get nodes查看到此節點：

圖 7 通過kubetctl查看cve-2020-8562節點

從上圖紅框處可以發現，此時我們創建的cve-2020-8562節點的狀態為NotReady，但即使此時cve-2020-8562節點的狀態為NotReady，也并不影響后續的利用流程。

使用如下命令啟動Kubernetes API 服務器的代理：

kubectl proxy &

圖 8 通過kebuectl開啟代理

在成功啟動Kubernetes API 服務器的代理之后，通過如下命令使用apiserver proxy來訪問cve-2020-8562節點的apiserver：

圖 9訪問cve-2020-8562節點的apiserver

通過上文來看，cve-2020-8562節點處于NotReady，我們可以正常的訪問其apiserver嗎？

我們來看一下Kubernetes是如何完成接下來的訪問：

首先，為了可以訪問cve-2020-8562節點，Kubernetes首先需要獲取cve-2020-8562節點的InternalIP，我們通過如下指令查看一下cve-2020-8562 的InternalIP：

圖 10 查看cve-2020-8562節點詳情

通過上圖可知，cve-2020-8562節點的InternalIP值與生成此節點yaml中配置項一致，為我們配置的www.attacker.com。

由于InternalIP為域名而非IP地址，Kubernetes需要對其進行域名解析，隨后校驗獲取到的IP地址是否位于本地鏈路 (169.254.0.0/16) 或 localhost (127.0.0.0/8) 范圍內，如果獲取到的IP屬于此范圍，則禁止訪問。

在第一次DNS解析時，攻擊者自建的DNS服務器將會返回一個合法的IP地址（非本地鏈路或 localhost范圍），例如172.x.x.x，流程見下圖：

圖 11 第一次DNS解析

通過此方式，可以繞過k8s的本地鏈路/localhost范圍IP校驗。

在通過安全校驗之后，K8s將會發起第二次域名解析。由于攻擊者將DNS TTL設置的數值極其小，此時DNS緩存已失效，k8s需要重新發起域名解析請求以獲取www.attacker.com的ip地址，流程見下圖：

圖 12 DNS重綁定攻擊

從上圖可見，此時攻擊者可以將 www.attacker.com域名的IP解析為一個localhost范圍內的IP地址并返回，在此例中，我們返回一個127.x.x.x地址。

此時，k8s apiserver proxy訪問情況可以類比于下圖情況：

圖 13當前訪問可抽象成此情況

如果127.x.x.x這個節點的apiserver 存在未授權訪問情況，我們就可以通過此方式直接訪問其apiserver，見下圖：

圖 14 攻擊者訪問托管服務中Master

通過此方式，可以訪問其他使用Kubernetes托管集群服務的租戶的apiserver。

總結

在安全研究以及運維中，一些低風險的集群漏洞極其容易被安全以及運維人員所忽略，但是這些漏洞在一些特定場景中仍為云上安全帶來了極大的安全挑戰，正如本文中所舉例的CVE-2020-8562安全漏洞，這個僅有2.2評分的Kubernetes安全漏洞，在與實際業務結合后，仍可為業務帶來極大的安全風險。因此與云上安全相關的漏洞，無論嚴重與否，都應得到安全人員以及運維人員的相應重視。

參考鏈接

https://github.com/kubernetes/kubernetes/issues/101493

https://zhuanlan.zhihu.com/p/89426041

https://cloud.tencent.com/developer/article/1400018