DNS缓存污染■文档编号■密级■版本编号1.1■日期2009-08-04©2009绿盟科技■版权声明本文中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属绿盟科技所有，受到有关产权及版权法保护。任何个人、机构未经绿盟科技的书面授权许可，不得以任何方式复制或引用本文的任何片断。■版本变更记录时间版本说明修改人2009-07-301.0初始版本陈庆2009-08-041.1应tt要求改动，更可读一些陈庆■适用性声明本模板用于撰写绿盟科技内外各种正式文件，包括技术手册、标书、白皮书、会议通知、公司制度等文档使用。目录DNS缓存污染1一.DNS体系简介11.1常见域名解析过程11.2常见DNS布署1二.DNS缓存污染22.1什么是DNS缓存污染22.2DNS缓存污染攻击所受限制32.3TransactionID32.4源端口42.5NAT对源端口随机化的干挠52.6生日攻击62.7ClassicGluePoison72.8BailywickCheck82.9KaminskiAttack82.10小结10三.参考资源10一.DNS体系简介一.1常见域名解析过程参看[RFC10344.3.1]，DNSServer必须支持迭代查询模式，可选支持递归查询模式。但在现实世界中几乎所有的DNSServer都支持递归查询模式，同时几乎所有的DNSClient都默认使用递归查询模式。图中的Step2被简化了，实际情形是ns1.sa.com依次访问根服务器、com的权威服务器、microsoft.com的权威服务器，每次都有DNS请求、响应发生，这个过程就是所谓迭代查询。一.2常见DNS布署常见DNS布署如下图([RFC10352.2]):RecursiveServer维护Centralcache，以此降低网络与相关服务器的负载([RFC10345.1])。二.DNS缓存污染二.1什么是DNS缓存污染在1.2中提到RecursiveServer维护Centralcache，就是将来自响应报文的各种RR以某种形式缓存起来，下次遇上StubResolver向自己发出请求时，先在本地缓存里寻找相应的RR，没有找到的情况下才向ForeignNameServer发出请求。Internet上攻击者有办法伪造一个报文，使之看起来像是从ForeignNameServer发往RecursiveServer的响应报文，其中包含的RR是攻击者指定的恶意内容，这样的RR被RecursiveServer接受并缓存，我们称之发生了DNS缓存污染。假设192.168.1.1是内网的DNSServer，客户机向192.168.1.1请求解析www.google.com，这个过程一般意味着请求解析www.google.com的ARR。攻击者可以通过缓存污染攻击使得192.168.1.1的缓存中出现"www.google.comA10.17.2.1"，结果所有使用192.168.1.1做DNSServer的客户机访问www.google.com时实际访问的是10.17.2.1。在缓存中置入伪造的ARR是最直接的攻击方式，还可以置入CNAMERR、NSRR、MXRR等各种RR，这完全取决于攻击者的最终目的。二.2DNS缓存污染攻击所受限制一般都是通过伪造DNS响应报文进行DNS缓存污染攻击。在设计DNS协议之初，并未专门考虑对抗这种类型的攻击，但一些协议方面的要求客观上起到了阻碍攻击的效果。分析响应报文时靠TransactionID判断是否与请求报文匹配([RFC10345.3.3])。收取响应报文后需要检查其是否与请求报文相匹配，建议先检查TransactionID是否匹配，再检查QuestionSection是否匹配([RFC10357.3])。如果没有请求报文与响应报文相匹配，响应报文不应被缓存。攻击者一般主动向CacheServer提交ARR查询请求，然后伪造AuthServer到CacheServer的ARR响应报文。这个过程要求伪造响应报文时必须指定正确的TransactionID，否则CacheServer认为响应报文无效，不予接受。除去DNS协议层TransactionID的限制外，还有一个UDP承载层的限制。CacheServer一般向AuthServer的53/UDP发送查询请求，假设这个请求报文的源端口是0x5121，AuthServer生成的响应报文其目标端口必然是0x5121/UDP。攻击者伪造响应报文时也必须将目标端口设为0x5121/UDP。如果攻击者可以嗅探、截获CacheServer与AuthServer之间的通信报文，就可以获知正确的TransactionID以及源端口号，但更多情况下攻击者不具备这个条件。二.3TransactionIDCacheServer接受DNS响应报文时要检查TransactionID是否匹配。早期有很多DNS实现发送请求报文时这个TransactionID是顺序递增的，这就使得攻击者很容易预测下一个ID值，类似早期TCPISN存在的问题。后来TransactionID字段开始随机化，攻击者只能穷举猜测ID值。1995年Bellowin最早提出了通过猜测TransactionID进行DNS欺骗的理论。攻击者要求CacheServer解析google.com，导致CacheServer向google.com的权威名字服务器发出查询请求，所用源端口固定为53/UDP，ID为12963。与此同时，攻击者向CacheServer发送大量伪造的响应报文，其中包含伪造的ARR(指向1.2.3.4)，响应报文的源端口、目标端口都等于53/UDP。响应报文中的ID值必须等于12963才能让CacheServer接受，攻击者不知道12963这个值，只能穷举猜测，发送大量伪造的响应报文就是为了指定不同的ID值，最多发送65536个伪造的响应报文分别指定[0,65535]上的各个值，总有一个会命中。TransactionID字段占16-bits，假设DNS实现用足了16-bits，攻击者平均猜测32768次会命中一次。但某些DNS实现只用了14-bits，平均猜测次数降至8192。二.4源端口支持递归解析的DNSServer向其它DNSServer发送请求时所用源PORT不易获知。绝大多数DNSServer会在启动时随机选取一个源PORT，以后向外发送请求时始终使用这个源PORT。还有一些DNSServer更蠢，向外发送请求时所用源PORT固定使用53(参2.3)。如果这个源PORT仅仅是初始时分随机确定，但随后就静态不变的话，任何在攻击者监视下的权威名字服务器都可用于获知这个源PORT，仅需一次正常的递归查询即可。假设攻击者控制了ns1.nsfocus.com，这是nsfocus.com的AuthServer，攻击者想知道192.168.1.1向外发送请求时所用源PORT，于是向192.168.1.1请求解析www.nsfocus.com，192.168.1.1会向ns1.nsfocus.com发送查询请求，攻击者在ns1.nsfocus.com上运行自己编写的DNSServer程序或者动用sniffer工具抓包，均可获知192.168.1.1所用源PORT。如果这个源PORT不是静态的，在变化中，攻击者就需要猜测这16-bits。考虑到小于1024的端口可能不被用于这个源PORT，平均猜测次数是32256。与2.3小节相比，这次攻击者必须同时穷举猜测TransactionID、源PORT。显然攻击难度加大。某些商用DNS实现，其请求报文的源端口范围太小，应该尽可能地扩大源端口取值范围。一般来说，源端口位于[1024,49152]是可以接受的。以前很少有DNSServer的这个源PORT不是静态的。二.5NAT对源端口随机化的干挠如果DNSServer位于NAT背后，NAT会干挠到由DNSServer发出的请求报文的源端口，很可能DNSServer自己随机化了源端口，但NAT减弱了其随机化程度。图中CacheServer随机化了源PORT(54132/UDP)，但DNS请求报文经过NAT设备后源PORT变成相对静态的1025/UDP。位于Internet一侧的攻击者伪造响应报文时只需指定目标端口为1025/UDP即可，NAT设备会自动转换成54132/UDP。二.6生日攻击如果DNSServer允许并发向外查询同一QNAME，就很容易遭致生日攻击。生日攻击的最简描述是，23个人中有两个人生日相同的概率接近1/2。1.2*k^0.5，k等于365时，前述结果约等于23。如果Attacker能迫使DNSServer并发请求同样的QuestionSection(QNAME、QTYPE、QCLASS)，就可以利用生日攻击原理对TransactionID、源PORT进行碰撞。如果简单套用前述公式的话(事实上不能简单套用)，k等于65536*65536，公式计算结果为78643，就是说同时发78643个响应报文，TransactionID、源PORT一起命中的概率接近1/2。同时发送更多的响应报文，TransactionID、源PORT一起命中的概率就更大。CERT#457875介绍了更多内容。图中攻击者向CacheServer并发请求解析同一QNAME，CacheServer也就向AuthServer并发请求解析同一QNAME，与此同时攻击者伪造大量响应报文以求产生TransactionID、源PORT碰撞。与2.4中单纯穷举猜测TransactionID、源PORT不同，此次来自CacheServer的查询请求有多个，而伪造的响应报文只要有一个被CacheServer接受就完成了攻击。目前Unbound和PowerDNS可以禁止并发向外查询同一QNAME。二.7ClassicGluePoison1997年出现了最早的关于DNS欺骗的安全公告，针对下述攻击:请求解析www.iss.net，响应报文给了正常的ARR，但在AdditionalSection中附带完全不相干的两个RR，这两个RR随AnswerSection中的ARR一起进入CacheServer的缓存。下次DNSClient向CacheServer请求解析www.paypal.com时，就会得到伪造的1.2.3.4。二.8BailywickCheck为了对付1997年出现的ClassicGluePoison，DNS实现进行了所谓的"BailywickCheck"。所谓"BailywickCheck"是指接受位于Authority、AdditionalSection中的RR时所进行的一种安全检查，比如QNAME是a.com，则仅当这些RR形如*.com时才接受，又比如QNAME是a.b.com，则仅当这些RR形如*.b.com时才接受。应用"BailywickCheck"之后，2.7中的攻击报文就无法进行缓存污染了，因为QNAME是www.iss.net，AdditionalSection中的RRowner不符合*.iss.net的要求。二.9KaminskiAttack2008年出现的KaminskiAttack是利用AdditionalSection进行的BlindDNSCachePoison攻击。攻击者先向CacheServer请求解析bogus12345.www.paypal.com，同时伪造响应报文进行缓存污染，与之前介绍的攻击一样，需要穷举猜测TransactionID、源PORT，有条件时可以利用生日攻击原理进行碰撞。这个响应报文没有利用AnswerSection，利用的是Authority、AdditionalSection，这次满足"BailywickCheck"，"www.paypal.comA1.2.3.4"被接受并缓存。如果攻击未得手，攻击者接着向CacheServer请求解析bogus12346.www.paypal.com，如此不断尝试直至攻击成功。过去的DNS缓存污染攻击有个麻烦。来自AuthServer的正常响应报文很可能先于攻击者伪造的响应报文到达CacheServer，这种情况下CacheServer只会接受先到达的正常响应报文，后续到达的伪造的响应报文无论其TransactionID、源PORT是否正确都不被接受。正常响应报文所携带的有效RR一旦进入CacheServer的缓存，在其过期前攻击者无法迫使CacheServer向AuthServer请求解析相应的RR，也就无法让伪造的响应报文派上用场。图中所用QNAME是bogus12345.www.paypal.com，是个不存在的RRowner，正常响应报文只会报告域名不存在，不会返回一个有效RR。DNS实现有一个可选支持项，允许缓存"否定"响应([RFC10344.3.4])，如果CacheServer不支持这个特性更好，那样缓存中完全没有干挠信息，攻击者可以持续攻击直至成功，而不必等待缓存中的有效RR过期。即使DNS实现支持缓存"否定"响应也无所谓，因为下一次请求解析的QNAME是bogus12346.www.paypal.com，缓存中只是说bogus12345.www.paypal.com不存在，此时CacheServer仍会向外发送查询请求。KaminskiAttack并未减少所需伪造的响应报文数量，但这种攻击缩短了攻击时间。2008年针对这种攻击出了一批分析文档，绝大多数都只盯着"源端口静态"的问题，认为DanKaminsky又在纯炒冷饭，现在看来这种攻击还是有可取之处的，只不过DanKaminsky这个人太爱作秀以致招人嫌了。二.10小结DNS缓存污染是一种历史悠久的攻击方式，至今有14个年头了。这个问题是DNS协议设计者最初没有想到的，由于设计上的缺陷以及多年应用带来的积重难返，在相当长的一段时间内这个问题都将始终存在并严重威胁着Internet。三.参考资源[1]DOMAINNAMES-CONCEPTSANDFACILITIESRFC882RFC1034http://www.ietf.org/rfc/rfc1034.txtDOMAINNAMES-IMPLEMENTATIONANDSPECIFICATIONRFC883RFC1035http://www.ietf.org/rfc/rfc1035.txt[2]TCP/IPIllustratedVolumeI:TheProtocols-W.RichardStevensInternetworkingWithTCP/IPVolI:Principles,Protocols,andArchitecture-DouglasE.Comer[3]http://www.cert.org/advisories/CA-1997-22.html[4]DefendingyourDNSinapost-Kaminskyworld-PaulWouters[2009-02]https://www.blackhat.com/presentations/bh-dc-09/Wouters/BlackHat-DC-09-Wouters-Post-Dan-Kaminsky-slides.pdfhttps://www.blackhat.com/presentations/bh-dc-09/Wouters/BlackHat-DC-09-Wouters-Post-Dan-Kaminsky.pdf[5]VariousDNSserviceimplementationsgeneratemultiplesimultaneousqueriesforthesameresourcerecord-[2002-11]http://www.kb.cert.org/vuls/id/457875BirthdayAttackhttp://mathworld.wolfram.com/BirthdayAttack.html[6]MultipleDNSimplementationsvulnerabletocachepoisoning-[2008-07]http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447http://www.kb.cert.org/vuls/id/800113[7]PatchyourDNSNOW-[2008-07-24]http://pandalabs.pandasecurity.com/archive/Patch-your-DNS-NOW_21002100210021002100_.aspxhttp://pandalabs.pandasecurity.com/blogs/images/PandaLabs/2008/07/24/dnstester.zip[8]BlackOps2008:It'sTheEndOfTheCacheAsWeKnowIt-DanKaminsky[2008]http://www.doxpara.com/DMK_BO2K8.ppt[9]DanKaminskyvulnerabilityDetailshttp://www.doxpara.com/?p=1185[10]DNSCachePoisoning-JoeStewart,GCIHhttp://www.lurhq.com/dnscache.pdf[11]PowerDNSRecursorDNSCachePoisoning-AmitKlein[2008-02]http://www.trusteer.com/powerdnsrecursorhttp://www.trusteer.com/files/PowerDNS_recursor_DNS_Cache_Poisoning.pdf[12]BlackOpsofDNSChaosCommunicationsCamp2003-DanKaminskyhttp://www.hackerz.ir/e-books/121%20Black%20Ops%20of%20DNS.pdf
详情Copyright © 2020