基于DNS的数据泄露开源测试工具篇(一)
2019-12-26 10:00:53 Author: www.freebuf.com(查看原文) 阅读量:116 收藏

免责声明:本文作者竭力保证文章内容可靠,但对于任何错误、疏漏或不准确的内容,作者不负任何责任。文章部分内容来源于网络是出于传递更多信息的目的,对此不负任何法律责任。本文仅用于技术分享与讨论,严禁用于其他用途。

一、前言

随着攻防对抗持续升级,攻击者与防御者之间在各方面的较量逐渐扩大。从ATT&CKTM矩阵[1]我们可以发现,攻击者完成攻击活动战术(Tatics,攻击行为的技术目标)明确,且每个战术下的可用技术(Technique,为实现战术所使用的方法)众多。在“假定失陷(Assume Breach)[2]”的现状下,作为防御方我们必须深入分析攻击者在实际攻击活动中正在使用、可能使用的技术,然后从攻击原理的角度指导防御策略制定、防御系统搭建,从而尽可能的在攻防博弈中占据主动地位。

正是在这一思想的指引下,本文将聚焦到基于DNS的数据窃取技术。本文所讨论的该技术主要指:攻击者恶意利用现有DNS服务来(隐蔽)窃取受害者主机上的高价值数据、重要文件等所使用的技术。参考近几年的恶意组织/攻击活动分析报告,可以发现这种隐蔽的攻击活动不乏真实案例的曝光;如APT32使用的后门工具曾利用DNS完成数据窃取,CopyKittens所使用攻击框架中的RAT也利用DNS窃取目标主机的重要文件数据。为了更好的理解基于DNS的数据窃取和隐蔽回传的技术细节,以攻击原理引导防御策略制定和防御能力提升。本次将选取DET(Data Exfiltration Toolki)、PyExfil、DNSExfiltrator——三个github上认可度较高的开源项目进行简要分析,同时这些工具可以帮助管理员快速搭建测试模拟环境,测试其系统对抗DNS数据窃密的检测能力。三个工具在github上收获的“粉丝”情况如图1。

图1 DET、PyExfil、DNSExfiltrator的首页展示

注:三个开源工具中DET、PyExfil为综合性工具,即它们不仅仅实现了DNS窃密技术;但本文只摘取了其基于DNS的数据窃取、隐蔽回传的相关部分进行梳理和简要分析。

二、DET工具简介

DET(Data Exfiltration Toolkit)是一个Github开源项目[3],该项目作者将它描述为一个用于数据泄露概念验证的项目,其基本思想是建立一个通用工具箱,可以动态扩展实现对多种类型协议、服务的利用,用来测试和验证利用不同协议或服务的数据泄露技术。

DET项目整体结构如图2,从图中可以看出,该工具通过插件形式实现扩展,支持使用不同协议、服务进行数据窃取,已实现协议、服务见表1。本文主要关注利用DNS进行数据窃取的相关部分(图2中标星部分)。

图2 DET项目整体情况

支持协议 DNS、HTTP、ICMP、TCP、UDP
支持服务 Gmail、Twitter、Slack、Google docs

表1 DET已实现的可利用服务、协议

三、基于DNS的数据窃取的源码简要分析

图2表明,det.py文件为DET工具运行的主体框架,不同的协议或服务的具体细节则分别在对应插件目录下实现。所以我们重点关注det.py、plugins/dns.py两个源码文件。

(一)det.py源码简要分析

对det.py代码中的主要方法、类梳理如图3。本文将重点关注用于关键类Exfiltration和类ExfiltrationFile。同时,在det.py中,也实现了一些通用方法,如:使用的加/解密方法为AES,具体实现是导入python的AES库;使用MD5进行文件校验,具体则采用python的hashlib库实现。除此之外,det.py实现了插件管理的多个方法,实现在使用DET工具是可以动态启用、停用特定协议或服务等。

图3 det.py代码概况

类Exfiltration主要包含服务端接收和恢复窃密文件的关键实现源码,也对部分辅助函数进行了封装。关键方法有register_file()、retrieve_file()、retrieve_data()等。

register_file()方法的主要功能是:根据文件唯一标识jobid(随机生成的7为字符串,用来标识哪些数据包属于同一个文件),在服务端的全局字典files(暂存接收的文件数据块)中初始化该文件的相关信息,主要包括添加该文件对应的jobid到全局字典files、提取并存储该文件的校验和文件名等信息;全局字典files中单个文件的存储结构如图4。

图4 单个文件在字典files中的形式化存储

retrieve_file()方法主要负责将已窃取的文件数据写入本地文件,该方法会首先计算文件数据的检验和,然后与注册包中传送的校验和对比,只有在验证通过的情况下才执行数据解密并写入本地文件。

retrieve_data()方法的主要作用是根据监听端口所收到包的不同类型,采取对应的预设处理方法;例如:当收到的包为文件数据包时,则从该包中提取文件数据,并将数据按jobid和包序号存入files[jobid][data]中。其中,不同包类型及其结构见表2。

包类型 组成结构
初始化包 <jobid> |!| <filename> |!| <”REGISTER”> |!| <checksum>
窃密数据包 <jobid> |!| <packet_num> |!| <data>
结束包 <jobid> |!| <packet_num> |!| <”DONE”>

表2 DET包类型及其组成结构

ExfiltrationFile类主要作用于客户端,负责处理欲窃取的文件数据,然后启用指定协议或服务的插件来发送窃密文件数据块。其工作主要流程如下:

1)计算欲发送文件数据的MD5值,用作文件校验。

2)完成预处理工作,包括注册使用指定协议/服务的插件、读取其他定制参数、读取文件数据、压缩及加密等。

3)构造初始化(注册)块,并启用插件实现的方法发送。

4)每次读取随机大小的文件数据块,编码、添加包序号后逐个发送,直到文件数据发送完毕。

5)构建结束块,并启动插件实现的方法发送。

注:不同包类型的构建格式参考表2

(二)插件plugins/dns.py简要分析

dns.py文件包含客户端发送、服务端接收处理单个DNS请求包的实现细节。例如:当客户端启用DET工具时指定利用协议为DNS时,det.py将通过插件管理启用dns.py。该源码文件主要负责将要传送的数据块二次拆分,并以符合DNS协议的形式编码组合为指定域名的子域名,然后通过DNS查询包发送。值得注意的是该文件与det.py文件协同工作,dns.py文件的处理对象是det.py输入的单个数据块,最终以一个或多个DNS查询请求包发送到服务端;而det.py的处理对象则是欲窃取文件对象,输出将作为dns.py的处理对象。梳理dns.py文件源码结构如图5。

图5 dns.py源码概况

图5中的listen()方法通过sniff监听在指定地址上接收数据,即用于服务端接收DNS请求数据,提出去子域名后作为handle_dns_packet()方法的处理对象。handle_dns_packet()方法将简单处理收到的DNS包,提取、暂存编码在子域名中的窃密数据;当检测到数据块传输完成,则解码数据块并交付给det.py做进一步处理。而send()方法则用于客户端构造并发送嵌入了窃密数据的DNS查询;它主要负责将det.py处理后的数据块拼接组成给定域名的子域名(子域名的拼接规则见表2中的窃密数据包),并发送到指定窃密服务器的目标端口(默认53端口)。

总结与思考:

通过以上分析,整理总结DET工具的整体流程如下图:

图6 DET工具的整体流程

通过对DET工具的实验测试,该项目作为测试项目在实际测试中存在一些问题,例如:

1)效率较低。如:使用Hex编码使实际传输文件数据是原始文件数据的2倍,处理数据块、构造DNS包时重复添加文件标识等。

2)抓包后的流量明显异常。如:子域名、单个标签过长,数字占比极高等。

3)服务端恢复成功率影响因素较多。如:DNS包的次序、文件数据大小等。

*本文作者:GZHU/asUwIll,转载请注明来自FreeBuf.COM


文章来源: https://www.freebuf.com/sectool/222561.html
如有侵权请联系:admin#unsafe.sh