DNS原理、脆弱性与域名劫持案例
《计算机网络安全与应用》贺思德 申浩如 科学出版社 2007 http://netsecurity.ynu.edu.cn 网络安全案例分析DNS 原理、脆弱性与域名劫持案例贺思德 谢利东 sd
《计算机网络安全与应用》贺思德 申浩如 科学出版社 2007 http://netsecurity.ynu.edu.cn 网络安全案例分析
DNS 原理、脆弱性与域名劫持案例
贺思德 谢利东 sdhe@ynu.edu.cn 2008-10-30 【未完¥章】
摘要 摘要 域名服务系统DNS 是互联网中一个庞大的分布式数据库系统,它有两个重要的作用:一是为网络用户访问Web 服务器等信息系统时提供网站域名与IP 地址的转换查询,二是为电子邮件系统的传输提供路由信息。本文内容:((1)以一个本地DNS 查询过程的数据分析介绍其工作原理,((2)用2008年8月发生于国内互联网上的一个DNS 劫持案例,介绍淫秽网站如何利用DNS 系统的漏洞来进行域名劫持,并使用超长的URL 来逃避互联网搜索引擎和公安网络监察部门的搜索,将大量的互联网用户的DNS 查询劫持连接到淫秽网站上,以提高其访问量。((3)分析了DNS 协议固有的脆弱性,微软的Windows 等商用系统的漏洞,最后给出了如何在DNS 系统中增强安全性的解决方案。
说明:说明:第一个DNS 案例属于本地解析,因为查询的授权域名记录就在本地DNS 服务器上。如果要查询的域名不在本地DNS 服务器中时,可以采用递归解析和迭代解析两种方式进行自动转发。第二个域名劫持案例产生于互联网DNS 系统的递归解析过程中,详细的背景知识参看页眉教材的第6.1.3节。分析软件工具Wireshark 和使用方法可从页眉的网站下载。
¥.1 .1 DNS 域名查询服务数据域名查询服务数据分析服务数据分析 分析
【实验目的】
理解DNS(Domain Name System)域名服务器如何处理来自客户机的域名解析请求。
通过实际案例分析DNS 如何进行查询和响应。
【实验内容】
1.利用客户机访问云南大学VOD 视频点播服务器vod.ynu.edu.cn,同时用客户机上安装的网络协议分析软件Wireshark 捕获通信时的数据。
2.分析DNS 客户机/服务器之间的通信过程。
3.分析查询数据包和响应数据包的结构和详细内容。
【实验原理】
参看教材第6.1节(P179)和第7章第2节相关内容(P236)。图¥.1为DNS

























查询步骤图。
图¥.1 DNS域名查询过程
【实验步骤】
1.启动客户机上安装的Wireshark 软件,执行Capture → Interfaces菜单命令,选择进行捕获的网络接口及其他选项,详细操作请参看教材第7章第2节相关部分(P246)。
1
,《计算机网络安全与应用》贺思德 申浩如 科学出版社 2007 http://netsecurity.ynu.edu.cn 网络安全案例分析
2.启动客户机IE 浏览器,访问云南大学视频点播服务器http://vod.ynu.edu.cn,捕获通信数据。
3.停止Wireshark 的捕获进程。在Wireshark 界面显示出获取的数据包列表。
4.利用Wireshark 的显示过滤器,从捕获数据中滤出DNS 通信数据包。
在显示过滤器Filter 中输入“udp.port==53”并按下Enter 键,从捕获数据中过滤出获得本机与DNS 服务器通信的数据包,如图¥.2所示,详细操作请参看教材第7章(P251)。从图中可以看出,1号数据包为DNS 客户机查询数据包,2号包为服务器响应数据包。
注意:在图¥.2中的下窗口可以看到Wireshark 自动将数据中的ASCII 编码字节翻译为文本字符(参看教材附录F ASCII编码表)。例如:查询ASCII 编码表,第003F 字节是65,代表字符e。第0040号字节是64,代表字符d。第0041号字节是75,代表字符u。等等。而文本开始处的符号“.”编码为02,文本结束处的符号“.”编码为03(本段中的数字都是16

进制数)。
图¥.2 DNS客户机请求与服务器响应的通信数据
5.分析DNS 通信过程 通信过程
在图¥.2中,鼠标点击执行Statistics → Flow Graph菜单命令,获取客户机(本机)向DNS 服务器查询vod.ynu.edu.cn 时的数据流向图,如图¥.3所示,详细操作参看教材第7

章(P259)。
图¥.3 DNS域名查询数据流向图
注意:由于202.203.208.33是校园网内的DNS 服务器,查询速度较快,实际用时0.000468秒,因数据流向图中保留3位有效数字,故Time 时间显示均为0.000。
6.分析查询请求分析查询请求数据包结构请求数据包结构 数据包结构
从图¥.2中可以看出,1号数据包为查询请求数据包,下面逐步对该数据包的结构进行分析。
2
,
《计算机网络安全与应用》贺思德 申浩如 科学出版社 2007 http://netsecurity.ynu.edu.cn 网络安全案例分析
图¥.4 1号数据包概要信息
(1)概要信息 概要信息
在Summary 窗口中单击选中1号数据包,分析其概要信息,如图¥.4所示。其中显示:1号数据包是由客户机(本机)发给DNS 服务器的DNS 协议标准请求,查询域名为vod.ynu.edu.cn。
(2)应用层(应用层(Domain Name System Domain Name System )头部信息 头部信息
在概要窗口中单击选中1号数据包,并在协议树窗口中单击“Domain Name System”协议前的“ ”,显示出该协议的详细信息,如图¥.5所示,详细操作请参看教材第7章相关部分(P236)。
图¥.5 应用层(Domain Name System)头部信息
分析:图¥.5中的协议数据内容详细分析如下所示。
Domain Name System (query) // DNS查询请求
[Response In: 2] // 响应的标识为2
Transaction ID: 0x3d34 // 本次DNS 查询的标识ID 代号
Flags: 0x0100 (Standard query) // 这是标准的查询请求
0... .... .... .... = Response: Message is a query // QR: 这是查询报文
.000 0... .... .... = Opcode: Standard query (0) // Opcode:操作代码(0)标准查询
.... ..0. .... .... = Truncated: Message is not truncated // TC:此查询报文是完整的 .... ...1 .... .... = Recursion desired: Do query recursively // RD:请使用递归查询 .... .... .0.. .... = Z: reserved (0) // 保留(0)标志
0 = Non-authenticated data OK: Non-authenticated data is unacceptable // 非授权数据:拒绝接受 Questions: 1 // 查询记录数:1
Answer RRs: 0 // 应答记录数:0
Authority RRs: 0 // 授权记录数:0
Additional RRs: 0 // 附加记录数:0
Queries // 查询的问题
vod.ynu.edu.cn: type A, class IN // 要查询的域名,类型A,要获取IP 地址 Name: vod.ynu.edu.cn // 查询域名为vod.ynu.edu.cn
Type: A (Host address) // 类型A(主机地址)
Class: IN (0x0001) // 使用标准IP 地址
3
,《计算机网络安全与应用》贺思德 申浩如 科学出版社 2007 http://netsecurity.ynu.edu.cn 网络安全案例分析
(3)User Datagram ProtocolUser Datagram Protocol am Protocol 传输层UDP 用户数据报头部信息用户数据报头部信息 头部信息
在概要窗口中单击选中1号数据包,并在协议树窗口中单击“User Datagram Protocol”协议前的“ ”,显示出该协议的详细信息,如图¥.6所示,详细操作请参看教材第7

章相关部分(P236)。
图¥.6 传输层UDP(User Datagram Protocol)头部信息
分析:协议内容详细分析如下所示
User Datagram Protocol, Src Port: 1034 (1034), Dst Port: domain (53) //UDP源端口1034,目的端口53 Source port: 1034 (1034) // 源端口(本机):1034
Destination port: domain (53) // 目的端口(DNS服务器):53
Length: 40 // UDP数据报总长度:40字节
Checksum: 0xc4c4 [correct] // 校验和,正确
7.分析响应数据包结构 分析响应数据包结构
从图6.1-1中可以看出,2号数据包为DNS 服务器的响应数据包,下面对该数据包的结构进行分析。
(1)概要信息 概要信息
在Summary 窗口中单击选中2号数据包,如图¥.7所示。概要信息:2号数据包是由DNS 服务器发给

客户机(本机)的响应,使用DNS

协议。
图¥.7 2号数据包概要信息
图¥.8 应用层(Domain Name System)头部信息
4
,《计算机网络安全与应用》贺思德 申浩如 科学出版社 2007 http://netsecurity.ynu.edu.cn 网络安全案例分析
(2)应用层DNS(DNS (Domain Name System Domain Name System )响应的头部信息 响应的头部信息
在概要窗口中单击选中2号数据包,并在协议树窗口中单击“Domain Name System”协议前的“ ”,显示出该协议的详细信息,如图¥.8所示,详细操作请参看教材第7章相关部分(P236)。
分析:图¥.8中的协议数据内容详细分析如下。
Domain Name System (response) // DNS响应
[Request In: 1] // 请求的标识为1
[Time: 0.000468000 seconds] // 1号请求包与2号响应包的时间间隔 Transaction ID: 0x3d34 // 本次DNS 的业务交易代号ID(与请求包相同) Flags: 0x8580 (Standard query response, No error) // 标准的查询响应,无错
1... .... .... .... = Response: Message is a response // QR: 这是一个响应报文
.000 0... .... .... = Opcode: Standard query (0) // Opcode:标准查询(0)
.... .1.. .... .... = Authoritative: Server is an authority for domain
// 授权状态:本域内的授权服务器
.... ..0. .... .... = Truncated: Message is not truncated // TC:本报文是完整的
.... ...1 .... .... = Recursion desired: Do query recursively // RD:执行递归查询
1... .... = Recursion available: Server can do recursive queries // RA:本服务器可以递归查询 .... .... .0.. .... = Z: reserved (0) // 保留(0)标志
.... .. ..0. = Answer authenticated: Answer/authority portion was not authenticated by the server // 授权的应答:应答中的授权部分不是本服务器的授权,而是递归解析过程中来自其他服务器的授权 .... .... .... 0000 = R
reply code: No error (0) // 应答代码:无错0
Questions: 1 // 查询问题:1
Answer RRs: 1 // 应答记录数:1
Authority RRs: 2 // 授权记录数:2
Additional RRs: 2 // 附加记录数:2
Queries // 查询的问题
vod.ynu.edu.cn: type A, class IN // 查询的域名,类型,互联网地址
Name: vod.ynu.edu.cn // 查询域名为vod.ynu.edu.cn
Type: A (Host address) // 查询类型A(主机地址)
Class: IN (0x0001) // 使用标准IP 地址
Answers // 回答
vod.ynu.edu.cn: type A, class IN, addr 202.203.208.175 // 所查询域名的IP 地址为202.203.208.175 Name: vod.ynu.edu.cn // 查询域名为vod.ynu.edu.cn
Type: A (Host address) // 类型A(主机地址)
Class: IN (0x0001) // 使用标准IP 地址
Time to live: 1 day // 此答案的有效期:1天
Data length: 4 // 数据长度:4字节
Addr: 202.203.208.175
Authoritative nameservers // 授权的域名服务器
ynu.edu.cn: type NS, class IN, ns pridns.ynu.edu.cn // 上级域名,域名服务器
Name: ynu.edu.cn //上级域名:ynu.edu.cn
Type: NS (Authoritative name server) // 类型:授权的域名服务器
Class: IN (0x0001) // 使用标准IP 地址
Time to live: 1 day // 此答案有效期:1天
Data length: 9 // 数据长度:9字节
Name server: pridns.ynu.edu.cn // 初级域名服务器:pridns.ynu.edu.cn 5
,《计算机网络安全与应用》贺思德 申浩如 科学出版社 2007 http://netsecurity.ynu.edu.cn 网络安全案例分析
ynu.edu.cn: type NS, class IN, ns secdns.ynu.edu.cn // 上级域名,二级域名服务器
Name: ynu.edu.cn // 域名:ynu.edu.cn
Type: NS (Authoritative name server) // 类型:授权域名服务器
Class: IN (0x0001) // 使用标准IP 地址
Time to live: 1 day // 此答案有效期:1天
Data length: 9 // 数据长度:9字节
Name server: secdns.ynu.edu.cn // 二级域名服务器:secdns.ynu.edu.cn
Additional records // 附加记录部分
pridns.ynu.edu.cn: type A, class IN, addr 202.203.208.33 // 初级域名服务器和它的IP 地址 Name: pridns.ynu.edu.cn // 初级DNS 服务器域名:pridns.ynu.edu.cn Type: A (Host address) // 类型:主机地址
Class: IN (0x0001) // 使用标准IP 地址
Time to live: 1 day // 答案的有效期:1天
Data length: 4 // 数据长度:4字节
Addr: 202.203.208.33 //初级域名服务器地址:202.203.208.33 secdns.ynu.edu.cn: type A, class IN, addr 202.203.208.34 // 二级域名服务器和地址
Name: secdns.ynu.edu.cn // 二级域名服务器:secdns.ynu.edu.cn
Type: A (Host address) // 类型:主机地址
Class: IN (0x0001) // 使用标准IP 地址
Time to live: 1 day // 答案的有效期:1天
Data length: 4 // 数据长度:4字节
Addr: 202.203.208.34 // 二级域名服务器地址:202.203.208.34
(3)User Datagram Protocol, User Datagram Protocol, rotocol, 传输层UDP 头部信息 头部信息
在概要窗口中单击选中2号数据包,并在协议树窗口中单击“User Datagram Protocol”协议前的“ ”,显示出该协议的详细信息,如图¥.9所示,详细操作请参看教材第7

章相关部分(P236)。
图¥.9 传输层(User Datagram Protocol)头部信息
分析:DNS服务器给客户机的应答数据报头部中内容详细分析如下。
User Datagram Protocol, Src Port: domain (53), Dst Port: 1034 (1034) //UDP源端口和目的端口
Source port: domain (53) // 源端口(DNS服务器):53
Destination port: 1034 (1034) // 目的端口(客户机):1034
Length: 130 // UDP数据报总长度:130字节
Checksum: 0x22f6 [correct] // 校验和:正确
[Good Checksum: True]
[Bad Checksum: False]
以上为DNS 客户机访问本地服务器,请求提供vod.ynu.edu.cn 的IP 地址,客户机与服务器双方正常通信过程的数据分析案例。建议读者利用自己的计算机,访问一个Web 网站,利用Wireshark 将DNS 数据捕获,重复上述分析过程。这样才能深入了解DNS 协议的工作原理,提高自己分析问题和解决问题的能力。网络协议分析软件Wireshark 的下载和使用方法,参看页眉的教材和网站。
6
,《计算机网络安全与应用》贺思德 申浩如 科学出版社 2007 http://netsecurity.ynu.edu.cn 网络安全案例分析
¥.2 异常的.2 异常的DNS 服务导致服务导致淫秽导致淫秽网页淫秽网页URL 连接案例连接案例
案例:案例:2008年8月下旬发现访问教学网站http://netsecurity.ynu.edu.cn 的每个网页时,客户机浏览器上都会出现大量的淫秽URL 连接,经过反复分析查明原因,恢复正常。介绍此案例的分析过程。
1.访问本网站的网页时出现淫秽访问本网站的网页时出现淫秽URL 连接 连接
案发期间,访问本教学网站的首页和其他任何网页,都能正常显示在客户机浏览器上。但是客户机安装的瑞星杀毒软件连续发出警告:“在浏览器的临时文件夹中含有木马Trojan.DL.JS.Agent.ljv”,根据提示,这些位于浏览器中的Internet 临时文件夹是:
(1)C:Documents and SettingsHeLocal SettingsTemporary Internet FilesContent.IE5
(2)C:Documents and SettingsHeLocal SettingsTemporary Internet
FilesContent.IE5OJV3I0LLvip[2].htm
(3)C:DOCUME~1HeLOCALS~1Temp74447003896.tmp
当浏览器正常显示完本站网页后,在浏览器的下边缘状态栏窗口就出现大量的URL 连接提示,随即自动打开了多个淫秽网站界面,显示出各种淫秽流氓网站的页面。每当用户点击访问本站的任何一个网页,下述异常的URL 连接和淫秽网页就重复出现一遍。这些恶意的URL 是:
注意:注意:上面这些淫秽网页的URL 都很长,这种方法可以有效地逃避互联网搜索引擎(例如:Google,baidu 等)的搜索,参看作者教材[1]中“Google的工作原理”,这种方法也能够逃避公安网络监察部门的搜索检查。由于淫秽网页的URL 很长,很多互联网搜索引擎搜索不到,但是为了提高其访问量,于是就在互联网系统的DNS 服务器上采取域名劫持的策略,将大量互联网用户对某些知名网站的正常访问,劫持引导到他们的淫秽网站上。除了本文描述的域名劫持案例外,另一种方法是利用以太网的ARP 欺骗产生中间人,当它转发客户访问的网页时,在其中插入淫秽网站的连接内容,见本网站ARP 欺骗案例分析。
2.寻找产生寻找产生淫秽产生淫秽URL 连接原因的过程 连接原因的过程
(1)首先我们怀疑本网站的网页文件被黑客入侵和恶意窜改了,因此在服务器端和在客户机浏览器端对收到的本网站的网页代码进行了仔细分析,没有发现任何异常的代码。
(2)利用瑞星杀毒软件对本站Web 服务器进行了全面的病毒和木马清查,没有发现任何问题。服务器的日志记录正常。将服务器的网站文件换为几个月前的备份文件,恶意URL 连接和木马警告仍然出现。
(3)启动服务器上的IE 浏览器访问本机网页:如果将服务器上的瑞星防火墙的“端口开关”中“远程”的80端口开放,浏览器出现与远端客户机访问时相同的恶意URL 连接,并且杀毒软件发出木马报警。如果将防火墙“端口开关”中“远程”80端口关闭,则服务器上的浏览器中只显示本站网页,没有恶意URL 连接和木马报警。
因此可得结论1:浏览器中出现的淫秽URL 连接和木马的第一个诱因是对某远端http 服务器的80端口的访问。而与http 服务器的80端口建立TCP 链接之前,首先要执行DNS 域名解析,参看页眉教材。 7
,《计算机网络安全与应用》贺思德 申浩如 科学出版社 2007 http://netsecurity.ynu.edu.cn 网络安全案例分析
(4)查看服务器的ARP 路由表,其中默认网关的IP 地址与MAC 地址的对应关系正常,证明服务器没有受到ARP 欺骗攻击。请参看本网站文章“利用ARP 欺骗实现中间人攻击窜改网页的案例分析”。按照页眉教材第7.1节介绍的方法,获得服务器的ARP 表如下:
C:Documents and Settings�ministrator>arp -a
Interface: 202.203.208.112 --- 0x10003 (服务器IP 地址)
Internet Address Physical Address Type
202.203.208.65 00-d0-2b-e5-1d-0a dynamic (服务器所在局域网的默认网关MAC 地址正常)
(5)从不同地域的网络中的计算机访问本网站,浏览器都同样出现上述淫秽网站URL 的连接。
由此可得结论2:产生恶意URL 连接和木马的原因不是产生在本服务器和服务器所在的局域网中,同样也不是产生在客户机和客户机所在的局域网中。
3.网页中的淫秽网页中的淫秽URL 连接和木马从何而来 连接和木马从何而来
分析:分析:因为IE 浏览器在收到服务器的网页代码后,是边解释网页代码,边逐渐显示对应的网页内容。即:浏览器上显示的网页内容不是整页一齐显示,而是随着代码的逐段解释而逐渐显示的。因此我们可以根据浏览器上看到的恶意URL 和木马出现的时刻,来判断这些恶意代码位于网页代码文件的大概位置。
在用浏览器观察本站网页时发现,恶意URL 连接的出现时刻是在每个本站网页正常显示完毕之后。因此可以断定:恶意URL 和木马出现的诱因是位于本站的每个网页的尾部,并且是位于每个网页都共同具有

的部分。这个部分对应于本站网页底部的作者通信录和点击率统计的部分,如下图。
图¥.10 网页中产生恶意URL 连接的可能位置
为了统计本网站的访问量和客户地域分布等数据,所有网页底部采用了“中国网站之家”等3个网站的统计服务,每当客户点击一次本站网页,就会向统计服务的网站的80端口发送信息。本站网页采用的由统计网站http:// indexed.webmasterhome.cn提供的代码之一如下:
每当运行上述代码时,就要进行一次对indexed.webmasterhome.cn 的域名查询,产生淫秽URL 链接问题的根源来自此域名查询的DNS 服务器。根据上述分析,将图¥.10所示区域的代码逐段停用,发现当把“CNZZ.COM.”、“收录查询”和“雅虎统计”等访问量统计的代码功能停用后,本站网页中的恶意URL 连接即消失,由此找到产生问题的原因。关于网页点击率统计的工作原理,在另文介绍。
8
,《计算机网络安全与应用》贺思德 申浩如 科学出版社 2007 http://netsecurity.ynu.edu.cn 网络安全案例分析
4.问题的根源 问题的根源
根据上述对DNS 怀疑的分析结果,在国家计算机网络应急技术处理协调中心网站上有如下公告:
关于DNS 系统面临严重安全漏洞风险的紧急公告 系统面临严重安全漏洞风险的紧急公告
安全公告:CN-VA08-05。发布日期发布日期:2008年7月24日。漏洞类型漏洞类型:欺骗。漏洞评估漏洞评估:重要。安全等安全等安全公告发布日期漏洞类型漏洞评估
级:三级。公开程度公开程度:公共。http://www.cert.org.cn/articles/bulletin 公开程度
漏洞描述:漏洞描述:
2008年7月9日以来,思科、微软、ISC等互联网域名解析服务软件厂商纷纷发布了安全公告,称其DNS 软件存在高危漏洞,攻击者可以通过猜测DNS 解析过程中的报文序列号来伪造DNS 权威服务器的应答,从而达到“污染”高速缓存(Cache)中的记录的目的,即将错误的域名指向信息注入即将错误的域名指向信息注入DNS 服务器,服务器,最终导致受到污染的DNS 服务器将对外提供错误的解析结果。服务器将对外提供错误的解析结果。该种攻击方式可造成域名劫持攻击,使得公众在不知情的情况下通过域名访问到黑客指定的网站,面临网络钓鱼和网页木马等一系列严重的安全威胁。
7月22日,针对该漏洞的探测程序被发布,7月23日,针对该漏洞的完整攻击程序被发布,并随后广泛流传。我中心经过初步测试后发现,在带宽良好情况下,该攻击程序对存在漏洞的DNS 服务器只需数分钟就可完成攻击,受攻击目标会瞬时接到大量攻击报文,容易被误判为“query flood”方式的拒绝服务攻击。鉴于该安全事件形势严峻且发展迅速,为确保我国互联网的运行安全,请各相关单位迅速采取适当措施,对所运行的DNS 服务器进行必要的安全加固,并加强异常监测和处置。
建议措施:建议措施:
(1)根据各DNS 生产厂商提供的补丁升级DNS 服务器系统;
(2)因在攻击过程中会短时出现大量伪造的域名解析响应数据包,呈现拒绝服务攻击特点,这些数据包的源IP、目的IP、解析的IP 地址相同,但序列号不同,可据此在有条件的防护设备(如智能防火墙、流量清洗设备等)上配置相应的规则加以屏蔽或过滤;
(3)定期清理DNS 缓存或在发现异常访问后清理缓存。
5.结论:结论:
在访问本网站时客户机获得的查询记录响应来自本地的DNS 服务器,其工作正常,客户机浏览器获得了目标网站的正确的IP 地址。但是当浏览器解释网页代码到网站的每个网页底部的“收录查询”时,浏览器启动了对统计网站的域名查询,在本地DNS 服务器中没有此统计网站的授权记录,这时本地DNS 服务器利用递归解析方法,将查询请求发向远端的DNS 服务器。网页中出现的淫秽网站的URL 连接就产生于对统计网站的域名查询的递归解析过程中。
参看本教材[2]中第6章6.1.5节图6.11关于DNS 系统的原理介绍,由于此案例中DNS 系统采用了递归解析方式,因此要具体查找到本案例中的高速缓存受到污染的DNS 服务器,就需要分析各DNS 服务器进行递归查询的链路关系。问题可能产生于递归解析链路中的某个DNS 服务器中的高速缓存受到污染。如果不能对被污染的DNS 服务器准确定位,可以在全互联网系统的所有DNS 服务器中安装上制造商提供的补丁程序。关于易受污染的DNS 服务器型号和制造商清单见下面美国网站的公告。
在美国计算机应急响应组的网站 http://www.kb.cert.org/vuls/id/800113 上对此DNS 服务器的高危漏洞进行了详细的技术描述,并且给出了易受此恶意攻击影响的DNS 服务器清单列表。更重要的是更重要的是,更重要的是,在DNS 系统的各服务器之间的查询转发中,系统的各服务器之间的查询转发中,禁止使用递归解析方式,禁止使用递归解析方式,而使用迭代方式。而使用迭代方式。
为了让读者易于理解,本文对DNS 的原理和域名劫持案例进行了非常详细的分析。从中可以看出,进行网络安全诊断的最基本和最有效的方法是进行数据分析。对于本案例的DNS 域名劫持攻击,客户端局域网内的杀毒软件、防火墙和入侵检测IDS 都是没有用的。
9
,《计算机网络安全与应用》贺思德 申浩如 科学出版社 2007 http://netsecurity.ynu.edu.cn 网络安全案例分析
¥.3 美国计算机应急响应组.3 美国计算机应急响应组DNS 安全公告安全公告 公告
下面对美国计算机应急响应组“关于DNS 服务器的高速缓存易受到污染的技术分析”进行介绍和解释。漏洞公告ID 号:VU#800113. “域名系统DNS 的执行中,多种途径容易导致高速缓存受到攻击污染”。公告网址http://www.kb.cert.org/vuls/id/800113
要点:要点:由于DNS 协议本身的弱点,以及DNS 软件中存在的共同问题,导致DNS 高速缓存易受到攻击污染。
1.详细的DNS 漏洞分析 漏洞分析
域名系统用于将主机名转换为IP 地址,是互联网系统的一个重要组成部分。攻击者可以利用对DNS 的高速缓存进行污染的技术,将虚假的DNS 信息设置到DNS 服务器的高速缓存中。对DNS 高速缓存进行污染并不是一个新概念,有些已发表的文章都论述了DNS 协议中的固有脆弱点,还有一些软件商开发的DNS 实施软件中的普遍漏洞,这些都容易导致DNS 缓存受到污染。下面是这些缺陷和漏洞的例子:
(1)缺乏足够的缺乏足够的DNS 查询ID 标识码空间:标识码空间:
在DNS 协议数据包的结构参数中指定了一个16比特长的字段作为查询交易的ID 标识码(见页眉教材的图6.7中的标识ID,例如,图¥.5的数据中,DNS客户机向服务器发出的查询请求中Transaction ID: 0x3d34)。在DNS 协议被正确地运行过程中,客户机发送DNS 查询请求数据包时选择一个真正的随机数作为本次查询的ID 标识码,而DNS 服务器利用收到的此ID 号将查询结果响应发回给客户机。如果一个攻击者要冒充服务器向客户机发回虚假的DNS 响应包,那么他平均要进行32768次尝试,才能成功地预测到此ID 标识码,利用它来欺骗客户机接受虚假的响应信息。有一些计算机操作系统的DNS 软件在随机选择此交易ID 号时,使用了较少的比特数,因而攻击者只要尝试较少的次数就可以成功地预测到此ID 号。另外,已知有一些计算机操作系统产生的ID 号的随机性不强。Amit Klein 在2007年研究了几个存在此问题的计算机操作系统,并将已发现的存在问题发布于下述公告中:
•
•
• 漏洞公告 -微软Windows DNS 服务器的高速缓存抗污染能力的脆弱性报告,全文下载网址[10]:http://www.kb.cert.org/vuls/id/484649 漏洞公告 - ISC BIND产生的DNS 查询ID 号的机密性不强的报告,全文下载网址[11]:http://www.kb.cert.org/vuls/id/252735 漏洞公告 - BIND version 8 产生机密性不强的DNS 查询标识ID 号的公告,全文下载
网址[12]:http://www.kb.cert.org/vuls/id/927905
(2)多重发出同样多重发出同样的同样的DNS 请求:请求:
有些计算机系统的DNS 业务的脆弱性表现在,如果要对DNS 服务器中的同一个资源记录RR (resource record)多次进行查询时,就会产生同时发送多个同样的查询请求的情况。这种情况可能导致“生日攻击”,使攻击者进行DNS 欺骗的成功率大大提高。此问题在安全公告VU#457875中进行了描述,题目为“各种DNS 业务软件对同一个资源记录RR 同时发送多个同样的请求”,参看[13]:http://www.kb.cert.org/vuls/ id/ 457875。有一些开发商已经在自己的产品中对此问题做了缓解的处理。
(3)在多次发多次发送DNS 查询请求时重复使用同样的查询请求时重复使用同样的固定源端口号同样的固定源端口号:固定源端口号:
当前的一些计算机的网络操作系统中,刚开始发送DNS 请求时选取了一个随机数作为源端口号,这是正确的方法。但是在后续再发送请求时,又重复使用了已经用过的同样的数字作为源端口号。在有些系统软件中,甚至将向外发送的DNS 请求的端口号固定在已经分配给DNS 服务器的端口53/UDP上。
近年来对这些脆弱性做了多方面的研究,将这些方法组合起来就可提高对DNS 服务器的高速缓存进行污染的攻击能力,出现了一些很有效的攻击技术。风险最大的是基于高速缓存的DNS 解析器,特别是那些开放式的DNS 解析器,它允许自己的管理域外的客户机通过递归解析方式向它提出域名解析请求服务。对不开放的DNS 服务器也有同样的问题。这些高速缓存的DNS 解析器是攻击者最常选的目标,原始授权DNS 解析器(stub resolvers)也有此风险。
因为对这些脆弱性的攻击,都依赖于攻击者的预测和欺骗网络数据流的能力。在当前DNS 协议规范的范围内增加源端口号的随机选取范围可减缓此类攻击,随机化的源端口号能被用来获取额外的大约16比 10