web安全中濫用緩存密鑰規(guī)范化的緩存投毒技術(shù)

這篇文章給大家分享的是有關(guān)web安全中濫用緩存密鑰規(guī)范化的緩存投毒技術(shù)的內(nèi)容。小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過(guò)來(lái)看看吧。

寫在前面的話

眾所周知，如今的網(wǎng)站會(huì)包含大量的JavaScript文件/代碼，而這些代碼一般都取自于TypeScript、SCSS和Webpack等復(fù)雜的實(shí)現(xiàn)棧。為了減少標(biāo)準(zhǔn)網(wǎng)頁(yè)的加載時(shí)間，開(kāi)發(fā)人員會(huì)利用緩存來(lái)減少服務(wù)器上的負(fù)載并減少用戶的延遲。雖然緩存通常是為了幫助提高服務(wù)的可靠性，使其更易于用戶訪問(wèn)，但一些自定義緩存配置可能會(huì)引入拒絕服務(wù)漏洞，導(dǎo)致服務(wù)易受攻擊。

緩存投毒DoS基礎(chǔ)知識(shí)

當(dāng)攻擊者利用目標(biāo)設(shè)備中的緩存來(lái)向每一個(gè)請(qǐng)求資源的其他用戶發(fā)送更改響應(yīng)時(shí)，便有可能觸發(fā)緩存投毒漏洞，下面給出的是緩存投毒拒絕服務(wù)攻擊的演示樣例：

背景內(nèi)容

大家可以看到，實(shí)現(xiàn)DoS攻擊所需的只是一個(gè)未緩存的Header，它將強(qiáng)制源服務(wù)器發(fā)送格式錯(cuò)誤的請(qǐng)求。因此，我決定通過(guò)應(yīng)用以下方法，在一些私人應(yīng)用程序中尋找潛在的DoS漏洞：

• 通過(guò)識(shí)別特定的緩存Header（X-Cache和cf-cache-status等）來(lái)檢測(cè)使用了緩存服務(wù)的所有子域名；

• 使用Param Miner來(lái)爆破潛在的未緩存的Header；

沒(méi)花多少時(shí)間，我就在assests.redacted.com中找到了一個(gè)緩存投毒DoS漏洞，而這個(gè)子域名負(fù)責(zé)托管其中一個(gè)私人應(yīng)用程序所使用的全部JS和CSS文件。這個(gè)漏洞是由Fastify的Accept-Version Header所導(dǎo)致的，它將允許客戶端返回資源的版本描述信息，我可以使用下列方法來(lái)利用該功能：

GET /assets/login.js?cb=1                  GET /assets/login.js?cb=1

Host: assets.redacted.com                  Host: assets.redacted.com

Accept-Version: iustin

 

HTTP/1.1 404 Not Found                     HTTP/1.1 404 Not Found

X-Cache: Miss                              X-Cache: Hit

由于緩存密鑰中沒(méi)有包含Accept-version Header，因此任意請(qǐng)求JS文件資源的用戶都將收到緩存404響應(yīng)。令我驚訝的是，這個(gè)漏洞竟然讓我拿到了2000美金的漏洞獎(jiǎng)勵(lì)，因?yàn)镕astify并沒(méi)有提供金禁用Accept-version Header的選項(xiàng)，該漏洞目前已被標(biāo)記為了CVE-2020-7764。

然而，在測(cè)試了更多的主機(jī)之后，越來(lái)越明顯的是，我將無(wú)法用這種技術(shù)找到更多的易受攻擊的目標(biāo)。因此，我決定對(duì)其他可能的緩存投毒DoS小工具做一些額外的研究。

研究過(guò)程中，我發(fā)現(xiàn)大多數(shù)技術(shù)都討論了非緩存鍵輸入如何導(dǎo)致DoS，但它們忽略了緩存鍵輸入，比如說(shuō)主機(jī)Header或路徑等等。因此，我能夠想出兩個(gè)新的攻擊方式，并成功復(fù)現(xiàn)一次之前的漏洞。

技術(shù)一：主機(jī)Header大小寫規(guī)范化

根據(jù)RFC-4343的定義，F(xiàn)QDN（全限定域名）必須是大小寫敏感的，但是在某些情況下，框架并不會(huì)嚴(yán)格遵循這一點(diǎn)。有趣的是，由于主機(jī)值應(yīng)該不區(qū)分大小寫，一些開(kāi)發(fā)人員會(huì)假設(shè)在將主機(jī)頭值引入cachekey時(shí)寫入小寫字符會(huì)是安全的，而不會(huì)更改發(fā)送到后端服務(wù)器的實(shí)際請(qǐng)求。

在將這兩種行為配對(duì)時(shí)，我能夠使用自定義配置的Varnish作為緩存解決方案在主機(jī)上實(shí)現(xiàn)以下DoS攻擊：

GET /images/posion.png?cb=1                GET /images/posion.png?cb=1  

Host: Cdn.redacted.com                     Host: cdn.redacted.com

 

HTTP/1.1 404 Not Found                     HTTP/1.1 404 Not Found

X-Cache: Miss                              X-Cache: Hit

注意上面大寫的主機(jī)Header值，它將導(dǎo)致404錯(cuò)誤，然后Varnish將使用cache鍵中主機(jī)Header的規(guī)范化值來(lái)緩存該數(shù)據(jù)。在將該漏洞上報(bào)之后，我又拿到了800美金的漏洞獎(jiǎng)勵(lì)。

分析過(guò)程中，我還發(fā)現(xiàn)它的負(fù)載均衡器（HAProxy）在接收到了大寫的Header值時(shí)，便會(huì)響應(yīng)404錯(cuò)誤。

除了主機(jī)Header之外，參數(shù)和路徑在注入到cachekey之前也可以是小寫的，因此我們應(yīng)該檢查緩存處理這些數(shù)據(jù)時(shí)所采用的機(jī)制。

技術(shù)二：路徑規(guī)范化

在使用緩存識(shí)別子域時(shí)，我發(fā)現(xiàn)了一個(gè)托管圖像的特定子域。請(qǐng)求一張圖片的請(qǐng)求類似如下：

GET /maps/1.0.5/map/4/151/16.png

Host: maps.redacted.com

跟之前一樣，Param Miner無(wú)法找到任何隱藏Header，因此我決定深入分析一下。就我目前所知，路徑中的最后三個(gè)數(shù)字是用來(lái)告訴服務(wù)器應(yīng)該返回映射的哪一部分范圍。我研究了半天，但啥也沒(méi)獲取到。

起初，我認(rèn)為1.0.5只是一個(gè)版本號(hào)，所以我沒(méi)有太過(guò)關(guān)注，但令我驚訝的是，當(dāng)我嘗試1.0.4時(shí)，竟然出現(xiàn)了緩存命中的情況。當(dāng)然，我認(rèn)為其他一些API可能使用的是舊版本，所以我測(cè)試了1.0.0，它也返回了緩存命中的響應(yīng)。沒(méi)過(guò)多久我就意識(shí)到，無(wú)論我用什么替換1.0.5，它都會(huì)返回200 OK和一個(gè)X-Cache命中響應(yīng)Header。于是乎，我想出了以下方法：

GET /maps/%2e%2e/map/4/77/16.png          GET /maps/1.0.5/map/4/77/16.png

Host: maps.redacted.com                   Host: maps.redacted.com

 

HTTP/1.1 404 Not Found                    HTTP/1.1 404 Not Found

X-Cache: Miss                             X-Cache: Hit

同樣，在試圖提高緩存命中率時(shí)，開(kāi)發(fā)人員沒(méi)有考慮到潛在的DoS攻擊，這使得我可以注入%2e%2e（URL編碼..），并將請(qǐng)求重定向到服務(wù)器上不存在的/map/4/77/16.png，從而導(dǎo)致404錯(cuò)誤。

感謝各位的閱讀！關(guān)于“web安全中濫用緩存密鑰規(guī)范化的緩存投毒技術(shù)”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！