dns-rebinding-attacks

关于dns-rebinding-attacks

一份专注于客户端技术的DNS重绑定攻击指南，旨在通过更改受害者已加载的主机名背后的IP地址，来绕过浏览器的同源策略。其核心洞见在于：同源策略检查的是主机名字符串，而非解析后的IP地址： 控制其域名权威DNS的攻击者可以在首次解析时（攻击者IP）提供恶意JavaScript，随后将同一主机名重新解析为内部IP，这样浏览器就会将对内部服务的请求视为同源请求，从而使脚本能够读取响应内容。

本文阐明了该漏洞与 SSRF 的区别——因为 DNS 重绑是其客户端对应的攻击形式——并详细说明了实际障碍及应对策略。 由于浏览器维护着自己的 DNS 缓存，且该缓存会忽略 TTL 较短的记录（在 Chrome、Edge 和 Firefox 中约为 60 秒），因此本文记录了多种绕过策略，包括等待缓存过期、通过包含攻击者 IP 阻断的多条 A 记录响应来强制回退、通过子域名洪水攻击触发新解析，以及利用服务 worker 延迟等。 攻击变体包括经典的HTTP重绑定、WebSocket重绑定、服务器端TOCTOU混合攻击，以及快速多A记录攻击方法。

在测试依赖 DNS 进行源域验证的应用程序，或向攻击者控制的域名发起客户端 fetch/XHR 请求的应用程序时，请使用此方法，特别是在无法进行服务器端 SSRF 攻击的情况下。高价值目标列表包含云元数据（169.254.169.254）、 Docker 和 Kubernetes API、内部管理面板、Elasticsearch、Redis 以及 Consul/etcd；其中特别指出，IMDSv2 因令牌要求而难以被重绑定，因为在无 CORS 模式下难以设置自定义头部。 涵盖的工具包括 Singularity、无需配置的 rbndr.us 服务（采用十六进制 IP 子域名格式）、whonow 以及精简版 Python DNS 服务器，并交叉引用了 SSRF 和 CORS 配置错误相关技术。

常见问题

DNS 重绑定与 SSRF 有何区别？

SSRF 属于服务器端攻击，而 DNS 重绑则是运行在受害者浏览器中的客户端对应攻击。它利用了同源策略仅检查主机名字符串而非解析后的 IP 地址这一漏洞。

为什么 TTL 设为 0 无法立即生效？

浏览器维护着自己的 DNS 缓存，该缓存会忽略较低的 TTL 值（在 Chrome、Edge 和 Firefox 中约为 60 秒），因此本技能涵盖了诸如等待、带后备的多条 A 记录、子域名泛洪以及服务 worker 延迟等绕过方法。

哪些是高价值的内部目标？

位于 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 服务器。