记录黑客技术中优秀的内容, 传播黑客文化,分享黑客技术精华

基于TCP/IP协议栈的隐写术和隐蔽通道(part 2)

2017-04-25 06:45

基于TCP/IP协议栈的隐写术和隐蔽通道,隐写术理论基础

在本文的第1篇中,我们提到过隐写术;现在,我们将对其进行深入的介绍。

隐写术有2类:

我们可以将莎士比亚戏剧文本隐写到一些斑马图像中,并确保没有人能觉察出来,因为对于观看图像的人来说,通常不会检查每个像素的每个字节的LSB。但是如果他们真的这样做的话,就会发现这些文本。 这属于“隐藏在平原地带”的隐写术。 整个第1篇中,我们将纯数据封装在TCP / IP报头中的方法,就属于此类别。

第二类(上述Tanenbaum的例子即属此类)隐写术就要好多了。它使用加密技术来确保即使把图像翻个遍,也看不出莎士比亚戏剧文本的痕迹,从而找不到相应的秘密了。

为什么说基于加密技术的隐写术要更好呢?因为这两种技术中的任何一种,都能给你提供保护。不同的是,如果你使用加密技术,虽然没有人能理解你说的话(授权的听众除外),但是所有人都知道你跟听众之间有一个通信信道,并且知道你可能会谈论一些秘密(这正是你使用加密技术的原因)。如果你使用隐写术的话,没有人觉察到通信信道。所以,别人也无法知道正在进行交流。换句话说,隐蔽通道就是一个别人不知道的通信通道。

坏消息是隐写术大部分情况下都会留下痕迹。有些时候是不言自明的。例如,图片中的LSB隐写术会导致色差,这很容易引起人们的怀疑。或者,在第1篇文章中,由于只能在随机字段中推送ASCII字节,这样就会显著降低这些字段中数据的熵——通过这种现象,通信信道甚至通信本身的可能性就会引起取证人员的注意。如果基于隐写术的隐蔽通道被发现了,那么它就降级到了单纯加密层面。

现在谈点完全不同的事情!

Pozzo & Lucky

Pozzo&Lucky是戏剧《等待戈多》中的两个关键人物。这部戏是爱尔兰现代主义剧作家塞缪尔·贝克特的两幕悲喜剧,也是它最著名的戏剧,同时也是我最喜欢的一部。

Lucky是一个没有自己的信仰、意见甚至想法的仆人。他盲目地服从Pozzo,Pozzo甚至用一条狗项圈牵着他。每当Pozzo发号命令,他都会跳舞。

在戏中,我们不知道为什么Lucky是如此可悲,任Pozzo摆布,做尽各种恶心的事情。他们之间一定有一个隐蔽通道...

但是,除了是戏剧的两个角色名字之外,Pozzo&Lucky还是一个个人项目。一个以打赌作为开始的项目。 “是否存在这样一种远程命令执行shell,既没有网络设备可以检测到它,也不会留下网络踪迹。我打赌有...

嗯,我赌赢了。这个shell确实存在并被命名为Pozzo&Lucky ...

思路

这里的思路与第1篇中的思路非常接近,我们将通过IP标识和TCP序列(ISN)字段来传递命令。 但是,这一次,我们做得更好...

Pozzo&Lucky shell由2个组件组成。Lucky必须安装到目标机器上(实际上只是在目标机器上面运行),Pozzo则是用于控制安装了Lucky的目标机器。

功能

执行OS命令(带输出和不带输出)

远程实时执行Shellcode(粘贴并执行)

文件上传/下载

完全绕过.pcap文件分析、防火墙日志分析和常规分析,从而阻碍取证人员从目标机器的操作系统上取证

能够模拟nmap -sS端口扫描或任何类型的SYN扫描,或将SYN Flood转发到特定(或给定)的一个或多个目标端口

可以用于Windows系统和Linux系统。

没有创建连接。同一个会话中的每一个数据包都可以从不同的源IP发送到不同的目标端口。

缺点

太慢! (带宽是5字节/包,所以要格外有耐心)

作为一个进程,它缺乏隐藏自身或持久性的能力。它必须与一个rootkit配合使用。

代理会杀死它(但是不会检测它)。它必须通过端口转发才能正常工作。

具有依赖性... 在Windows上依赖基于Winpcap的Scapv,在Linux上依赖Scapy。两者可能会被Pylnstaller-pv2exe-nuitka会话阻止。

要求

需要拥有目标主机的root / admin权限(由于数据包的构建和嗅探都需求超级权限)。

要求Pozzo与Lucky必须在同一个子网(如果它们所在主机都具有公共IP的话,只要连接Internet即可)中,至少Pozzo要有一个指向Lucky的TCP端口路由(如果Lucky位于一个只转发TCP的21端口的防火墙之后, Pozzo将数据包发送到:21即可。)

Pozzo不能位于NAT之后。 这是因为出站Pozzo数据包的源端口对Lucky是有意义的,但是NAT会修改这个字段(这是因为,在使用网关的IP转发之前,会将其转换为另一个源端口)。

概念

前面说过,Lucky运行在目标机器上面,实际上它就是一个数据包嗅探器。它能收到所有到达机器的数据包,通过下文将要介绍的算法来确定哪些数据包是由Pozzo所在的计算机创建的。

关键在于这些数据包没有建立连接(无论TCP还是UDP连接),它们是TCP SYN数据包,没有以任何方式滥用TCP协议(在本文的第3篇中,我们将详细讲解如何绕过(由安全设备和数据包检查程序进行的)协议完整性检查。同时,它们也是有用的数据包,通常不会被网络拦截(这与与ICMP不同),因为这样做就会破坏网络的运转(网络中不允许连接阻止SYN数据包,否则SQL、Web应用程序、FTP等统统挂掉...)。

这些“Pozzo数据包"的特征在于通过IP标识字段和TCP序列号字段(2字节+ 4字节)以强加密的形式提供6字节的数据,当Lucky遇到这样一个数据包时,会从中抽取6字节的有效负载,以1 + 5字节形式分割,其中第一个字节是用于随后5个字节的命令操作码。然后生成一个RST-ACK数据包(当然也不能违反TCP协议),并且注入(同时加密)到在目标机器上执行的命令的响应中,从而将其发送回Pozzo。

这种SYN-RST之间的交互,与远程命令执行相比,更像是端口扫描,因此它不会被IDS / IPS阻止,因为使用加密后,就没有匹配的签名了(并且它们很少检测3-4层的报头)。 一个配置良好的防火墙设备,如果考虑到了每个主机的使用情况(这是一个SSH服务器——只允许22端口),可以减轻Pozzo&Lucky带来的影响,但是这么做的并不多见!

解决面临的问题

在第1篇中,我们曾经提到一些问题,下面给出相应的解决方案。

克服熵问题

熵的问题是,虽然允许在随机字段中的每个字节位置中使用256个字节中的任何一个,但是我们只会使用可打印ASCII列表中相应字节,并且通常不包括大写字母和数字。 这使得随机字段会包含的数据具有较高的可预测性,从而导致数据的熵降低。

{C}对于这个问题,解决方案是加密。但是我们需要以6字节为块单位的加密技术,或流密码。 最重要的是,我们需要”style”...所以我根据明文XOR和SHA512定制了一个一次性密钥加密方案。这样的话,那根本就不缺少”style”!

OTP方案

你对通行字短语进行SHA512运算,从而得到一个密钥。然后,利用这个密钥对数据进行XOR运算,每次处理6字节的数据。经过异或处理的数据就被安全地加密了,因为密钥是通行字短语的单向函数,同时它是保密的。要加密下一个6字节的数据块,需要通过SHA512处理当前的密钥,并重新进行XOR运算。这样我们就不会使用相同的密钥进行XOR运算了,从而消除了通过已知明文进行密码分析的可能性,同时也消除了预测下一个密钥的可能性,即使我们始终加密相同的6个字节(例如wls -laH),每次可以恢复密钥部分是6个字节。单纯6个字节,无法提供足够的信息来产生下一个密钥,因为整个密钥是512位(64字节)的。

另外,使用这种方法的话,有可能对任何可能的字节进行XOR(SHA512返回包含各种字节的序列),我们得到的加密字节处于整个256字节范围内。而且它们具有相同的可能性...这意味着熵接近1,也就是说数据看上去是随机的。

克服身份问题

“谁是你的主人?”RCE shell必须知道如何回答这个问题。你可以远程运行命令,这是一件好事,但你必须是唯一可以这么做的人。也就是说,shell必须能够将你的数据包与其他人的数据包区分开来。并且为了在shell代理程序中加入IP检查功能,你必须将自己IP或域名硬编码到代理中。仅靠这一点是不够的,除非你采用了Exploit-Kits中快速更换子域名等技术,以及其他缺乏”style”的东西,否则这些数据包最终会被捕获和分析!

在本文的第1篇中,我们忘了TCP中的一个可控字段,同时在端口扫描中也无人关心它:源端口。 “好的,你会想,让数据包来自端口xxxx,那么这就是需要解密和执行的数据包”。 嗯,是的,但它也缺乏”style”。 所以需要:

解决“谁是你的主人”问题

源端口检查的思想在一定程度上是正确的,但是它有个很大的坑。这个想法实现起来很容易,不过同样也很容易被分析人员发现。如果您收到一个.pcap文件,涉及各种目标端口和一个源端口(甚至有多个源IP),这肯定会引起你的怀疑。

为什么端口扫描器需要在多个系统中分配端口23456?

这是通过硬编码实现的吗?

你了解这样的端口扫描器吗?

这是一种常见的行为吗?

在搜索引擎中搜索端口23456时没有返回结果。

所以这非常可疑。

在Pozzo&Lucky中,我们会检查数据包的源端口,但我们不指望它始终是一样的。此外,还有一个循环算法,类似于上面的OTP方案。

源端口字段包含2个字节,即4个十六进制数字。 我们根据给定的通行字短语(它必须大于8——始终得到高端口)来初始化第一个(最高有效位)数字。 然后我们利用SHA512处理该通行字短语,从而得到哈希值的前3个十六进制数字。然后,将它们与最初的十六进制数字组成4个十六进制数字或2个字节。然后我们重复哈希计算过程,也就是通过重新计算其哈希值来生成下一个端口。

这种技术能够提供不同的端口号,对于没有通行字短语的人来说,这将是一个完全不可预测的序列。只有代理程序(Lucky)和客户端(Pozzo)知道下一个正确的通信端口,并且出现具有正确源端口的“噪音”数据包的可能性为1/65536,所以可以忽略不计。

知识来源: www.2cto.com/article/201704/632469.html

阅读:69406 | 评论:0 | 标签:无

想收藏或者和大家分享这篇好文章→复制链接地址

“基于TCP/IP协议栈的隐写术和隐蔽通道(part 2)”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

公告

关注公众号hackdig,学习最新黑客技术

推广

工具

标签云

本页关键词