網頁緩存中毒:投放惡意代碼新方法
作者:星期三, 八月 29, 20180

Portswigger,開發出Web應用攻擊平臺 Burp Suite 的公司,再添超越前版緩存中毒的新技術。

網頁緩存能減少時延,降低應用服務器負載,從而加速網頁加載。有些公司使用Varnish之類軟件托管緩存;有些則選擇依靠Cloudflare這樣的內容分發網絡(CDN),將緩存散布在多個地方。還有些流行網頁應用和框架,比如流行內容管理系統Drupal,具備內置緩存。

網頁緩存中毒通過發送能引發有害響應的請求實施,該請求會被保存在緩存中,進而影響其他用戶。

新型緩存中毒主要關注利用HTTP頭之類非用戶鍵入的輸入。其他不那么有效的小花招,比如“請求走私”也有成功的可能。

緩存中毒本身不是黑客的最終目的,而是用非鍵入性輸入打開第二階段漏洞利用(比如跨站腳本攻擊(XSS))大門的途徑。只要正確操作,網頁緩存中毒可創建起一套機制,產生能執行任意JavaScript代碼的特定響應,通過目標網站的網頁緩存,來攻擊試圖瀏覽該網站上特定資源的用戶。

雖然惡名昭彰,緩存中毒卻非常容易實施。在策略對研究人員不太限制的網站上做的實驗已經證明了這一點。

Mr. Robot 擴展

Mozilla Firefox 瀏覽器的SHIELD系統維護有一張recipe表,可供靜默安裝用于市場營銷或研究目的的擴展,其與黑客劇集《機器人先生》合作推出的 Mr. Robot 擴展就曾在推送之列。研究人員表示,可以黑掉Mozilla的基礎設施,并部分劫持該靜默安裝擴展的功能,理論上能夠聯合數百萬Firefox瀏覽器組成僵尸網絡。

僅Mozilla簽名代碼才能以這種方式推送的控制措施,某種程度上限制了攻擊者的破壞力。但無論如何,Mozilla的這項功能留下了可引發問題的隱患。

雖然不能直接安裝惡意插件并獲取完整代碼執行權,但黑客可以將數千萬用戶導引到其所選擇的URL,形成分布式拒絕服務(DDoS)攻擊。除此之外,如果結合恰當的內存破壞漏洞,所造成的影響將不可估量。

而且,某些后端Mozilla系統使用未簽名recipe,有可能被黑客攻陷,當成深藏于系統基礎設施里的立足點,還有可能供黑客獲取到recipe簽名密鑰。另外,黑客還可重放舊recipe,大量安裝有漏洞的舊擴展,或者將已停止自動推送的 Mr. Robot 擴展又安回去。

研究人員已將該問題報告給了Mozilla。24小時之內,Mozilla便修復了其基礎設施。但關于該問題的嚴重性,該公司與研究人員之間存在分歧,只支付了1000美元的漏洞獎勵。

通過下載并梳理GitHub上前2萬個PHP項目的頭名稱,研究人員擴展了頭字典,發現了另一個方面的問題。

能夠重寫請求路徑的X-Original-URL和X-Rewrite-URL頭暴露了出來。我先是注意到了這兩個頭會影響運行Drupal的目標,隨后在深挖Drupal代碼的過程中,我又發現了支持這些頭的是流行PHP框架Symfony,而Symfony的代碼又來自Zend。

其結果就是,大量PHP應用在不知不覺間支持了這些頭。

這些頭簡直就是繞過網頁應用防火墻(WAF)和安全規則的利器,還能為緩存中毒提供一條康莊大道。只要應用使用了緩存,攻擊者就能利用這些頭欺騙應用,讓應用提供錯誤的頁面。

攻陷Unity

被稱為“本地路由中毒”的一種攻擊方法,可以讓攻擊者替換掉本應訪問的路徑。最終結果就是,訪問請求發出之后,試圖訪問 Unity for Education 的用戶可能會對瀏覽到的頁面大吃一驚。

還有其他相關安全漏洞可供黑客重寫查詢字符串,若與Drupal的開放重定向聯合使用,黑客構建漏洞利用的基礎就齊全了。

能夠重寫請求路徑的X-Original-URL和X-Rewrite-URL頭暴露了出來。我先是注意到了這兩個頭會影響運行Drupal的目標,隨后在深挖Drupal代碼的過程中,我又發現了支持這些頭的是流行PHP框架Symfony,而Symfony的代碼又來自Zend。

作為第二階段攻擊的嵌套緩存中毒也是有可能實現的。如果站點使用外部緩存(比如幾乎所有的高流量Drupal網站),就可以用內部緩存來對外部緩存下毒,并在過程中將任意響應轉換成重定向。

研究人員演示的最終實踐結果,是點擊unity.com網站上的“下載安裝文件”按鈕,會下載到evil.net上的惡意軟件。

5月份的時候,該漏洞就已通報給了Drupal、Symfony和Zend。安全更新已放出,用戶最好安裝一下。

Mozilla和Drupal是網頁緩存中毒的典型例子,其他項目也有緩存缺陷,但對緩存中毒漏洞的通報響應不一:

Unity立即做了全面修復并支付了可觀的漏洞獎勵;Mozilla的修復動作也很快;但包括data.gov和Ghost在內的其他人就幾個月都毫無動靜,只是在即將公開的威脅下才勉強修復。

這些案例研究中有很多都在非鍵入性輸入中利用了XSS之類的次級漏洞。需要強調的是,若沒有緩存中毒,此類漏洞會因沒有可靠的方法迫使其他用戶在跨域請求中發送定制包頭而沒什么用處。或許這就是此類漏洞很容易被發現的原因吧。 

如何防護

要么做測試,確保自家網站沒有緩存中毒漏洞;要么限制緩存使用,避免潛在風險。

應對緩存中毒的最堅實防御,就是禁用緩存。對某些人而言禁用緩存或許不太現實,但很多開始采用Cloudflare之類服務以驅動DDoS防護或邊界SSL應用的網站,最終都會因為默認啟用緩存而陷入緩存中毒攻擊的困境。

將緩存限制在純靜態響應上也很有效,只要你對自己定義為“靜態”的東西足夠警惕。

但顯然,簡單地將緩存堆到網站面前只會讓網站從安全狀態落入脆弱狀態。

網頁緩存中毒長期以來都是個艱澀難懂的漏洞,一個主要用于恐嚇開發人員去乖乖修復沒人能實際利用的“理論上”的威脅。但如今,網頁緩存中毒遠不只是理論上的漏洞,臃腫的應用和層層疊疊的服務器棧正密謀將其推到大眾面前。

附上Drupal安全團隊發言人的回應:

收到研究人員的漏洞報告后,Drupal安全團隊發現了Drupal依賴棧中的某些Symfony和Zend框架代碼存在問題。Symfony和Zend項目成員與我們合作,協同發布了有關這些問題的情況說明與解決方案。

論文原文地址:

https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Regilero-Hiding-Wookiees-In-Http.pdf

相關閱讀

都什么年代了 看個視頻還會中毒?

都什么年代了,打開個Word文檔還能中毒!Locky病毒瘋狂傳播

 

分享:

相關文章

沒有相關文章!

寫一條評論

 

 

0條評論