DNS缓存污染.docx
《DNS缓存污染.docx》由会员分享，可在线阅读，更多相关《DNS缓存污染.docx（12页珍藏版）》请在冰点文库上搜索。
DNS缓存污染
nDNS缓存污染
■文档编号
■密级
■版本编号
■日期
2009-08-04
©2020绿盟科技
■版权声明
本文中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属绿盟科技所有，受到有关产权及版权法保护。
任何个人、机构未经绿盟科技的书面授权许可，不得以任何方式复制或引用本文的任何片断。
■版本变更记录
时间
版本
说明
修改人
2009-07-30
初始版本
陈庆
2009-08-04
应tt要求改动，更可读一些
陈庆
■适用性声明
本模板用于撰写绿盟科技内外各种正式文件，包括技术手册、标书、白皮书、会议通知、公司制度等文档使用。
一.DNS体系简介
一.1常见域名解析过程
参看[RFC1034，DNSServer必须支持迭代查询模式，可选支持递归查询模式。
但在现实世界中几乎所有的DNSServer都支持递归查询模式，同时几乎所有的DNSClient都默认使用递归查询模式。
图中的Step2被简化了，实际情形是依次访问根服务器、com的权威服务器、的权威服务器，每次都有DNS请求、响应发生，这个过程就是所谓迭代查询。
一.2常见DNS布署
常见DNS布署如下图（[RFC1035]）:
RecursiveServer维护Centralcache，以此降低网络与相关服务器的负载（[RFC1034]）。
二.DNS缓存污染
二.1什么是DNS缓存污染
在中提到RecursiveServer维护Centralcache，就是将来自响应报文的各种RR以某种形式缓存起来，下次遇上StubResolver向自己发出请求时，先在本地缓存里寻找相应的RR，没有找到的情况下才向ForeignNameServer发出请求。
Internet上攻击者有办法伪造一个报文，使之看起来像是从ForeignNameServer发往RecursiveServer的响应报文，其中包含的RR是攻击者指定的恶意内容，这样的RR被RecursiveServer接受并缓存，我们称之发生了DNS缓存污染。
假设是内网的DNSServer，客户机向请求解析，这个过程一般意味着请求解析的ARR。
攻击者可以通过缓存污染攻击使得的缓存中出现"A"，结果所有使用做DNSServer的客户机访问时实际访问的是。
在缓存中置入伪造的ARR是最直接的攻击方式，还可以置入CNAMERR、NSRR、MXRR等各种RR，这完全取决于攻击者的最终目的。
二.2DNS缓存污染攻击所受限制
一般都是通过伪造DNS响应报文进行DNS缓存污染攻击。
在设计DNS协议之初，并未专门考虑对抗这种类型的攻击，但一些协议方面的要求客观上起到了阻碍攻击的效果。
分析响应报文时靠TransactionID判断是否与请求报文匹配（[RFC1034。
收取响应报文后需要检查其是否与请求报文相匹配，建议先检查TransactionID是否匹配，再检查QuestionSection是否匹配（[RFC1035]）。
如果没有请求报文与响应报文相匹配，响应报文不应被缓存。
攻击者一般主动向CacheServer提交ARR查询请求，然后伪造AuthServer到CacheServer的ARR响应报文。
这个过程要求伪造响应报文时必须指定正确的TransactionID，否则CacheServer认为响应报文无效，不予接受。
除去DNS协议层TransactionID的限制外，还有一个UDP承载层的限制。
CacheServer一般向AuthServer的53/UDP发送查询请求，假设这个请求报文的源端口是0x5121，AuthServer生成的响应报文其目标端口必然是0x5121/UDP。
攻击者伪造响应报文时也必须将目标端口设为0x5121/UDP。
如果攻击者可以嗅探、截获CacheServer与AuthServer之间的通信报文，就可以获知正确的TransactionID以及源端口号，但更多情况下攻击者不具备这个条件。
二.3TransactionID
CacheServer接受DNS响应报文时要检查TransactionID是否匹配。
早期有很多DNS实现发送请求报文时这个TransactionID是顺序递增的，这就使得攻击者很容易预测下一个ID值，类似早期TCPISN存在的问题。
后来TransactionID字段开始随机化，攻击者只能穷举猜测ID值。
1995年Bellowin最早提出了通过猜测TransactionID进行DNS欺骗的理论。
攻击者要求CacheServer解析，导致CacheServer向的权威名字服务器发出查询请求，所用源端口固定为53/UDP，ID为12963。
与此同时，攻击者向CacheServer发送大量伪造的响应报文，其中包含伪造的ARR（指向，响应报文的源端口、目标端口都等于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（参。
如果这个源PORT仅仅是初始时分随机确定，但随后就静态不变的话，任何在攻击者监视下的权威名字服务器都可用于获知这个源PORT，仅需一次正常的递归查询即可。
假设攻击者控制了，这是的AuthServer，攻击者想知道向外发送请求时所用源PORT，于是向请求解析，会向发送查询请求，攻击者在上运行自己编写的DNSServer程序或者动用sniffer工具抓包，均可获知所用源PORT。
如果这个源PORT不是静态的，在变化中，攻击者就需要猜测这16-bits。
考虑到小于1024的端口可能不被用于这个源PORT，平均猜测次数是32256。
与小节相比，这次攻击者必须同时穷举猜测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。
*k^，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碰撞。
与中单纯穷举猜测TransactionID、源PORT不同，此次来自CacheServer的查询请求有多个，而伪造的响应报文只要有一个被CacheServer接受就完成了攻击。
目前Unbound和PowerDNS可以禁止并发向外查询同一QNAME。
二.7ClassicGluePoison
1997年出现了最早的关于DNS欺骗的安全公告，针对下述攻击:
请求解析，响应报文给了正常的ARR，但在AdditionalSection中附带完全不相干的两个RR，这两个RR随AnswerSection中的ARR一起进入CacheServer的缓存。
下次DNSClient向CacheServer请求解析时，就会得到伪造的。
二.8BailywickCheck
为了对付1997年出现的ClassicGluePoison，DNS实现进行了所谓的"BailywickCheck"。
所谓"BailywickCheck"是指接受位于Authority、AdditionalSection中的RR时所进行的一种安全检查，比如QNAME是，则仅当这些RR形如*时才接受，又比如QNAME是，则仅当这些RR形如*.时才接受。
应用"BailywickCheck"之后，中的攻击报文就无法进行缓存污染了，因为QNAME是，AdditionalSection中的RRowner不符合*.的要求。
二.9KaminskiAttack
2008年出现的KaminskiAttack是利用AdditionalSection进行的BlindDNSCachePoison攻击。
攻击者先向CacheServer请求解析，同时伪造响应报文进行缓存污染，与之前介绍的攻击一样，需要穷举猜测TransactionID、源PORT，有条件时可以利用生日攻击原理进行碰撞。
这个响应报文没有利用AnswerSection，利用的是Authority、AdditionalSection，这次满足"BailywickCheck"，"A"被接受并缓存。
如果攻击未得手，攻击者接着向CacheServer请求解析，如此不断尝试直至攻击成功。
过去的DNS缓存污染攻击有个麻烦。
来自AuthServer的正常响应报文很可能先于攻击者伪造的响应报文到达CacheServer，这种情况下CacheServer只会接受先到达的正常响应报文，后续到达的伪造的响应报文无论其TransactionID、源PORT是否正确都不被接受。
正常响应报文所携带的有效RR一旦进入CacheServer的缓存，在其过期前攻击者无法迫使CacheServer向AuthServer请求解析相应的RR，也就无法让伪造的响应报文派上用场。
图中所用QNAME是，是个不存在的RRowner，正常响应报文只会报告域名不存在，不会返回一个有效RR。
DNS实现有一个可选支持项，允许缓存"否定"响应（[RFC1034，如果CacheServer不支持这个特性更好，那样缓存中完全没有干挠信息，攻击者可以持续攻击直至成功，而不必等待缓存中的有效RR过期。
即使DNS实现支持缓存"否定"响应也无所谓，因为下一次请求解析的QNAME是，缓存中只是说不存在，此时CacheServer仍会向外发送查询请求。
KaminskiAttack并未减少所需伪造的响应报文数量，但这种攻击缩短了攻击时间。
2008年针对这种攻击出了一批分析文档，绝大多数都只盯着"源端口静态"的问题，认为DanKaminsky又在纯炒冷饭，现在看来这种攻击还是有可取之处的，只不过DanKaminsky这个人太爱作秀以致招人嫌了。
二.10小结
DNS缓存污染是一种历史悠久的攻击方式，至今有14个年头了。
这个问题是DNS协议设计者最初没有想到的，由于设计上的缺陷以及多年应用带来的积重难返，在相当长的一段时间内这个问题都将始终存在并严重威胁着Internet。
三.参考资源
[1]DOMAINNAMES-CONCEPTSANDFACILITIES
RFC882
RFC1034
DOMAINNAMES-IMPLEMENTATIONANDSPECIFICATION
RFC883
RFC1035
2]TCP/IPIllustratedVolumeI:
TheProtocols-W.RichardStevens
InternetworkingWithTCP/IPVolI:
Principles,Protocols,andArchitecture-DouglasE.Comer
[3]4]DefendingyourDNSinapost-Kaminskyworld-PaulWouters>[2009-02]
5]VariousDNSserviceimplementationsgeneratemultiplesimultaneousqueriesforthesameresourcerecord-[2002-11]
BirthdayAttack
6]MultipleDNSimplementationsvulnerabletocachepoisoning-[2008-07]
7]PatchyourDNSNOW-[2008-07-24]
8]BlackOps2008:
It'sTheEndOfTheCacheAsWeKnowIt-DanKaminsky[2008]
9]DanKaminskyvulnerabilityDetails
DNSCachePoisoning-JoeStewart,GCIH>
PowerDNSRecursorDNSCachePoisoning-AmitKlein[2008-02]
BlackOpsofDNSChaosCommunicationsCamp2003-DanKaminsky
升级会员 