為啥突然要總結一下這個很老的知識點,我也不知道,可能太菜了,閑下來總得學點什么~

DNS Rebinding

0x01 攻擊簡介

DNS Rebinding也叫做DNS重綁定攻擊或者DNS重定向攻擊。在這種攻擊中,惡意網頁會導致訪問者運行客戶端腳本,攻擊網絡上其他地方的計算機。

在介紹DNS Rebinding攻擊機制之前我們先了解一下Web同源策略,

Web同源策略

同源策略(英語:Same-origin policy)是指在Web瀏覽器中,允許某個網頁腳本訪問另一個網頁的數據,但前提是這兩個網頁必須有相同的URL、主機名和端口號,一旦兩個網站滿足上述條件,這兩個網站就被認定為具有相同來源。此策略可防止某個網頁上的惡意腳本通過該頁面的文檔對象模型訪問另一網頁上的敏感數據,比如XSS,XXE,SSRF等基于網頁上的惡意腳本攻擊。

同源的定義:如果兩個 URL 的 協議、域名、端口都相同的話,則這兩個 URL 是同源

同源策略對Web應用程序具有特殊意義,因為Web應用程序廣泛依賴于HTTP cookie來維持用戶會話(session),所以必須將不相關網站嚴格分隔,以防止丟失數據泄露。

值得注意的是同源策略僅適用于腳本,這意味著某網站可以通過相應的HTML標簽訪問不同來源網站上的圖像、CSS和動態加載 腳本等資源。而跨站請求偽造(CSRF)就是利用同源策略不適用于HTML標簽的缺陷。

所以從理論上來講,同源策略是能夠有效的保證:客戶端腳本只能訪問為腳本提供服務的同一主機上的內容。

至此如何繞過Web同源策略也成了眾多hacker研究的地方。

0x02 攻擊原理:

這里說一下利用的TTL是什么:

TTL是英語Time-To-Live的簡稱,意思為一條域名解析記錄在DNS服務器中的存留時間。當各地的DNS服務器接受到解析請求時,就會向域名指定的NS服務器發出解析請求從而獲得解析記錄;在獲得這個記錄之后,記錄會在DNS服務器中保存一段時間,這段時間內如果再接到這個域名的解析請求,DNS服務器將不再向NS服務器發出請求,而是直接返回剛才獲得的記錄;而這個記錄在DNS服務器上保留的時間,就是TTL值。

即TTL的數值越小,修改記錄后所受的影響生效越快。

這里我們可以來構造一個DNS 重綁定的案例:

例如,要在192.168.32.10和127.0.0.1之間切換,我們可以將他們編碼為dwords,使用rbndr工具:

7f000001.c0a8200a.rbndr.us

接下來,我們測試一下:

# host 7f000001.c0a8200a.rbndr.us
7f000001.c0a8200a.rbndr.us has address 127.0.0.1
# host 7f000001.c0a8200a.rbndr.us
7f000001.c0a8200a.rbndr.us has address 127.0.0.1
# host 7f000001.c0a8200a.rbndr.us
7f000001.c0a8200a.rbndr.us has address 127.0.0.1
# host 7f000001.c0a8200a.rbndr.us
7f000001.c0a8200a.rbndr.us has address 192.168.32.10
# host 7f000001.c0a8200a.rbndr.us
7f000001.c0a8200a.rbndr.us has address 127.0.0.1
# host 7f000001.c0a8200a.rbndr.us
7f000001.c0a8200a.rbndr.us has address 127.0.0.1
# host 7f000001.c0a8200a.rbndr.us
7f000001.c0a8200a.rbndr.us has address 192.168.32.10
# host 7f000001.c0a8200a.rbndr.us
7f000001.c0a8200a.rbndr.us has address 127.0.0.1                                                   

由此就達到了一個DNS 重綁定的效果。

0x03 攻擊機制

攻擊者無法控制名稱服務器的載體,所有解析主機名(或 IP 地址,仍然是有效主機名)的請求都被重定向到由攻擊者控制和操作的備用名稱服務器。例如,如果我們有一個網址為 www.example-a.com 的網站,并且我們想要訪問私有內部域郵件服務器或只能通過該特定私有 IP 地址訪問的其他服務,則可以使用 DNS 重新綁定攻擊來偽造這些地址之一。

0x04 攻擊示例

  1. 1. 攻擊者注冊一個域名,例如 IP 地址為 1.3.5.7 的 www.evil.com,將其委托給自己的 DNS 服務器(1.3.5.4),并使用釣魚鏈接或電子郵件獲取 HTTP 流量。
  2. 2. DNS 服務器沒有發送正常的 TTL 記錄,而是發送了一個非常短的 TTL 記錄(例如,1 秒),防止條目 [www.evil.com, 1.3.5.7] 的 DNS 響應被緩存在受害者的(192.168.1.10 ) 瀏覽器。
  3. 3. 對手的服務器首先用包含服務器 IP 地址 (1.3.5.7) 的JavaScript 等惡意腳本響應受害者。
  4. 4. 對手使用 XMLHttpRequest (XHR) 將 HTTP 請求或 HTTPS 請求直接發送到對手的服務器并加載響應。
  5. 5. 惡意腳本允許對手將主機名重新綁定到防火墻后面的目標服務器的 IP 地址 (192.168.1.2)。
  6. 6. 然后服務器響應對手的真實目標,即與受害者(192.168.1.10)同域的內部主機IP(192.168.1.2)。
  7. 7. 由于同一個名稱解析為這兩個 IP 地址,瀏覽器會將這兩個 IP 地址(1.3.5.7 和 192.168.1.2)置于同一安全區域并允許信息在地址之間流動。
  8. 8. 此外,攻擊者可以通過發送多個短期IP地址來實現掃描和訪問受害者本地網絡(192.168.XX)中的所有內部主機。

0x05 攻擊危害

DNS Rebinding可以通過讓受害者的Web瀏覽器訪問專用IP地址的機器并將結果返回給攻擊者來破壞專用網絡。它也可以用于使用受害者機器發送垃圾郵件,分布式拒絕服務攻擊(DDOS)或其他惡意活動,也就是我們常聽說的肉機和僵尸機。

DDOS

0x04-1 通過 DNS 重新綁定攻擊進行網絡滲透測試:

在某些情況下,用戶會被誘騙使用這些網(例如,私人電子郵件服務器)創建網絡釣魚網站。由于發送到被劫持 URL 的所有流量現在都被發送回原始服務器,因此它變得完全混亂并迫使用戶安裝網絡釣魚頁面。以此來達到獲取用戶信息或者是用戶權限的作用。

0x06 將DNS Rebinding應用到實際漏洞挖掘

CVE-2022-4096

漏洞描述:1.8.2 之前的 GitHub 存儲庫 appsmithorg/appsmith 中的服務器端請求偽造 (SSRF)
復現鏈接:https://infosecwriteups.com/ssrf-via-dns-rebinding-cve-2022-4096-b7bf75928bb2

CVE-2023-26492

漏洞描述:Directus 是用于管理 SQL 數據庫內容的實時 API 和應用程序儀表板。當從遠程 Web 服務器導入文件(POST 到 /files/import)時,Directus 容易受到服務器端請求偽造 (SSRF) 的攻擊。攻擊者可以通過執行 DNS 重新綁定攻擊并查看來自內部服務器的敏感數據或執行本地端口掃描來繞過安全控制。攻擊者可以利用此漏洞訪問高度敏感的內部服務器并竊取敏感信息。此問題已在版本 9.23.0 中修復。
CVE鏈接:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-26492

CVE-2022-43548

漏洞描述:由于 IsAllowedHost 檢查不充分,Node.js 版本 <14.21.1、<16.18.1、<18.12.1、<19.0.1 中存在操作系統命令注入漏洞,該漏洞很容易被繞過,因為 IsIPAddress 沒有正確檢查 IP在發出允許重新綁定攻擊的 DBS 請求之前地址無效。https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32212 中針對此問題的修復不完整,這個新的 CVE 是為了完成修復。
CVE鏈接:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-43548

針對CVE-2022-43548CVE-2023-26492后續會有完整的復現過程文章,期待一下~

0x07 參考鏈接

[Web同源策略] https://zh.wikipedia.org/wiki/%E5%90%8C%E6%BA%90%E7%AD%96%E7%95%A5)
[DNS Rebinding] (https://en.wikipedia.org/wiki/DNS_rebinding)
[CVE-2022-4096] (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-4096)
[DNS Rebinding Attacks Explained] (https://danielmiessler.com/blog/dns-rebinding-explained/)