浅析DNS Rebinding
Posted 蚁景科技
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了浅析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 重绑定的效果。
【----帮助网安学习，以下所有学习资料免费领！加vx：yj009991，备注 “博客园” 获取！】
① 网安学习成长路径思维导图
② 60+网安经典常用工具包
③ 100+SRC漏洞分析报告
④ 150+网安攻防实战技术电子书
⑤ 最权威CISSP 认证考试指南+题库
⑥ 超1800页CTF实战技巧手册
⑦ 最新网安大厂面试题合集（含答案）
⑧ APP客户端安全检测指南（安卓+IOS）
0x03 攻击机制
攻击者无法控制名称服务器的载体，所有解析主机名（或 IP 地址，仍然是有效主机名）的请求都被重定向到由攻击者控制和操作的备用名称服务器。例如，如果我们有一个网址为 www.example-a.com 的网站，并且我们想要访问私有内部域邮件服务器或只能通过该特定私有 IP 地址访问的其他服务，则可以使用 DNS 重新绑定攻击来伪造这些地址之一。
0x04 攻击示例
-
攻击者注册一个域名，例如 IP 地址为 1.3.5.7 的 www.evil.com，将其委托给自己的 DNS 服务器（1.3.5.4），并使用钓鱼链接或电子邮件获取 HTTP 流量。
-
DNS 服务器没有发送正常的 TTL 记录，而是发送了一个非常短的 TTL 记录（例如，1 秒），防止条目 [www.evil.com, 1.3.5.7] 的 DNS 响应被缓存在受害者的（192.168.1.10 ) 浏览器。
-
对手的服务器首先用包含服务器 IP 地址 (1.3.5.7) 的
JavaScript等恶意脚本响应受害者。 -
对手使用
XMLHttpRequest (XHR)将 HTTP 请求或 HTTPS 请求直接发送到对手的服务器并加载响应。 -
恶意脚本允许对手将主机名重新绑定到防火墙后面的目标服务器的 IP 地址 (192.168.1.2)。
-
然后服务器响应对手的真实目标，即与受害者（192.168.1.10）同域的内部主机IP（192.168.1.2）。
-
由于同一个名称解析为这两个 IP 地址，浏览器会将这两个 IP 地址（1.3.5.7 和 192.168.1.2）置于同一安全区域并允许信息在地址之间流动。
-
此外，攻击者可以通过发送多个短期IP地址来实现扫描和访问受害者本地网络（192.168.XX）中的所有内部主机。
0x05 攻击危害
DNS Rebinding可以通过让受害者的Web浏览器访问专用IP地址的机器并将结果返回给攻击者来破坏专用网络。 它也可以用于使用受害者机器发送垃圾邮件，分布式拒绝服务攻击（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-43548和CVE-2023-26492后续会有完整的复现过程文章，期待一下~
更多靶场实验练习、网安学习资料，请点击这里>>
浅析IM即时通讯开发移动端DNS域名劫持问题
对于互联网，域名是访问的第一跳，而这一跳很多时候会“失足”（尤其是移动端网络），导致访问错误内容、失败连接等，让用户在互联网上畅游的爽快瞬间消失。
而对于这关键的第一跳，包括鹅厂在内的国内互联网大厂，都在持续深入地研究和思考对策，本文将就鹅厂团队在这一块的技术实践，做一个深度的总结和技术分享，希望给大家带来些许启发。
但凡使用域名来给用户提供服务的互联网企业，都或多或少地无法避免在有中国特色的互联网环境中遭遇到各种域名被缓存、用户跨网访问缓慢等问题。那么对于腾讯这样的域名数量在10万级别的互联网公司来讲，域名解析异常的情况到底有多严重呢？
每天腾讯的分布式域名解析监测系统在不停地对全国所有的重点LocalDNS（指运营商的DNS服务）进行探测，腾讯域名在全国各地的日解析异常量是已经超过了80万条（这方面，来自移动端的异常尤为突出）。这给腾讯的业务带来了巨大的损失。为此腾讯建立了专业的团队与各个运营商进行了深度沟通，但是由于各种原因，处理效率及效果均不能达到腾讯各业务部门的需求。
除了和运营商进行沟通，有没有一种技术上的方案，能从根源上解决域名解析异常及用户访问跨网的问题呢？这是包括腾讯在内的很多国内互联网大厂技术团队一直在思考的问题。
首先，什么是DNS？
要想理解本文将要讨论的DNS各种问题，我们需要首先来复习一下DNS的基本原理和相关知识。
DNS的工作原理
DNS（Domain Name System，域名系统），DNS 服务用于在网络请求时，将域名转为 IP 地址。能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的 IP 数串。
传统的基于 UDP 协议的公共 DNS 服务极易发生 DNS 劫持，从而造成安全问题。
典型DNS域名系统的结构如下：
1）Root 域名：DNS 域名使用时，规定由尾部句号来指定名称位于根或更高级别的域层次结构；
2）Top Level 顶级域名：用来指示某个国家、地区或组织使用的名称的类型名称。如 .net；
3）Second Level 域名：个人或组织在 Internet 上使用的注册名称。如 52im.net；
4）Third Level 域名：已注册的二级域名派生的域名。如 docs.52im.net。
DNS的递归查询和迭代查询
递归查询：如果主机所询问的本地域名服务器不知道被查询域名的 IP 地址，那么本地域名服务器就以 DNS 客户的身份，向其他根域名服务器继续发出查询请求报文，而不是让该主机自己进行下一步的查询。
迭代查询：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的 IP 地址，要么告诉本地域名服务器：你下一步应当向哪一个域名服务器进行查询。然后让本地域名服务器进行后续的查询，而不是替本地域名服务器进行后续的查询。
由此可见，客户端到 Local DNS 服务器，Local DNS 与上级 DNS 服务器之间属于递归查询；DNS 服务器与根 DNS 服务器之前属于迭代查询。
实际环境中，因为采用递归模式会导致 DNS 服务器流量很大，所以现在大多数的 DNS 都是迭代模式。
国内移动端网络所面临的各种DNS杂症
总结下来，DNS的这些咋整主要的带来了三类问题：
1）LocalDNS劫持；
2）平均访问延迟下降；
3）用户连接失败率下降。
LocalDNS劫持: 由于HttpDNS是通过ip直接请求http获取服务器A记录地址，不存在向本地运营商询问domain解析过程，所以从根本避免了劫持问题。 （对于http内容tcp/ip层劫持，可以使用验证因子或者数据加密等方式来保证传输数据的可信度）即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询
平均访问延迟下降: 由于是ip直接访问省掉了一次domain解析过程，（即使系统有缓存速度也会稍快一些‘毫秒级’）通过智能算法排序后找到最快节点进行访问。
用户连接失败率下降: 通过算法降低以往失败率过高的服务器排序，通过时间近期访问过的数据提高服务器排序，通过历史访问成功记录提高服务器排序。如果ip(a)访问错误，在下一次返回ip(b)或者ip(c) 排序后的记录。
我们得先得了解下现在国内各ISP运营商的LocalDNS的基本情况。
国内运营商LocalDNS造成的这些问题，可以归为下以下3种原因：
域名缓存；
解析转发；
LocalDNS递归出口NAT。
下面，我们来逐一分析。
域名缓存
域名缓存很好理解，就是LocalDNS缓存了腾讯的域名的解析结果，不向腾讯权威DNS发起递归。
为何LocalDNS要把域名解析结果进行缓存呢？原因有以下几个：
1）保证用户访问流量在本网内消化：国内的各互联网接入运营商的带宽资源、网间结算费用、IDC机房分布、网内ICP资源分布等存在较大差异。为了保证网内用户的访问质量，同时减少跨网结算，运营商在网内搭建了内容缓存服务器，通过把域名强行指向内容缓存服务器的IP地址，就实现了把本地本网流量完全留在了本地的目的；
2）推送广告：有部分LocalDNS会把部分域名解析结果的所指向的内容缓存，并替换成第三方广告联盟的广告。
以上类型的行为就是我们常说的域名缓存，域名缓存会导致用户产生以下的访问异常：
A、仅对80端口的http服务做了缓存，如果域名是通过https协议或其它端口提供服务的，用户访问就会出现失败。比如支付服务、游戏通过指定端口连接connect server服务等；
B、缓存服务器的运维水平参差不齐，时有出现缓存服务器故障导致用户访问异常的问题。
解析转发
除了域名缓存以外，运营商的LocalDNS还存在解析转发的现象。解析转发是指运营商自身不进行域名递归解析，而是把域名解析请求转发到其它运营商的递归DNS上的行为。
而部分小运营商为了节省资源，就直接将解析请求转发到了其它运营的递归LocalDNS上去了：
这样的直接后果就是腾讯权威DNS收到的域名解析请求的来源IP就成了其它运营商的IP，最终导致用户流量被导向了错误的IDC，用户访问变慢。
LocalDNS递归出口NAT
LocalDNS递归出口NAT指的是运营商的LocalDNS按照标准的DNS协议进行递归，但是因为在网络上存在多出口且配置了目标路由NAT，结果导致LocalDNS最终进行递归解析的时候的出口IP就有概率不为本网的IP地址。
这样的直接后果就是GSLB DNS收到的域名解析请求的来源IP还是成了其它运营商的IP，最终导致用户流量被导向了错误的IDC，用户访问变慢。
以上是关于浅析DNS Rebinding的主要内容，如果未能解决你的问题，请参考以下文章