在用户验证他们有域名控制权后，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放大攻击。

为了进行实践分析，我需要一个不做这种过滤的主机，此外，攻击主机和受害者之间的延迟必须尽可能地低，以最大限度地提高在真正的应答之前收到的虚假响应的机会。