dns-rebinding-attacks

關於dns-rebinding-attacks

一份專注於客戶端技術的 DNS 重新綁定攻擊指南，旨在透過變更受害者已載入的主機名稱所對應的 IP 位址，來繞過瀏覽器的同源政策。其核心洞見在於：同源政策檢查的是主機名稱字串，而非解析後的 IP 位址： 若攻擊者控制了其網域的權威 DNS 伺服器，便可在首次解析時（攻擊者 IP）載入惡意 JavaScript，隨後將相同主機名重新解析至內部 IP；如此一來，瀏覽器會將對內部服務的請求視為同源請求，該腳本便能讀取回應內容。

本文闡明了其與 SSRF 的區別——因為 DNS 重新綁定是其客戶端對應技術——並詳述了實際上的障礙與解決方法。 由於瀏覽器會維護自己的 DNS 快取，且會忽略 TTL 值較低的記錄（在 Chrome、Edge 和 Firefox 中約為 60 秒），因此本文記錄了多種繞過策略，包括等待快取過期、透過包含攻擊者 IP 封鎖的多重 A 記錄回應來強制回退、透過子網域洪水攻擊觸發新的解析，以及利用服務工作者（Service Worker）延遲等。 攻擊變體包括經典的 HTTP 重新綁定、WebSocket 重新綁定、伺服器端 TOCTOU 混合攻擊，以及快速多 A 記錄方法。

當測試依賴 DNS 進行來源驗證的應用程式，或向攻擊者控制的網域發起客戶端 fetch/XHR 請求的應用程式時，可運用此方法，特別是在無法進行伺服器端 SSRF 的情況下。一份高價值目標清單列出了雲端元數據（169.254.169.254）、 Docker 與 Kubernetes API、內部管理後台、Elasticsearch、Redis 以及 Consul/etcd；並特別註明 IMDSv2 因需驗證憑證，且在 no-cors 模式下難以設定自訂標頭，因此能抵禦重新綁定攻擊。 工具涵蓋範圍包括 Singularity、無需設定的 rbndr.us 服務（採用十六進位 IP 子網域格式）、whonow 以及精簡版 Python DNS 伺服器，並與 SSRF 及 CORS 配置錯誤的技術要點相互參照。

常見問題

DNS 重新綁定與 SSRF 有何不同？

SSRF 屬於伺服器端攻擊，而 DNS 重新綁定則是運行於受害者瀏覽器中的客戶端對應攻擊。它利用了「同源政策」僅檢查主機名稱字串，而非解析後的 IP 位址這一漏洞。

為何 TTL 設為 0 無法立即生效？

瀏覽器會維護自己的 DNS 快取，並會忽略較低的 TTL（在 Chrome、Edge 和 Firefox 中約為 60 秒），因此本技巧涵蓋了諸如等待、帶有備用選項的多個 A 記錄、子網域洪水攻擊以及服務工作程序延遲等繞過方法。

哪些是高價值的內部目標？

位於 169.254.169.254 的雲端元資料、Docker API、Kubernetes API、內部管理後台、埠 9200 上的 Elasticsearch、埠 6379 上的 Redis，以及 Consul/etcd。

能否透過重新綁定從 IMDSv2 竊取 AWS 憑證？

並非易事。IMDSv2 要求 PUT 請求必須包含 X-aws-ec2-metadata-token 標頭，而在 no-cors 模式下，重新綁定難以在初始令牌請求中設定自訂標頭。相較之下，IMDSv1 的防護較為薄弱。

它推薦哪些工具？

Singularity（完整框架）、rbndr.us（零設定，使用十六進位 IP 對子網域）、whonow（動態重新綁定伺服器），以及最簡化的自訂 Python DNS 伺服器。