本文讲的是
通过DNS响应欺骗来绕过域控制验证,
在用户验证他们有域名控制权后,Detectify才会扫描这个网站。其中一个验证方法是向域添加一个DNS TXT记录,其中包含由Detectify提供的字符串。当用户进行验证时,Detectify将执行DNS查询并检查相应字符串。让我们来看看它是如何通过 DNS 响应欺骗来绕过域控制验证。
译者注:Detectify是基于SaaS网站安全扫描工具,是一个免费的帮助站长们发现网站漏洞的安全扫描应用工具,通过该工具来扫描网站的安全性能。
DNS欺骗
DNS查询和响应通常是通过UDP发送的,因此攻击者可以使用IP地址欺骗,向来查询的DNS服务器的客户端发送DNS响应。当然,如果用户的设备能匹配未处理的查询,则只接受响应。具体来说,以下字段必须匹配:
1.源(DNS服务器)IP地址
2.目的地(DNS客户端)IP地址
3.源(DNS服务器)端口-总是53
4.目的地(DNS客户端)端口——DNS请求的源端口
5.“事务ID”——由客户机生成的16位数字
6.“问题”——本质上是DNS查询的副本
已知源端口、源IP和目的地IP。DNS“问题”通常可以被猜到,甚至可以从真正的查询中复制出来,如果攻击者能够访问它的话,唯一未知的字段就剩目标端口和事务ID了。
大约9年前,许多DNS客户端使用了一个固定的或容易预测的源端口或事务ID或两者都使用。这样,虽然有65536个可能,但猜测一个16位的数字还是完全可行的,而攻击者可以在实际响应到达之前,将数千个虚假的响应包发送到DNS客户端。在2008年7月,Dan Kaminsky揭示了这个问题,在问题被披露后,DNS实现被快速修补以使用真正随机的事务id和端口号,同时各大厂商也开始采用DNSSEC协议。
对验证器的验证
为了避免任何缓存的影响,Detectify的验证器可能会执行自己的DNS查询,而不是只使用操作系统的DNS解析器。如果是这样,它仍然可以使用可预测的事务ID或少量的源端口。
为了测试这一点,我建立了一个简单的nameserver,使用dnsmasq来控制一个域,并使用tcpdump来捕获它的流量,因为我多次尝试在Detectify站点上验证它。在Wireshark中打开结果捕获文件显示,确实有一个DNS查询来自scanner.detectify.com。源端口看上去足够随机,但是事务ID在哪里?
它是零!事务ID每次都为零,由于我知道准确的查询Detectify发送,所以欺骗正确的响应只是猜测源端口的问题。
POC
现在,让我们来验证一下example.com。创建一个欺骗的DNS响应有效载荷很简单,采取真正的响应,由tcpdump捕获,并手动更改域名。nping可以用来发送这个响应,欺骗源IP和端口:
nping --udp -g 53 -p 30000-39999 -S 199.43.133.53 -c 100 --rate 100000 -N -H --data 000085000001000100000000076578616d706c650000100001c00c00100001000000010038376465746563746966792d766572696669636174696f6e3d6530363663623430643165353234323362613661646539393562613433636663 scanner.detectify.com
上面的命令会尝试发送假的DNS响应,从199.43.133.53(example.com的真实名称)到scanner . detectify.com,源端口在30000到39999之间循环。现在这个问题就很简单了,只需在我的笔记本电脑上运行,在Detectify的网站上反复点击验证即可。
IP欺骗的用途
几乎所有的isp和数据中心今天都进行了出口过滤,以防止欺骗的数据包脱离他们的网络。所以,IP欺骗最常见的用途是DDOS攻击,特别是DNS放大攻击。
为了进行实践分析,我需要一个不做这种过滤的主机,此外,攻击主机和受害者之间的延迟必须尽可能地低,以最大限度地提高在真正的应答之前收到的虚假响应的机会。
原文发布时间为:2017年9月15日
本文作者:xiaohui
本文来自云栖社区合作伙伴嘶吼,了解相关信息可以关注嘶吼网站。