报文DNS缓存污染

DNS缓存污染

■文档编号 ■密级

■版本编号 1. 1 ■ 日期 2009-08-04

©2014绿盟科技

■版权声明

本文中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容除另有特别注明版权均属绿盟科技所有受到有关产权及版权法保护。任何个人、机构未经绿盟科技的书面授权许可不得以任何方式复制或引用本文的任何片断。

■版本变更记录

时间 版本 说明 修改人

2009-07-30 1.0 初始版本 陈庆

2009-08-04 1. 1 应tt要求改动更可读一些 陈庆

■适用性声明

本模板用于撰写绿盟科技内外各种正式文件包括技术手册、标书、 白皮书、会议通知、公司制度等文档使用。

DNS缓存污染........................................................................................................................1

一. DNS体系简介........................................................................................................................1

1. 1 常见域名解析过程. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

1.2 常见DNS布署. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

二. DNS缓存污染........................................................................................................................2

2. 1 什么是DNS缓存污染. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

2.2 DNS缓存污染攻击所受限制. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

2. 3 Transaction ID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

2.4 源端口. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

2. 5 NAT对源端口随机化的干挠. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

2.6 生日攻击. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

2. 7 Classic Glue Poison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

2.8 Bailywick Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

2.9 Kaminski Attack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

2. 10 小结. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

三. 参考资源..............................................................................................................................10

一. DNS体系简介

1. 1常见域名解析过程

参看[RFC 1034 4.3. 1]  DNS Server必须支持迭代查询模式可选支持递归查询模式。但在现实世界中几乎所有的DNS Server都支持递归查询模式 同时几乎所有的DNS Client都默认使用递归查询模式。

图中的Step 2被简化了实际情形是ns1. sa.com依次访问根服务器、 com的权威服务器、microsoft.com的权威服务器每次都有DNS请求、响应发生这个过程就是所谓迭代查询。

1.2常见DNS布署

常见DNS布署如下图([RFC 1035 2.2]) :

Recursive Server维护Central cache 以此降低网络与相关服务器的负载([RFC 1034

5. 1] ) 。

二. DNS缓存污染

2. 1什么是DNS缓存污染

在1.2中提到Recursive Server维护Central cache就是将来自响应报文的各种RR以某种形式缓存起来下次遇上Stub Resolver向自己发出请求时先在本地缓存里寻找相应的RR没有找到的情况下才向Foreign Name Server发出请求。

Internet上攻击者有办法伪造一个报文使之看起来像是从Foreign Name Server发往Recursive Server的响应报文其中包含的RR是攻击者指定的恶意内容这样的RR被Recursive Server接受并缓存我们称之发生了DNS缓存污染。

假设192. 168. 1. 1是内网的DNS Server客户机向192. 168. 1. 1请求解析www.google.com这个过程一般意味着请求解析www.google.com的A RR。攻击者可以通过缓存污染攻击使得

192. 168. 1. 1的缓存中出现"www.google.com A 10. 17.2. 1"结果所有使用192. 168. 1. 1做DNS Server的客户机访问www.google.com时实际访问的是10. 17.2. 1。

在缓存中置入伪造的A RR是最直接的攻击方式还可以置入CNAME RR、 NS RR、 MX RR等各种RR这完全取决于攻击者的最终目的。

2.2 DNS缓存污染攻击所受限制

一般都是通过伪造DNS响应报文进行DNS缓存污染攻击。在设计DNS协议之初并未专门考虑对抗这种类型的攻击但一些协议方面的要求客观上起到了阻碍攻击的效果。

分析响应报文时靠Transaction ID判断是否与请求报文匹配( [RFC 1034 5.3.3] ) 。

收取响应报文后需要检查其是否与请求报文相匹配建议先检查Transaction ID是否匹配再检查Question Section是否匹配([RFC 1035 7.3] ) 。

如果没有请求报文与响应报文相匹配 响应报文不应被缓存。

攻击者一般主动向Cache Server提交A RR查询请求然后伪造Auth Server到CacheServer的A RR响应报文。这个过程要求伪造响应报文时必须指定正确的Transaction ID否则Cache Server认为响应报文无效不予接受。

除去DNS协议层Transaction ID的限制外还有一个UDP承载层的限制。 Cache Server一般向Auth Server的53/UDP发送查询请求假设这个请求报文的源端口是0x5121 AuthServer生成的响应报文其目标端口必然是0x5121/UDP。攻击者伪造响应报文时也必须将目标端口设为0x5121/UDP。

如果攻击者可以嗅探、截获Cache Server与Auth Server之间的通信报文就可以获知正确的Transaction ID以及源端口号但更多情况下攻击者不具备这个条件。

2. 3 Transaction ID

Cache Server接受DNS响应报文时要检查Transaction ID是否匹配。

早期有很多DNS实现发送请求报文时这个Transaction ID是顺序递增的这就使得攻击者很容易预测下一个ID值类似早期TCP ISN存在的问题。

后来Transaction ID字段开始随机化攻击者只能穷举猜测ID值。

1995年Bellowin最早提出了通过猜测Transaction ID进行DNS欺骗的理论。

攻击者要求Cache Server解析google.com导致Cache Server向google.com的权威名字服务器发出查询请求所用源端口固定为53/UDP ID为12963。与此同时攻击者向CacheServer发送大量伪造的响应报文其中包含伪造的ARR(指向1.2.3.4)  响应报文的源端口、目标端口都等于53/UDP。响应报文中的ID值必须等于12963才能让Cache Server接受攻击者不知道12963这个值只能穷举猜测发送大量伪造的响应报文就是为了指定不同的ID值最多发送65536个伪造的响应报文分别指定[0,65535]上的各个值总有一个会命中。

Transaction ID字段占16-bits假设DNS实现用足了16-bits攻击者平均猜测32768次会命中一次。但某些DNS实现只用了14-b i t s平均猜测次数降至8192。

2.4源端口

支持递归解析的DNS Server向其它DNS Server发送请求时所用源PORT不易获知。

绝大多数DNS Server会在启动时随机选取一个源PORT 以后向外发送请求时始终使用这个源PORT。还有一些DNS Server更蠢 向外发送请求时所用源PORT固定使用53(参2.3) 。

如果这个源PORT仅仅是初始时分随机确定但随后就静态不变的话任何在攻击者监视下的权威名字服务器都可用于获知这个源PORT仅需一次正常的递归查询即可。假设攻击者控制了ns1.nsfocus.com这是nsfocus.com的Auth Server攻击者想知道192. 168. 1. 1向外发送请求时所用源PORT于是向192. 168. 1. 1请求解析www.nsfocus.com 192. 168. 1. 1会向ns1.nsfocus.com发送查询请求攻击者在ns1.nsfocus.com上运行自己编写的DNS Server程序或者动用sniffer工具抓包均可获知192. 168. 1. 1所用源PORT。

如果这个源PORT不是静态的在变化中攻击者就需要猜测这16-bits。考虑到小于1024的端口可能不被用于这个源PORT平均猜测次数是32256。

与2.3小节相比这次攻击者必须同时穷举猜测Transaction ID、源PORT。显然攻击难度加大。

某些商用DNS实现其请求报文的源端口范围太小应该尽可能地扩大源端口取值范围。一般来说源端口位于[1024,49152]是可以接受的。

以前很少有DNS Server的这个源PORT不是静态的。

2. 5 NAT对源端口随机化的干挠

如果DNS Server位于NAT背后 NAT会干挠到由DNS Server发出的请求报文的源端口很可能DNS Server自己随机化了源端口但NAT减弱了其随机化程度。

图中Cache Server随机化了源PORT(54132/UDP) 但DNS请求报文经过NAT设备后源PORT变成相对静态的1025/UDP。位于Internet一侧的攻击者伪造响应报文时只需指定目标端口为1025/UDP即可 NAT设备会自动转换成54132/UDP。

2.6生日攻击

如果DNS Server允许并发向外查询同一QNAME就很容易遭致生日攻击。

生日攻击的最简描述是 23个人中有两个人生日相同的概率接近1/2。

1.2*k^0. 5 k等于365时前述结果约等于23。

如果Attacker能迫使DNS Server并发请求同样的Question Section(QNAME、 QTYPE、QCLASS) 就可以利用生日攻击原理对Transaction ID、源PORT进行碰撞。

如果简单套用前述公式的话(事实上不能简单套用)  k等于65536*65536公式计算结果为78643就是说同时发78643个响应报文 Transaction ID、源PORT一起命中的概率接近1/2。 同时发送更多的响应报文 Transaction ID、源PORT一起命中的概率就更大。

CERT #457875介绍了更多内容。