内容简介:之前很早就已经看到360关于Ghost Tunnel的研究,当时也一时兴起进行复现。在Mac和Windows上都做了一系列尝试,证明了理论可行。后来闲的无聊,并且刚好有学弟也在验证这个隐蔽通道的可行性,就干脆和他一起探讨这方面的实现。之后,GhostTunnel我就推在自己的Github上,经过一段时间的努力,我和我同伴一起推出了GhostTunnel稳定版。说实话,我不是很清楚360是如何做到极其稳定的控制在各个系统上,技术上难以想象。在探索GhostTunnel的道路上,我个人认为未来在移动端以及蓝牙
之前很早就已经看到360关于Ghost Tunnel的研究,当时也一时兴起进行复现。在Mac和Windows上都做了一系列尝试,证明了理论可行。
后来闲的无聊,并且刚好有学弟也在验证这个隐蔽通道的可行性,就干脆和他一起探讨这方面的实现。之后,GhostTunnel我就推在自己的Github上,经过一段时间的努力,我和我同伴一起推出了GhostTunnel稳定版。说实话,我不是很清楚360是如何做到极其稳定的控制在各个系统上,技术上难以想象。
在探索GhostTunnel的道路上,我个人认为未来在移动端以及蓝牙上,可能都存在类似的方法进行隐蔽传输。传输的效率和网卡的功率非常有关系,目前我们测试的有效距离是5m左右,过远会导致丢帧率增高,不稳定性增加。
利用GhostTunnel配合bashbunny+powershell基本可以实现无感控制。然后远程加载木马或者绕过,提权都是非常可行的。
本人的想法是希望能够将这个一直迭代下去,开发出多端的隐蔽控制。也希望有朋友一起提出issue或者request进行迭代。
【Github传送门】 https://github.com/JcQSteven/GhostTunnel
下面是ReadMe部分。主要表述了我是如何利用GhostTunnel实现控制端和其被控端。
被控端程序逻辑
被控端程序的目的在于接收控制端的指令,并根据指令执行相应的行为。由于控制端与被控端之间通过Probe request帧和Probe response帧传输,因此被控端逻辑主要分为 【帧传输逻辑】和【帧解析逻辑】 两个部分。
帧传输逻辑
Probe request帧由被控端主动发送,并接受控制端发送Probe respense帧。因此,在 windows环境下,其执行的逻辑为:获取会话句柄、获取网卡列表及信息、发送request帧、获取附近网络信息列表、获取指定WLAN端口上的网络基本服务集、获取帧数据。
获取会话句柄
获取会话句柄采用的api为WlanOpenHandle。该 api打开了一个与服务器的连接。只有持有了句柄,才能进行后续才做。
获取网卡列表及信息
获取网卡列表采用的api为WlanEnumInterfaces,通过该函数,可以获得一个网卡列表 pIfList,通过对该列表的解析,可以获取网卡的信息。
发送request帧
在获取网卡信息判断网卡准备无误后,即可通过WlanScan函数发送request帧。发送帧的结构请参见后续部分。
获取附近网络信息列表
在发送request帧后,被控端通过WlanGetAvailableNetworkList 函数开始扫描附近网络信息,检查是否收到response帧。如果没有,则返回第3步,重新发送request 帧,然后再次检测。如果收到response帧,则进入第5步。
获取指定WLAN端口上的网络基本服务服务集
利用WlanGetNetworkBssList函数获取指定网络上的BSS列表并进行解析,根据 response帧的特征值id过滤出有用的的帧。
帧解析
将过滤出的帧并根据帧的定义获取对应的数据,从而完成一次帧传输逻辑。
帧解析逻辑
在完成帧传输逻辑后,即可获取由控制端发送的response帧数据。request帧和response帧的帧结构如下:
request 帧结构 :
“acc” (3byte) | Hash (8byte)
名称 | 作用 |
“acc” | 用来标识该帧为请求帧 |
Hash | 帧第一次发送时间的Hash值 |
request帧的前三个字节用于标识该帧为请求帧,后面8个字节为当前帧第一次发送时间的Hash值,为接收端提供帧标识,防止重复接收。 |
response 帧结构 :
执行指令帧:
”ccc” (3byte) | Hash (8byte) | Command (244byte)
名称 | 作用 |
”ccc” | 用来标识该帧为执行指令帧 |
Hash | 最后一次接收到response帧的Hash值 |
Command | 执行指令 |
执行指令帧的前三个字节用来标识该帧为执行指令帧,后面8个字节为最后一次接收到response帧的Hash值,最后244字节为待执行指令。
传输文件帧:
”F” (1byte) | FilenameLen (2byte) | Hash (8byte) | FileIndex (2byte) | CurrentIndex(2byte) | FileName+FileContext (220byte)
名称 | 作用 |
“F” | 用来标识该帧为传输文件帧 |
FilenameLen | 用来标识文件内容相对于头信息后内容的偏移量 |
Hash | 当前帧第一次发送时间的Hash值 |
FileIndex | 文件总分片数 |
CurrentIndex | 当前接收的分片序号 |
FileName+FileContext | 先为文件名称,然后为具体的文件内容 |
传输文件帧的第1个字节(“F”)用来标识该帧为传输文件帧,第 2、3字节(FilenameLen)用来标识文件内容相对于头信息后内容的偏移量,因为文件名的长度是不定的。第4-11字节(Hash)为当前帧第一次发送时间的Hash值,第12、13字节(FileIndex)为文件总分片数,第14、15字节(CurrentIndex)为当前接收的分片序号,第16字节起先为文件名称,然后为具体的文件内容。
根据帧结构,可以很轻易的解析帧所携带的信息。如果帧为执行指令帧,则调用CreateProcess函数创建进程执行指令;如果帧为传输文件帧,则将帧所携带的文件内容写入文件中。
文件说明
1.main.cpp /.h 主程序入口 2.mainProcess.cpp /.h 主函数逻辑 3.Action_ExcuteCmd.cpp /.h 执行命令攻击逻辑 4.Action_Sendfile.cpp /.h 发送文件攻击逻辑
控制端程序逻辑
response帧由控制端在接收到request帧后发送,因此控制端逻辑主要分为解析命令、抓包、发送帧三个步骤。
解析命令
不同的攻击所采用的参数不同。例如:
需要设定自动关机时,所采用的指令是
python main.py -c"shutdown -r -t 60"
需要远程传输文件时,所采用的指令是
python main.py -f"/root/Desktop/hello.txt"
因此,需要对攻击者所采用的指令进行解析,从而确定所需的帧结构。
抓包
由于reponse帧需要在接收到request帧后对其进行反馈,因此,在 python 环境下,利用scapy工具包sniff方法对指定网卡进行扫描(注:指定网卡需要切换至monitor模式)。当收到数据包后,根据request帧的特征对数据包的内容进行定位和解析,如果解析到request帧,则将帧的hash部分存入本地缓存。
发送帧
根据攻击者的指令,控制端根据定义的response帧结构构造数据包,并按照帧会话逻辑进行发送。
帧会话逻辑
由于采用request帧和response帧进行的会话是无连接的,因此很容易造成帧的丢失、重复等问题。因此,在需要多帧传输、单帧验证等使用场景下,需要采用一种可靠的会话逻辑来确保帧的按序传输。帧的会话逻辑如下:
request帧初始状态下Hash值为随机数。在接收到response帧后,将最新接收的response帧的Hash值作为自己的Hash值,从而达到告诉控制端“某帧已经接收到,请发送下一帧”的目的。reponse帧发送的Hash值为第一次该帧发送的时间哈希值,控制端第一次发送500帧,之后每隔4秒钟再增加50帧发送,直到收到request帧携带的Hash与当前帧的Hash值相同为止,否则不发送下一帧。从而达到“确认帧已经送达”的目的。通过这种逻辑,从而保证帧不会丢失。
此外,被控端每次会将最新收到的帧的hash存在本地,每收到response帧时,会将Hash值与本地的hash值进行比较,如果不一致,则执行相关动作,否则,则抛弃该帧。通过这种逻辑,从而保证帧丢失、帧缓存等问题。
考虑到帧所携带的数据量有限,且传输距离较短,因此没有对帧数据进行校验,默认接收到的帧都是正确的,实验测试也表明,没有必要对帧数据进行校验。
脚本使用方法
主控脚本采用传统的”参数+指令”方法,其对应参数及含义如下:
-h 脚本帮助 -c”command” 远程执行指令,建议执行的指令使用“”括起来,如果没有使用则只能执行单指令 -f”file path” 传输文件,路径可以为绝对路径,也可以为相对路径
示例:
打开计算器:
python main.py "cmd /c calc"
传输hello.txt文件:
python main.py "/root/Desktop/hello.txt"
踩过的坑
1.程序的整体逻辑比较简单、清晰。帧结构目前仍然有可扩展性,如帧头。
2.被控端在收到response帧后,会在本地进行缓存,导致被控端反复认为接收到该response帧,因此帧头采用hash值进行标识。
3.对于被控端,不同的攻击类型所需采用的执行方法不同,如执行命令攻击需要调用createProcess方法来执行命令,而传输文件则需要将帧内容写入文件。因此,对帧头进行了标识,根据标识在客户端采用不同的方法。
4.控制端的网卡需要切换至monitor模式
5.在文件多分片传输的情况下,可能会出现network down,为了解决这个问题,后续将开发续传功能。
6.一次传输完成大约需要3秒,且该时间随着传输距离的增加而增加,因此传输效率低,该问题有待于解决。
*本文作者:网络安全通,转载请注明来自FreeBuf.COM
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 【漏洞复现】WordPress插件Quizlord 2.0 XSS漏洞复现与分析
- Paxos与“幽灵复现”
- CVE-2010-3333漏洞复现
- CVE-2017-12149漏洞复现
- CSAW 2018 复现writeup
- WinRAR 代码执行漏洞复现
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Scrum敏捷软件开发
Mike Cohn / 廖靖斌、吕梁岳、陈争云、阳陆育 / 清华大学出版社 / 2010-11 / 69.00元
《Scrum敏捷软件开发》是敏捷联盟及Scrum联盟创始人之一、敏捷估算及计划的鼻祖Mike Cohn三大经典著作中影响最为深厚的扛鼎之作,也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考。作者花四年时间,把自己近十五年的敏捷实践经验,特别是近四年中针对各种敏捷转型企业的咨询和指导工作,并结合旁征博引的方式,从更高的思想层次对敏捷与Scrum多年来的经验和教训进行深入而前面的梳理和总结,最终集......一起来看看 《Scrum敏捷软件开发》 这本书的介绍吧!