標題：利用DNS重綁定在Chrome、Edge和Safari中實現瞬間DNS重綁定的攻擊技術

本文介紹了在Chrome、Edge和Safari中實現可靠的DNS重綁定的新技術，並討論了繞過本地網絡限制的技術。通過分析慢緩存的根本原因，提出了新的解決技術。本文研究了利用DNS重綁定在Chrome、Edge和Safari中實現瞬間DNS重綁定的攻擊技術。

本文是關於DNS重新綁定係列文章中的第二篇。第一篇文章介紹了一個使用DNS重新綁定後攻擊的案例。在這篇文章中，我介紹了在IPv6可用時在Chrome, Edge和Safari中實現可靠的，瞬間DNS重新綁定的新技術，以及一種繞過本地網絡限制的技術，該技術適用於基於Chrome的瀏覽器的獲取API。

瀏覽器中的DNS重綁定傳統上被視為攻擊者通過誘騙受害者加載惡意網站來訪問內部網絡服務的一種方式，但隨著許多現代web應用程序現在在其部分功能上驅動無頭瀏覽器，它已成為攻擊web應用程序的有用工具。無頭瀏覽器，即Headless Browser，是一種沒有界面的瀏覽器。它擁有完整的瀏覽器內核，包括JavaScript 解析引擎、渲染引擎等。與普通瀏覽器最大的不同是，無頭瀏覽器執行過程中看不到運行的界面，但是我們依然可以用GUI 測試框架的截圖功能截取它執行中的頁面。在上一篇文章中，我介紹了一個使用可能是最簡單的重新綁定方法的例子。在這種情況下，我有很長的時間讓漏洞運行，但這在許多web應用程序中不太可能，需要更快的技術。

緩慢的緩存簡單的DNS重綁定技術依賴於對相同主機名的連續查找返回不同的DNS記錄。對於這些攻擊，所花費的最小時間是瀏覽器執行兩次連續DNS查找之間的時間。這有時可以通過刷新瀏覽器緩存來加快速度，生成大量DNS查找以填充可用的緩存空間，並導致舊條目在過期之前被清除，從而使瀏覽器更快地對相同的主機名執行第二次查找。

當它工作時，它仍然需要大約10秒的時間，而且通常這種技術不會起作用，因為中間緩存不能像瀏覽器的緩存那樣容易地被清除。例如，在測試期間，我發現在一個新創建的Ubuntu EC2實例上，由於系統解析的緩存，我只能每5分鐘為同一域獲得不同的響應。在VPN上，我看到DNS響應在默認解析器上至少緩存30分鐘。讓用戶將頁面打開這麼長時間以允許攻擊者實現DNS重新綁定漏洞，通常是一件很困難的事情，更不用說將無頭瀏覽器作為web應用程序的一部分驅動了。

為了加速漏洞利用，2010年Craig Heffner提出了通過在相同響應中回復同一域的多個A記錄來執行DNS重新綁定的想法，Gerald Doussot和Roger Meyer在2019年的singularity 中使用了這種技術。 Singularity是一個開放源碼容器平台，旨在簡化、快速和安全。 Singularity 是針對EPC 和HPC 工作負載進行優化的，允許不受信任的用戶以可信的方式運行不受信任的容器。

返回的兩條記錄是攻擊者控制的公共服務器的IP地址和目標服務器的(通常是私有的)IP地址。

只有當瀏覽器試圖首先與公共服務器通信並加載攻擊者的惡意頁面時，攻擊才會起作用。然後，攻擊者的web服務器開始阻止來自受害者瀏覽器的流量，導致瀏覽器退回到將所有請求發送到目標服務器。在這種情況下，攻擊者頁面中的JavaScript將能夠向同一來源下的目標IP地址發送請求。

這種技術確實繞過了緩存問題，因為瀏覽器只需要執行一次DNS查找，儘管在我的測試期間，所有主要瀏覽器都會始終嘗試在公共IP地址之前與私有IP地址通信，這意味著這些技術不起作用。雖然我不相信這種行為是為了防止DNS重新綁定，但它可以有效的阻止這種技術。

這種新行為促使我研究新的技術，可以用來在Safari和基於chrome的瀏覽器中實現瞬間DNS重新綁定。這些技術的關鍵是找到新的方法，使瀏覽器最初使用公共IP，然後在加載網站時切換到使用私有IP。打開Wireshark，我注意到在現代瀏覽器中加載網站時，會同時發送A和AAAA查詢。我開始調查這種行為是否可以用來可靠地執行DNS重新綁定。

攻擊Safari：延遲DNS響應當你在通過IPv6訪問互聯網的主機上加載Safari網頁時，分別為IPv4和IPv6地址發送A和AAAA DNS查詢。當返回多個IP地址時，Safari將優先考慮私有IP地址而不是公共IP地址。

當A或AAAA響應延遲時，Safari中允許快速DNS重新綁定的有趣行為會發生。在這種情況下，Safari不會等待所有DNS響應，而是在接收到第一個DNS響應後立即發送HTTP請求。當收到延遲的DNS響應時，此響應中的IP地址將被添加到IP地址池中，Safari可以在將來請求該域時使用該IP地址池。

這意味著，如果第一個DNS響應是針對公共IP地址的，而延遲的DNS響應是針對私有IP地址的，Safari將向公共IP地址發送第一個請求，直到接收到延遲的DNS響應，此時它將開始向私有IP地址發送請求。

這提供了一種在Safari中使用自定義DNS服務器實現DNS重新綁定的簡單方法，該服務器可處理*.r.inded.es的查詢：

1.加載目標瀏覽器http://safari.r.intrud.es，觸發safari.r.intrud.es的A和AAAA查找。

2.讓DNS服務器立即返回AAAA記錄，其中包含互聯網上攻擊者控制的web服務器的IPv6地址。暫時不要返回A響應。

3.一旦收到AAAA響應，Safari將向攻擊者的web服務器發出第一個請求。從攻擊者的web服務器返回一個帶有JavaScript的頁面來重複請求http://safari.r.intrud.es/secret.txt。

4.從DNS服務器發送包含本地網絡上目標服務器的IP地址的A響應。

5.Safari現在將對http://safari.r.intrud.es/secret.txt的請求發送到本地網絡上的目標服務器。從攻擊者的服務器加載的頁面可以讀取這些請求的響應，而不會違反同源策略。

為了實現這一點，我編寫了一個小型DNS服務器，可以使用命令行參數延遲DNS響應。在實踐中，我發現將A響應延遲100毫秒幾乎總是足夠的，儘管可以使用200毫秒或更長時間的延遲來使該技術更加可靠。可以在這裡https://github.com/intruder-io/dns-delay-server找到這個服務器以及設置它的說明。

我用來利用它的PHP腳本會將用戶重定向到r.introd.es的隨機子域，以避免中間緩存干擾利用。它還將JavaScript直接包含在頁面中，以避免另一個資源負載。你可以在這裡找到使用的代碼。

該腳本在操作中的視頻請點此，從本地web服務器檢索文件的內容：

我在iOS上的Safari和Brave上進行了測試，發現同樣的技術也可以用於訪問內部網絡上的服務。

攻擊Chrome：使用AAAA優先級Chrome將優先加載本地網絡上的頁面，而不是互聯網上的頁面，但在可用的情況下，它會優先加載IPv6而不是IPv4上的頁面。所以首要任務是：

1.本地IPv6(最高優先級)；

2.公共IPv6；

3.當地IPv4；

4.公共IPv4(最低優先級)；

這裡的關鍵部分是Chrome會優先考慮公共IPv6地址而不是私有IPv4地址。此外，當Chrome知道一個域的多個IP地址時，一旦服務器重置連接，它就會嘗試不同的IP地址。

這給出了一個針對Chrome的快速DNS重綁定計劃：

1.加載http://chrome.r.intrud.es，這將觸發A和AAAA查找chrome.r.intrud.es。

2.讓DNS服務器返回指向本地網絡上目標web服務器的A記錄和指向公共互聯網上攻擊者控制的web服務器的AAAA記錄。

3.Chrome將優先考慮IPv6地址，並從攻擊者控制的web服務器發出第一個加載頁面的請求，該服務器返回JavaScript以重複向http://chrome.r.intrud.es/secret.txt發出請求。

4.關閉攻擊者控制的服務器，以便重置所有連接。 Chrome現在將把所有請求發送到本地網絡上的目標服務器。

5.讓加載的頁面向http://chrome.r.intrud.es/secret.txt發出請求。可以在不違反同源策略的情況下讀取對這些請求的響應。

這個計劃幾乎成功了。從互聯網加載的頁面上的JavaScript試圖向本地網絡上的目標發出請求，但這些請求被阻止，並在控制台中顯示以下錯誤：

Accesstofetchat'http://chrome.r.intrud.es/secret.txt'fromorigin'http://chrome.r.intrud.es'hasbeenblockedbyCORSpolicy:Therequestclientisnotasecurecontextandtheresourceisinmore-privateaddressspace`local`.出現此錯誤是因為Chrome部分實現了私有網絡訪問(PNA)https://wicg.github.io/private-network-access/規範中描述的保護。

繞過PNAPrivate Network Access（以前稱為CORS-RFC1918 ）限制了網站向私有網絡上的服務器發送請求的能力。根據規範，此類請求只允許來自安全上下文。另外，該規範擴展了跨域資源共享（CORS）協議，因此網站現在必須在允許發送任意請求之前，必須顯式請求私有網絡上服務器的許可。

私有網絡是指目標服務器的IP地址比從其獲取請求服務器的IP地址更私有的請求。例如，從公共網站（https://example.com）向私有網站（http://router.local）的請求，或從私有網站向localhost 的請求。

PNA保護阻止通過普通HTTP從公共互聯網加載的頁面向私有網絡發出請求。在Chrome中，這些保護是為fetch請求實現的，但還沒有為iframe實現。不完整的實現以及DNS重新綁定允許繞過對獲取請求的PNA限制。

我們可以重複利用到上面的步驟4，其中公共web服務器已經關閉，所有對http://chrome.r.intrud.es的請求現在都被定向到本地網絡上的目標服務器。加載的首頁不能向本地網絡發出請求，因為它是通過HTTP從公共互聯網加載的，但是我們可以在iFrame中加載http://chrome.r.intrud.es。這個iFrame中的頁面將從目標web服務器加載。由於此服務器位於本地網絡上，因此允許在iFrame中加載的頁面向本地網絡發出請求。

iFrame中的頁面也與頂部頁面處於相同的起源，這使得頂部頁面可以完全控制框架頁面的DOM。這包括注入腳本，使獲取請求進入框架頁面。這些腳本可以用來訪問目標web服務器並洩露數據，就像如果PNA根本沒有實現的話，它們可以從首頁獲取數據一樣。

所以，把這些放在一起，我們最終得到了一個完整的步驟：

1.加載http://chrome.r.intrud.es，這將觸發A和AAAA查找chrome.r. imports .es。

2.讓DNS服務器返回一條A記錄，指向本地網絡中的目標web服務器，並返回一條AAAA記錄，指向公網上攻擊者控制的web服務器。

3.Chrome將首先請求從攻擊者的web服務器加載頂部頁面，該服務器返回一個頁面以執行以下步驟。

4.關閉攻擊者控制的服務器，以便重置所有連接嘗試。 5.Chrome現在將把所有請求發送到本地網絡上的目標服務器。

6.從首頁，將一個腳本注入框架頁面以請求http://chrome.r.intrud.es/secret.txt並將響應發送到攻擊者的web服務器。

這可以在Chrome中實現瞬間DNS重新綁定。

為了幫助實現這個漏洞，我編寫了一個小型web服務器，當它接收到/block請求時將停止。你可以在這裡找到運行它的源代碼和說明。

當攻擊自動瀏覽器時，你通常想要在頁面中包含一個iFrame，這需要一些時間來加載。這將阻止瀏覽器認為頁面已完全加載，直到iFrame已加載，並確保漏洞利用腳本有足夠的時間運行。下面的演示顯示，當gowitness被用來從啟用了IPv6的EC2上截取惡意網站的截圖時，這個漏洞被用來從AWS元數據服務中提取憑證：

或者對於更可能在web應用程序中發現的場景，使用無頭Chromium將網頁轉換為PDF：

這種繞過Chrome的PNA限制的行為通過他們的問題跟踪器報告給了Chrome團隊。他們確定這不是安全問題，因為PNA的限制仍在實施過程中。

總結DNS重新綁定是攻擊web應用程序的一個武器。在本系列的第一篇文章中，我試圖展示如何在不太複雜的情況下實現針對web應用程序的重新綁定漏洞。在這篇文章中，我提供了一些工具和技術來構建可靠的漏洞攻擊驅動自動瀏覽器的web應用程序，即使它們只加載頁面很短的時間。