损坏的DNS请求

有时在包含我的DNS服务器的一些networking捕获中,我发现失败的查找看起来像无效的请求。

在Wireshark中查看时,这些字符显示的是ASCII范围之外的转义字节。

Wireshark的query.name> Copy> Bytes> Hex Stream的一个例子是:

Raw: 03777777128b68481cc5116ceb53bade651327d982751903636f6d00` As Python bytes: \x03www\x12\x8bhH\x1c\xc5\x11l\xebS\xba\xdee\x13'\xd9\x82u\x19\x03com\x00 

你可以看到那里有一些常见的DNS查询格式:

  • 信号3个字节,然后www
  • 信号18个字节,然后…乱码。
  • 信号3个字节,然后com

我无法弄清楚中间是什么意思。

我熟悉国际字符Punycode,我相当肯定,这不是这是什么。

我无法访问发出请求的主机。 我知道一些恶意软件试图解决这样的事情,所以我很好奇这是否表示存在恶意软件。

编辑添加

以下是Wireshark的DNS响应截图: 在这里输入图像说明

Punycode是ASCII编码,所以你是正确的,这似乎是垃圾。 我们需要看到整个数据包不止于此。 我已经把这个string分解成了ASCII和hex字节的边界,以便更容易理解数据包的结构。

(如果有人发现一个错误,直接编辑它)

[03] www
[12][8b] hH
[1c][c5][11] l
S
[ba][de] e
[13] ' [illegal DNS ASCII: byte 0x27]
[d9][82] u
[19][03] com
[terminating null byte 0x00]

  • Punycode不使用高于7位ASCII边界的字节,以hex7F结尾。
  • 即使我们假设在这个string中embedded了UTF-8字节的非法尝试,那么这些字节的起始字节在C2F4的hex范围内。 紧跟在最初的www后面的字节是hex12 (换页),然后是8B ,这是一个连续字节。 绝对不是有效的UTF-8。

在这一点上,我们剩下三种可能性:

  1. 数据损坏
  2. 旨在利用漏洞的数据包
  3. 尝试通过DNS协议对非DNS数据进行编码,以规避防火墙,如VPN软件。 我没有花太多的时间研究这个实现,所以不能评论这种情况的可能性。 如果发生这种情况,我会认为领先的“www”和“com”是愚弄基本的深度包检测的弱点。