生日悖论普遍的应用于检测哈希函数:N-位长度的哈希表可能发生碰撞测试次数不是2N次而是只有2N/2次。这一结论被应用到破解密码学散列函数的生日攻击中生日问题所隐含的理论已经在[Schnabel 1938]名字叫做capture-recapture的统计试验得到应用,来估计湖里鱼的数量。
好,下面我们还是回到我的攻击测试上来,在上述的最为普遍的DNS欺骗攻击中,是在窃听(嗅探)网络以便得到来自X的ID号码,然后回复以相同的ID只是含有攻击者提供的IP。
就像我之前说的,这种攻击需要嗅探网络中的X生成的DNS数据。那这是不是意味着攻击者不能不用嗅探器实施攻击呢?
试着“猜猜”ID怎么样?
为什么不呢,但是ID号是用两字节构成的,这意味着有65535个可能的值!也就是说攻击者如果想要成功攻击的话,他要构造出65535个不同ID号的伪造回复,这样里面至少有且仅有一个包是可用的。
如果这样的攻击的话,我们需要相当好的带宽,而且最重要的是我们不知道何时发送伪造的回复。他就必须先知道对方有个请求,然后紧接着及时地(在真的来自DNS服务器的回复之前)发送回复。
让我们来从另一个角度看问题,我们知道是有可能性去直接麻痹DNS服务器的。回忆一下,攻击者是想DNS服务器询问解析www.attacker.net,多亏有从ns.attacker.net来的恶意记录zone transfer,攻击者才可以麻痹DNS服务器的高速缓存器。值得重提的是,这种攻击的局限在于攻击者必须在运行自己带有恶意记录的DNS服务器。
这样的分析之下,如果攻击者没有办法嗅探你的网络数据或者没有自己的服务器,是不是就是说你就远离DNS劫持技术了?
答案是,完全不是这样。
我之前提到过,DNS协议是用UDP回复,UDP是非连接状态的协议,是没有像TCP三次握手的过程的。所以,这也就使得可以非常容易地用你选的任意IP发送UDP包。所以为什么攻击者在可以从任意DNS服务器发送伪造包的情况下要辛辛苦苦地架设起自己地DNS服务器呢?他可以直接询问受害者的DNS服务器解析www.google.com,然后立即发送含伪造IP的包给www.google.com的域名服务器。
好,这样时间刚好,这样是可行的,所以问题就只有受害者的DNS服务器将要向ns.google.com发送一次请求来得到www.google.com的IP,同时有一个请求的ID号。所以又一次的,攻击者就必须发送65535个含ns.google.com的伪造包来做为受害者域名服务器的源地址。至少有一个包是吻合的。所以看来这个可能会成功。
下面就是最有趣的部分了……如果攻击者向受害者的DNS服务器发送了100份请求来解析www.google.com会发生什么呢?那么ns.victim.com也将会向ns.google.com发送100份请求,那然后如果我们发送100个从ns.google.com到ns.victim.com的伪造回复会怎样呢?如果你已经理解了刚刚提到的生日悖论原理,你就应该懂得相比之下冲撞(猜对)的概率已经有了可观的提高。
除此之外,还有个必须注意的小细节——源端口!
试想,ns.victim.com将要向ns.google.com发送请求,UDP头就应该像这样:
Source address : ns.victim.com
Destination address : ns.google.com
Source port : 1256 (choosed randomly and > 1024)
Destination port : 53 (DNS port)
Data : What is the IP of www.google.com?
很明显,攻击者必须ns.victim.com的源端口作为目标端口发送伪造的DNS回复,包的内容就像:
Source address : ns.google.com
Destination address : ns.victim.com
Source port : 53
Destination port : 1256
Data : The IP of www.google.com is 81.81.81.81
所以如果我们没有嗅探又要怎样猜测源端口呢?“不幸”的是,对大多数DNS服务器来说,源端口是不会为每个客户端而改变的,因此攻击者可以很简单地通过看 ns.victim.com的目前源端口来得到。比方说,如果他有一个域名服务器,他只要请求DNS查找他的域的一个站名,得到的返回查询包就会包含现在在的被ns.victim.com用来发送DNS请求的源端口。
好,现在我知道如何得到源端口了,你可能会对攻击的成功率好奇。这也是我正要讲的。我们的C代码也有所改动:
#define POSSIBILITIES 65535.0
void main (void)
{
float chances;
int i, j;
for (i = 0; i
结果如下:
Queries
50
100
150
200
250
300
350
400
500
550
650
750
Chances
0.0185
0.0728
0.1569
0.2621
0.3785
0.4961
0.6069
0.7048
0.8517
0.9008
0.9604
0.9865
我们可以看到,650个构造回复有0.960411的概率成功,近乎100%!
欲知更多详细信息,我建议阅读以下文章:
http://www.kb.cert.org/vuls/id/457875
http://www.securityfocus.com/guest/17905
D)总结
在这篇文章里,我用www.google.com做例子,并不是因为我真的对其的重定向攻击感兴趣。这个问题在你访问你的银行账户,在线购书网站甚至是网页电子邮件时尤为重要。
而对于网站管理者来说,可行的防范措施有:
对高速缓存器加以限制,保证不保留额外的记录。
不要用或依赖DNS构架安全体系。
使用SSL之类的加密技术,所以即使被攻击,难度也会加大
来源:
https://www.jb51.net/hack/5285.html
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!