国产成人毛片毛片久久网_国产午夜激无码av毛片不_国产乱对白精彩在线播放_av资源站中文字幕_亚洲男人的天堂网站_国产成 人 综合 亚洲网_中国国产激情一区_少妇一级淫片免费放_亚洲一本大道av久在线播放_免费观看美女裸体网站

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

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

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

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

Issue地址如下：

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

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

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

在攻擊者將DNS TTL數(shù)值設置為一個極小值時，當受害目標第一次訪問惡意域名時并發(fā)起域名解析請求時，惡意DNS服務器會返回一個ip地址A；當受害目標第二次發(fā)起域名解析請求時，卻會得到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重綁定攻擊技術。

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

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

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

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

程序繼續(xù)往下執(zhí)行，執(zhí)行到了如下代碼塊：

$dev_ip = "54.87.54.87";

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

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

隨后，程序執(zhí)行到如下語句：

$content = file_get_contents($dst);

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

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

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

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

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

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

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

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

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

在集群創(chuàng)建完畢后，通過編寫如下yaml來創(chuàng)建一個名為cve-2020-8562的node

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

創(chuàng)建完畢后，可以通過kubectl get nodes查看到此節(jié)點：

從上圖紅框處可以發(fā)現(xiàn)，此時我們創(chuàng)建的cve-2020-8562節(jié)點的狀態(tài)為NotReady，但即使此時cve-2020-8562節(jié)點的狀態(tài)為NotReady，也并不影響后續(xù)的利用流程。

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

kubectl proxy &

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

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

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

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

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

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

在第一次DNS解析時，攻擊者自建的DNS服務器將會返回一個合法的IP地址（非本地鏈路或 localhost范圍）

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

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

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

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

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

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

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