荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: hellsolaris (qq), 信区: Security
标 题: NetXray使用说明之(9)----TCP/DNS问题
发信站: 荔园晨风BBS站 (Sun Oct 26 13:10:20 2003), 站内信件
发信人: scz (小四), 信区: Security WWW-POST
标 题: NetXray使用说明之(9)----TCP/DNS问题
发信站: 武汉白云黄鹤站 (Wed Feb 14 18:07:04 2001) , 站内信件
论坛上santa朋友报告了一个关于Win2K下Sniffer Pro 4.5的问题，简单说就是解析
TCP/DNS报文的时候有点问题。flag和我一起仔细测试过，的确存在小麻烦。
在RFC 1035的"4.2.2. TCP usage"小节对此有足够解释，TCP数据流的前两个字节是
message length，这点和UDP DNS报文明显不同。注意，既然是TCP数据流，所以并不
要求这两个字节和DNS负载出现在同一个报文中，至少RedHat下nslookup在做区传输
的时候先发送了两个字节的message length，然后发送另外一个TCP报文携带了DNS负
载。对于UDP DNS报文，UDP数据区直接对应DNS负载，UDP头部中UDP报文长度减去8就
是DNS负载长度(也就是UDP数据区长度)。
从Win9x下的Sniffer Pro 2.6到Win2K下Sniffer Pro 4.5，事实上都意识到了TCP DNS
的特殊性，解析区传输引发的TCP查询报文时，对前两个字节做了规避。偏偏前两个
字节已经单独发送到DNS SERVER去了，最终导致后续DNS负载中真正的id域被当成
message length而越过，param域被当成id域解析，再后面的域解析全部乱套。区传
输的第一个响应报文中message length和后续DNS负载位于同一个TCP报文中，所以解
析正确。
RFC 1035没有强制要求message length如何出现，对于TCP数据流来说，这是完全正
确的，本来就没有边界概念。Sniffer Pro无法预知所有TCP数据流的表现方式，或者
说无法预知所有DNS CLIENT的具体实现方式，只能简单假设message length和后续
DNS负载位于同一个TCP报文中，不可能为了正确解析这种TCP DNS查询报文而跟踪保
持前后的TCP数据流(前后状态相关)。
NetXray 3.03存在类似问题，但是它显式解析了message length字段，以Tcp Length
显示该字段，明确提醒使用者TCP DNS报文和UDP DNS报文的差别。很奇怪，Sniffer
Pro抛弃了太多NetXray的优点，这次又是一个例证。
如果你想自己测试验证这个问题，重点在于如何激发TCP DNS报文，下面是我整理维
护的<<Unix编程/应用问答中文版>>中的内容：
--------------------------------------------------------------------------
17. 如何进行DNS区传输
A: scz <scz@nsfocus.com>
用nslookup是最普遍适用的
nslookup
> server ns.tsinghua.edu.cn
> set type=axfr
> ls tsinghua.edu.cn [> tsinghua.txt] (方括号里的可选)
有些系统提供了dig命令
dig @ns.tsinghua.edu.cn axfr tsinghua.edu.cn
A: lgwu
有些系统提供了host命令，这个命令不太保险
host -l net.tsinghua.edu.cn (后面指定域)
host -l ncic.ac.cn
18. 如何获知权威名字服务器
A: scz <scz@nsfocus.com>
nslookup
> set query=ns
> ncic.ac.cn (获知管辖该域的权威名字服务器)
Authoritative answers can be found from:
gatekeeper.ncic.ac.cn internet address = 159.226.41.188
> server gatekeeper.ncic.ac.cn
> set type=axfr (准备区传输)
> ls ncic.ac.cn > ncic.txt
--------------------------------------------------------------------------
另外有个问题，用RedHat下nslookup做区传输激发TCP DNS报文，Win2K下
LanExplorer 3.6抓取响应报文(不是分成两半的查询报文)，在企图解析时导致进程
异常退出。具体原因尚在参测中，可能和错误处理message length字段有关。
由此我们想到其他sniffer是否存在类似问题，针对Unix系统下snoop、tcpdump是否
有机会做exploit。
--
--
※ 来源:·荔园晨风BBS站 bbs.szu.edu.cn·[FROM: 192.168.44.223]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店