DNS缓存污染.doc

nDNS缓存污染 文档编号 密级 版本编号1.1 日期2009-08-04 2020 绿盟科技 版权声明本文中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属绿盟科技所有，受到有关产权及版权法保护。任何个人、机构未经绿盟科技的书面授权许可，不得以任何方式复制或引用本文的任何片断。 版本变更记录时间版本说明修改人2009-07-301.0初始版本陈庆2009-08-041.1应tt要求改动，更可读一些陈庆 适用性声明本模板用于撰写绿盟科技内外各种正式文件，包括技术手册、标书、白皮书、会议通知、公司制度等文档使用。 目录nDNS缓存污染1一.DNS体系简介11.1常见域名解析过程11.2常见DNS布署1二.DNS缓存污染22.1什么是DNS缓存污染22.2DNS缓存污染攻击所受限制32.3Transaction ID32.4源端口42.5NAT对源端口随机化的干挠52.6生日攻击62.7Classic Glue Poison72.8Bailywick Check82.9Kaminski Attack82.10小结10三.参考资源10- I -DNS缓存污染一. DNS体系简介1.1 常见域名解析过程参看RFC 1034 4.3.1，DNS Server必须支持迭代查询模式，可选支持递归查询模式。但在现实世界中几乎所有的DNS Server都支持递归查询模式，同时几乎所有的DNS Client都默认使用递归查询模式。图中的Step 2被简化了，实际情形是依次访问根服务器、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缓存污染。假设是内网的DNS Server，客户机向请求解析，这个过程一般意味着请求解析的A RR。攻击者可以通过缓存污染攻击使得的缓存中出现 A ，结果所有使用做DNS Server的客户机访问时实际访问的是。在缓存中置入伪造的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到Cache Server的A RR响应报文。这个过程要求伪造响应报文时必须指定正确的Transaction ID，否则Cache Server认为响应报文无效，不予接受。除去DNS协议层Transaction ID的限制外，还有一个UDP承载层的限制。Cache Server一般向Auth Server的53/UDP发送查询请求，假设这个请求报文的源端口是0x5121，Auth Server生成的响应报文其目标端口必然是0x5121/UDP。攻击者伪造响应报文时也必须将目标端口设为0x5121/UDP。如果攻击者可以嗅探、截获Cache Server与Auth Server之间的通信报文，就可以获知正确的Transaction ID以及源端口号，但更多情况下攻击者不具备这个条件。2.3 Transaction IDCache Server接受DNS响应报文时要检查Transaction ID是否匹配。早期有很多DNS实现发送请求报文时这个Transaction ID是顺序递增的，这就使得攻击者很容易预测下一个ID值，类似早期TCP ISN存在的问题。后来Transaction ID字段开始随机化，攻击者只能穷举猜测ID值。1995年Bellowin最早提出了通过猜测Transaction ID进行DNS欺骗的理论。攻击者要求Cache Server解析，导致Cache Server向的权威名字服务器发出查询请求，所用源端口固定为53/UDP，ID为12963。与此同时，攻击者向Cache Server发送大量伪造的响应报文，其中包含伪造的A RR(指向)，响应报文的源端口、目标端口都等于53/UDP。响应报文中的ID值必须等于12963才能让Cache Server接受，攻击者不知道12963这个值，只能穷举猜测，发送大量伪造的响应报文就是为了指定不同的ID值，最多发送65536个伪造的响应报文分别指定0,65535上的各个值，总有一个会命中。Transaction ID字段占16-bits，假设DNS实现用足了16-bits，攻击者平均猜测32768次会命中一次。但某些DNS实现只用了14-bits，平均猜测次数降至8192。2.4 源端口支持递归解析的DNS Server向其它DNS Server发送请求时所用源PORT不易获知。绝大多数DNS Server会在启动时随机选取一个源PORT，以后向外发送请求时始终使用这个源PORT。还有一些DNS Server更蠢，向外发送请求时所用源PORT固定使用53(参2.3)。如果这个源PORT仅仅是初始时分随机确定，但随后就静态不变的话，任何在攻击者监视下的权威名字服务器都可用于获知这个源PORT，仅需一次正常的递归查询即可。假设攻击者控制了，这是的Auth Server，攻击者想知道向外发送请求时所用源PORT，于是向请求解析，会向发送查询请求，攻击者在上运行自己编写的DNS Server程序或者动用sniffer工具抓包，均可获知所用源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*k0.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介绍了更多内容。图中攻击者向Cache Server并发请求解析同一QNAME，Cache Server也就向Auth Server并发请求解析同一QNAME，与此同时攻击者伪造大量响应报文以求产生Transaction ID、源PORT碰撞。与2.4中单纯穷举猜测Transaction ID、源PORT不同，此次来自Cache Server的查询请求有多个，而伪造的响应报文只要有一个被Cache Server接受就完成了攻击。目前Unbound和PowerDNS可以禁止并发向外查询同一QNAME。2.7 Classic Glue Poison1997年出现了最早的关于DNS欺骗的安全公告，针对下述攻击:请求解析，响应报文给了正常的A RR，但在Additional Section中附带完全不相干的两个RR，这两个RR随Answer Section中的A RR一起进入Cache Server的缓存。下次DNS Client向Cache Server请求解析时，就会得到伪造的。2.8 Bailywick Check为了对付1997年出现的Classic Glue Poison，DNS实现进行了所谓的Bailywick Check。所谓Bailywick Check是指接受位于Authority、Additional Section中的RR时所进行的一种安全检查，比如QNAME是，则仅当这些RR形如*.com时才接受，又比如QNAME是，则仅当这些RR形如*.时才接受。应用Bailywick Check之后，2.7中的攻击报文就无法进行缓存污染了，因为QNAME是，Additional Section中的RR owner不符合*.的要求。2.9 Kaminski Attack2008年出现的Kaminski Attack是利用Additional Section进行的Blind DNS Cache Poison攻击。攻击者先向Cache Server请求解析，同时伪造响应报文进行缓存污染，与之前介绍的攻击一样，需要穷举猜测Transaction ID、源PORT，有条件时可以利用生日攻击原理进行碰撞。这个响应报文没有利用Answer Section，利用的是Authority、Additional Section，这次满足Bailywick Check， A 被接受并缓存。如果攻击未得手，攻击者接着向Cache Server请求解析，如此不断尝试直至攻击成功。过去的DNS缓存污染攻击有个麻烦。来自Auth Server的正常响应报文很可能先于攻击者伪造的响应报文到达Cache Server，这种情况下Cache Server只会接受先到达的正常响应报文，后续到达的伪造的响应报文无论其Transaction ID、源PORT是否正确都不被接受。正常响应报文所携带的有效RR一旦进入Cache Server的缓存，在其过期前攻击者无法迫使Cache Server向Auth Server请求解析相应的RR，也就无法让伪造的响应报文派上用场。图中所用QNAME是，是个不存在的RR owner，正常响应报文只会报告域名不存在，不会返回一个有效RR。DNS实现有一个可选支持项，允许缓存否定响应(RFC 1034 4.3.4)，如果Cache Server不支持这个特性更好，那样缓存中完全没有干挠信息，攻击者可以持续攻击直至成功，而不必等待缓存中的有效RR过期。即使DNS实现支持缓存否定响应也无所谓，因为下一次请求解析的QNAME是，缓存中只是说不存在，此时Cache Server仍会向外发送查询请求。Kaminski Attack并未减少所需伪造的响应报文数量，但这种攻击缩短了攻击时间。2008年针对这种攻击出了一批分析文档，绝大多数都只盯着源端口静态的问题，认为Dan Kaminsky又在纯炒冷饭，现在看来这种攻击还是有可取之处的，只不过Dan Kaminsky这个人太爱作秀以致招人嫌了。2.10 小结DNS缓存污染是一种历史悠久的攻击方式，至今有14个年头了。这个问题是DNS协议设计者最初没有想到的，由于设计上的缺陷以及多年应用带来的积重难返，在相当长的一段时间内这个问题都将始终存在并严重威胁着Internet。三. 参考资源 1 DOMAIN NAMES - CONCEPTS AND FACILITIES RFC 882 RFC 1034 /rfc/rfc1034.txt DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION RFC 883 RFC 1035 /rfc/rfc1035.txt 2 TCP/IP Illustrated Volume I: The Protocols - W. Richard Stevens Internetworking With TCP/IP Vol I: Principles,Protocols,and Architecture - Douglas E. Comer 3 /advisories/CA-1997-22.html 4 Defending your DNS in a post-Kaminsky world - Paul Wouters 2009-02 /presentations/bh-dc-09/Wouters/BlackHat-DC-09-Wouters-Post-Dan-Kaminsky-slides.pdf /presentations/bh-dc-09/Wouters/BlackHat-DC-09-Wouters-Post-Dan-Kaminsky.pdf 5 Various DNS service implementations generate multiple simultaneous queries for the same resource record - 2002-11 /vuls/id/457875 Birthday Attack /BirthdayAttack.html 6 Multiple DNS implementations vulnerable to cache poisoning - 2008-07 /cgi-bin/cvename.cgi?name=CVE-2008-1447 /vuls/id/800