http隐蔽信道简单总结

隐蔽通道Covert Channel, CC

基于HTTP协议构造隐蔽信道（从数据包特征，协议头部和数据收发行为） HTTP 协议语法定义较为宽松，存在着很多冗余部分，可以用来嵌入隐蔽信息

不论是怎样的 HTTP 隧道软件,他都必须保证有两条 TCP 连接，且服务器端一般使用 80 或 8080 等具有迷惑性的端口（使用这种 web 服务端口只是增加其迷惑性，HTTP 隧道并不一定必须要使用这种端口，它可以使用任何一个可用的端口建立连接）。HTTP 隧道客户端和服务器端的配合，有如下两种目前已实际采用的方式

简单http模型

1达更清楚，只示出了两台主机上的 HTTP 隧道软件担任自己各自的功能时的一种情况，当然反过来，A 也能扮演图中 B 的角色,即成为服务器，B 扮演图中 A 的角色,即成为客户端，效果一样。如图所示，客户端和服务器端各自与本地主机建立至少一条 TCP 连接。主机应用进程将原始数据发送到本机的 HTTP 隧道客户端或服务器端，经隧道软件用 HTTP 协议包装，然后发送到对方主机。对方主机收到数据后，拆封 HTTP 包，然后把原始数据转发给本地的相应进程

代理模型

A：基于协议的检测：（基于HTTP协议头部标识）

协议头部的检测应该属于基于协议的检测（PROTOCOL-BASED DETECTION）范畴。但是目前有相当一部分基于协议的检测是探测某种协议的状态是否是处于约定的正常范围之内，如有异常状态发生就报警。这种检测协议状态的方法适用于有状态的协议，如 TCP，DHCP 等协议。对于无状态的 HTTP 协议则不能使用这种检测方法。那么，我们就需要从其他方面来考虑怎么检测 HTTP 隧道。在面对这个问题时我们都会想到从 HTTP 协议首部的异常来进行检测，其实针对这个异常，我们首先应明确什么是正常的状态或者说HTTP的头部：在特定用户和特定环境下，浏览器所体现出的 HTTP 协议使用情况

一般的存在的http的协议隐藏信息的存在点：

1、重排序法：需要统计这些头部的各个字段的顺序（这些host标记位应一致，可以根据五元组，在一个会话里面对协议头标的顺序进行统计（可以通过数组的方式来存储（动态分配数组）））

2、大小写变换法：

（需要分析协议头标名称中的大小写，正常情况协议头部信息的标识都不会异常的，一般都会符合正常通信的规则，例如Connection ：Keep-Alive --可以改为ConnECtion ：Keep-Alive 即可代表0111001111，或者是1000110000，这个我们是可以不用深究它这个具体是啥意思，只需要匹配出它这个协议的标识不正常即可）

通过这些信息，我们可以进行估计这些信息所传送的信息的值，比如说上面所说的ConnECtion ：Keep-Alive 即可代表0111001111，也就是可以代表0x72即R或者是1000110000，但是这个没意思的一个值，所以很可能是代表R，所以我们可以做一个估计，一般估计的值应该是比较常见的东西，比如说字母或者是数字之类的，一般就是说常见的ASSIC码值（如果是调制出来的信息为0~9，A~Z，a~z我们都可以提示，如果是其他信息，我们就可以不做处理或者是其他处理（根据相应情况提示加密之类的））

需要的数据有：Http协议头部的各个字段（可以用一个数组保存这些首部名称，然后进行匹配这些信息）（头部名称《具体的大小写匹配》）的信息，大小写如下

先转换为小写，然后匹配在这些数据中是否存在首部信息的完整信息，如果存在，然后把没转换的来匹配（标准的http协议的协议头部）如果匹配命中，则没问题，如果匹配不成功，则说明可能存在这种大小写的调制信息的可能（这里可以取出各个首部名称出来，然后尝试调制这些信息）

下面给出几种涉及到http的协议头部异常的情况（区别上面所提到的直接看协议异常）：HTTP-TunnelClient.exe(特别关注) 1、请求方法和首部，首部和首部的搭配异常

这种只需要的是匹配，比如说一个if（A && B）即可

多数 HTTP 隧道在设计时只考虑使用 HTTP 协议封装数据，忽略了方法和首 部，首部和首部的搭配。于是就会出现诸如 HEAD 方法的响应会带消息主 体,If-Modified-Since 与 If-Not-Modified-Since 首部同时出现在一个报文头部等等非常荒谬的情况。当然这已经是比较极端的例子了。大多数情况下，这些在设计上没有考虑方法-首部，首部-首部搭配规范的 HTTP 隧道，会不知不觉的用一些很少出现的方法-首部或首部-首部的搭配。这里说很少出现，是相对于“正常 HTTP 协议的使用情况”而言的，即某用户在使用浏览器的过程中，浏览器接收到的 HTTP报文中很少出现的方法-首部，或首部-首部搭配。那么哪些属于为数较多的搭配，哪些又是为数较少的搭配呢？下表是关于浏览器的 HTTP 协议首部-首部搭配的部分样本数据。如下所示统计信息：

从表中我们可以看到，为数较多的匹配是首部 1 和同一行的首部 2 的出现次数相当的匹配。如 Server 和 Date，Accept 和 Connection，User-Agent 和 Accept 等匹配都属于为数较多的。从这些为数较多的匹配的出现次数上看，首部 1 和首部 2 几乎都是成对出现的。也就是说如果首部 1 出现了，那么首部 2 就几乎没有不出现的可能性。反过来对于较少出现的匹配，如 Server 和 Vary 等，首部 1 的出现几乎不伴有首部 2 的出现。匹配出现的较多或较少是受到多方面因素制约（如大多数WEB 服务器遵守的 HTTP 协议规范，WEB 服务器自身的个性特点，用户喜好上的那些网站等等都会影响匹配的出现频度），因此在另一个环境中采集到的浏览器首部-首部匹配样本可能不会体现出表 5-1 的情况，而体现出样本所在的环境的情况。

下图给出了报文中的首部的各个字段在请求，应答，与主体中出现与否

对于设计上未考虑这些正常匹配的 HTTP 隧道来说，它们在封装数据时可 能是随机的挑选某个方法和某些首部，也可能是固定的就用某个方法和某些首部，还可能是在自己已选中的方法和首部中随便的挑选。这样，这些“胡乱”搭配的组合就不可能出现类似表 5-1 列出的那些匹配情况。这里关键在于“胡乱”搭配的组合体现 HTTP 隧道自身的特点，它完全不顾，也不可能顾及到实际环境中用户的行为特点。因此由用户实际行为产生的浏览器标准样本中的匹配情况就一定会和这些“胡乱”搭配的组合情况有很大的差距。根据“正常 HTTP 协议的使用情况”的定义，这个差距越大，就越是异常

方法-首部，首部-首部匹配异常是针对大多数非专业的 HTTP 隧道而言的

方法-首部匹配，首部-首部匹配可疑度计算的具体分析：（需要用到下图）

2、某一种方法的高频出现（比如说post提交数据的方法（例如HTTP-TunnelNG 中，就是完全使用POST 方法打包和传输数据的），还比如说PUT，因为 PUT也可以带消息主体，而且 HTTP 隧道也可以把需要传输的数据放到首部的赋值里，这样一来不但会使非 POST，非 PUT 方法高频出现，也会引起首部赋值异常）

虽然如今 HTTP-TunnelClient.exe 在 HTTP 协议头部的构造方面也更加考究了，但在样本数据看来，POST 的使用还是相当频繁（浏览器 50 天的样本含有 301 个 POST，HTTP-TunnelClient.exe 3 天就 3234 个 POST）

在浏览网页时，我们有时会向服务器提交一些表单，或者在 bbs 论坛上发帖子。 这些时候，浏览器会使用 HTTP 协议的 POST 方法来提交数据；但是，我们提交表单也好，还是发帖子也好，都不会经常连续不断的提交数据；因此在正常情况下，POST 方法不会经常连续出现。但是有些“模仿过分”的 HTTP 隧道，为了假装浏览器在提交数据，也使用 POST 方法（其实他完全可以不使用 POST 也照样传递数据，所以说它“模仿过分”）；但这些 HTTP 隧道经常有连续不断的数据要打包发送出去，这就造成 POST 方法的泛滥。

优缺点：

若是HTTP隧道有意的模仿了浏览器的常见方法-首部，首部-首部匹配，就会降低头部分析的成功率。当然这也是必然的，因为我们检测头部的异常就是要看它距离浏览器的正常标准有多远，如果它也在有意的靠拢这个标准，且做的很考究，那检测成功率降低也是符合规律的。但我们不必担心的是，目前绝大多数 HTTP 隧道的头部做的并没有那样的考究，另一方面要做的那样考究就需要牺牲一部分隧道的效率，增加设计复杂度等等，这并不是 HTTP 隧道开发者所期望的。因此，一般的 HTTP 隧道都不会花力气仔细的模仿浏览器，所以采用这种统一检测匹配异常和高频异常的方法是很有实用价值的

3、首部的赋值异常

对于浏览器的方法-首部等匹配来说存在“对环境不敏感的匹配”，但这里谈 的首部赋值大部分都是对环境敏感的。浏览器的标准样本采自不同用户和不同环 境。不同用户会喜欢上不同的网站，不同的环境中安装了不同版本的操作系统和 其他软件，这些都会使 HTTP 首部的值千变万化，因此我们说首部赋值几乎都是对环境敏感的。但是因为对于一个用户来说，他总是会上一些经常去的网站，他总是不会老是改变操作系统和浏览器，因此一个用户的首部赋值档案就只能适于该用户了。这样，同样基于“正常 HTTP 协议的使用情况”的定义，我们知道，凡是在特定的环境中如果某使用 HTTP 协议的进程的首部赋值里边出现了浏览器中该首部没有的值，那这个进程的首部赋值就属于异常

在 HTTP 隧道中这种异常时有体现。如 Host 首部出现了一个陌生的主机名， Accept 首部出现了未见过的文件类型等等，这些都是极有可能发生的。HTTP 隧道的设计者不可能知道他的软件将会在谁的机上运行，首部到底该取什么值最为隐蔽，他也无法预先知道，因此如果把一个用户的浏览器首部赋值样本与 HTTP 隧道的首部赋值样本作比较，就能看出差异。当然有些首部的值虽然无法预先确定，但是设计者也可以先了解这些首部在实际运用中会较多的取到哪些值，然后

再估计用户可能会与一些用到这些值的 WEB 服务器交互，最后将这些估计值放进 HTTP隧 道 首 部 中 去 。 比 如 Accept 的 值 就 可 以 估 计 是 image/jpeg ，application/x-shockwave-flash 或 image/gif 等等多数时候都会遇到的文件类型，其他有些首部也可以这样估计。当然出现了这种情况是肯定会影响首部赋值的检测，但由于大多数 HTTP 隧道对首部赋值并不很讲究，再加上它们还可能会把某些数据设作首部的值加以传输（比如 GET 方法正常使用频率最高，但基本不带消息体，那么为了隐秘性，就可以把数据设作首部的值加以传输），因此对首部赋值的检测是必不可少的。在首部赋值的异常中，还有一个特殊的首部 Content-Length 需引起关注。之所以关注它，是因为它与数据包尺寸分析有关。单独检测 Content-Length 首部的值，将对头部分析的检测成功率有很大的促进作用。当然没使用到这个首部的 HTTP隧道就不必去谈论，但是使用到这个首部的 HTTP 隧道就大有检测的需要。比如HTTP-TunnelClient.exe 就使用了这个首部，而且它的取值非常怪异，基本上都取的一个较大的定值（在早期版本 HTTP-TunnelNG 中取的定值 40000；在最近的Content-Length 的取值检测中 HTTP-TunnelClient.exe 也获得最高的可疑度，可见开发者一直没注意这个异常）。Content-Length（HTTP 报文消息体的字节数） 首部的取值分布情况会体现 HTTP 隧道的数据包尺寸的表观特征，这个特征是有异于浏览器的。

首部-赋值分析

Content-Length 值分布分析（参差度分布可疑度的算法）

Content-Length 首部的值指明的是 HTTP 报文消息体的字节数。因为浏览器 样本中 Content-Length 首部值的各区间分布情况能够求出，而对象进程的Content-Length 首部值的分布情况也能求出，所以使用参差度分布可疑度的求法，可以计算出 Content-Length 首部值的分布可疑度

算法如下：

把浏览器和某进程的 Content-Length 值的样本分为[0，100]，[101，200]，[201，300]。。。。。。[39801，39900]，[39901，40000]，[40001，+∞]等 401 个区间（当然这些区间是按照实际需要来分的，一般取 0 到 50000 就足够体现出样本差异了）。分析样本，将 Content-Length 值出现在各个区间的次数统计出来，于是得到浏览器 Content-Length 值分布档案1, 2, 3 399, 400, 401c c c ...c c c某进程 Content-Length 值分布档案1, 2, 3 399, 400, 401c ′ c ′ c ′ ...c ′ c ′ c′同时得到浏览器Content-Length首部出现的次数n和某进程Content-Length 首部出现的次数n′然后按下式计算：

算法中区间的划分也可以更细，这随不同的设计需要可以更改。这个算法并 没有在意到底正常情况下 Content-Length 值是一个怎样的分布，而是在肯定 HTTP隧道的 Content-Length 值与正常情况存在差异的前提下进行计算的。这一点可以充分体现出该算法的自适应能力。每个人按自己的喜好都会经常浏览某几

个 WEB服务器上的网页。这些 WEB 服务器发送过来的 HTTP 报文的 Content-Length 值，直观上，体现这几个服务器 WEB 应用程序的打包特征，间接的却体现了用户的行为特点。又因为不同用户有不同的喜好，所以对不同用户采集的 Content-Length值样本只对被采集样本的用户有最大效力。这就是为什么该方法存在自适应性的原因。而且，因为 HTTP 隧道的开发者不可能预测用户的习惯，所以他不能像前边模仿首部匹配和付值那样，去预测和模仿 Content-Length 值的分布。这样，只要HTTP 隧道使用了 Content-Length 首部，那么对 Content-Length 值分布的检测是行之有效的，即具有有效性。

序号 1，2，3 的记录来自于 HTTP-TunnelClient.exe 和其他对象进程同时采 集的样本，序号 4，5，6 的记录是对应于 1，2，3 条记录只改变了HTTP-TunnelClient.exe 的样本得到的结果。可以看出，不同时间采集的HTTP-TunnelClient.exe 样本放到同一个用户环境中去检测，都会体现出很明显的、可疑度差异。这说明，HTTP 隧道的 Content-Length 值分布在任何时候都与正常HTTP 协议使用情况下的分布有着明显的差异。这个差异从表中看，至少波动在 23 到 82 倍于正常情况之间。所以，Content-Length 值分布的检测能比较明显的区别出 HTTP 隧道，为协议头部分析的正确率起到了促进作用。

B：基于签名的检测

基于签名的检测（特征值检测（或者说是基于 HTTP 数据包的外在特性来检 测））

事先定义好一些认为可疑的数据式样（SIGNATURE 或叫PATTERN ）；然后在对 HTTP 数据流的检测中，将数据流中的相关数据与这些式样相匹配，如果匹配上了就认为该数据流是可疑的。例如，我们事先定义好的数据式样有“cat c:” ﹑“cat d:” ﹑“del c:” ﹑“PWD” ﹑“RETR ” ﹑“cmdc:” ﹑“cmd net start”等。在检测时，HTTP 报文主体数据区如果出现了以上的数据样式之一，那么就判定该数据流是存在隧道的。如这个例子，若“cat c:”﹑“cat d:”被匹配上则认为可能该 HTTP 报文的主体数据在请求远程主机显示什么文件，而不是正常的网页请求；若“del c:” ﹑“cmd c:” ﹑“cmd net start”匹配上了则认为该 HTTP 数据包是不安全的，他在操作文件系统或运行某程序，可能有隧道存在；若“PWD” ﹑“RETR ”匹配上了则判定这个 HTTP 数据流可能暗含了 FTP 连接。 （缺点：

a. HTTP 隧道封装的数据可以是任何数据，多样性极强。数据是纷繁复杂的，各种图像，声音，文本等等类型的数据都可以打包到 HTTP 隧道。我们定义的那些式样，无外乎是从内容想去找到一个独特性，然后去判断它是不是 HTTP 隧道。可是 HTTP 隧道本身是一个具有迷惑性的工具，它没有必要告诉你它打包的数据是那种类型的，更何况他还会谎报，比如把文本说成是声音是有可能的。这样，如果我们以这种检测内容的方法去匹配式样，就得对每一个 HTTP 报文进行一次这个处理。这种开销是巨大的。而且面对各种类型的数据，我们在匹配的过程当中会得到大量错误结论。我们可以想象，如果把一个图片的二进制数据当作字符数据来和字符式样比较，就有可能出现“PWD” ﹑“RETR ”等匹配，可它根本就不是文本。再者，即便是文本，哪怕不是有关计算机科学方面的文本，也经常出现这些关键字或缩写，这大大降低了基于签名检测的准确性。b、HTTP 主体数据加密给基于签名检测致命的打击。基于签名的检测事实上就 要对数据的内容进行监测。可是一旦数据被加密，这种方法将完全失效）

C：数据收发行为检测

HTTP 隧 道 可 以 分 为 非 专 业 个 人 开 发 的 和 专 业 性 开 发 的 两 种 。HTTP-TunnelClient.exe 属于专业性开发的隧道，在反探测方面作了许多考究。而其他各种个人开发的 HTTP 隧道就并没有这么多的考究。它或者在协议头部信息上，或者在数据收发行为上都会出现不同程度的可测出的异常。这里，我们还是以浏览器的 HTTP 包收发行为作为衡量标准，把跟它的差异叫做异常。从收发行为上分析，未经改良的 HTTP 隧道会存在如下两小节所述的两个特点

1、未经改良的 HTTP 隧道为了缩短收发延时，会采取“即来即发”的方式接受和发送数据包。“即来即发”指的是在一条本地（远程）连接上一接受到一个数据包，就马上用 HTTP 协议头打包（对于远程来的 HTTP 包，就马上拆封还原数据），紧接着把这个封包（原数据）马上又发送到远程主机（本地主机）。也就是说这一系列动作是连续发生的，中间没有其他诸如缓冲之类的行为参与。事实上，大部分隧道都会采取这种行为。特别是在不清楚哪个进程使用隧道的时候，隧道软件为了尽可能实现其透明性，保证进程和远程主机通信的流畅，都会采取这种“即来即发”的行为模式。从接受到一个数据包，到处理完后把这个数据包发送出去所经历的时间，对于未改良 HTTP 隧道而言，一般不会超过 3 秒，偶尔由于系统资源调度原因会超过 5 秒，但可能性非常小。因此，当我们在 3 秒内检测 HTTP隧道的收发数据包比率的话，理论上就会得到很接近 1:1 的比值（虽然按这种收发行为工作的 HTTP 隧道应该体现出收发数据包比为定值 1:1，但实际中会因为偶发的异常原因或其他原因，如系统资源调度等，致使我们的样本采集会在一些收发包上出现较大误差，故这个比值不是定值 1:1，而是接近 1:1）。另外，由于浏览器不具有 HTTP 隧道的传输模式，故不会有这种收发行为出现。这里多次强调是未经 改 良 的 HTTP 隧 道 才 会 有 这 个 比 例 。 经 过 改 良 的 HTTP 隧 道 如 HTTP-TunnelClient.exe，比如内部使用了缓存技术，它的收发包比率就不会接近1:1，而会低于这个值。HTTP-TunnelClient.exe 的开发者曾说，他的 HTTP 隧道并不是一接受到数据包就简单的打包发送出去，而是要等到约定的缓冲填满之后才发送到服务器端。实际上他是专业的 HTTP 隧道提供商，采用的是 HTTP 隧道中转模式提供服务。他们的 HTTP 隧道服务器端经常负荷很大，如果在客户端采用缓冲，等缓冲区填满了才发送，就能减小服务器端的开销。当然这一举动不只仅仅减小了服务器开销，还改变了 HTTP 隧道原有的收发数据包比率，给检测增加了难度，无疑是一举两得（虽然这样减小了服务器负荷，但是这样会影响 HTTP客户端的响应速度，影响用户的使用，所以实际上为了满足用户需要，缓冲耽搁的时间不能太长，因此改良的 HTTP 隧道收发数据包比值也不会很小或很大）。后边的试验中，将讨论一下 HTTP-TunnelClient.exe 扰乱数据收发行为检测的情况。我们后边将讨论的检测方法并不是把样本和比值 1:1 对照，而是仍然和浏览器的比值对照来求差异。这样就要求 HTTP 隧道又要再一次消耗自己效率去模仿浏览器才能避过检测。目前，除很少部分 HTTP 隧道外，大部分都是个人为了某种意图而开发的,不会考虑打包的过程中诸如增加许多缓冲的情况，故都会很大程度上落

入上面所提到的收发行为之中去。下一节讨论的检测方法，就是在这个行为模式的基础上，结合浏览器样本实现检测的

1、本地连接上传输的数据尺寸总和小于远程连接上传输的数据尺寸总和的可能性大。本地连接就是 HTTP 隧道进程和本地某一进程的连接。远程连接就是 HTTP隧道进程和远程 HTTP 隧道进程的连接。直观上讲，由于本地连接上传输的是原数据，远程连接上传输的是增加了 HTTP 协议头部的数据，所以远程连接上传输的数据比本地连接上传输的数据尺寸总和要大。对于许多未经改良的 HTTP 隧道来说，这的确是一个很明显的特征。但是对于经过加密或压缩后的数据，就不能体现这个特征了。一是因为它间接的和加密或压缩等具体的数据处理方法相联系，失去了通用性，二是如果采用本地和远程连接的数据包尺寸总和比较大小的方法来求可疑度，由于只有两种选择（不大就小），且不能通过两方面数据包尺寸总和之差距来衡量可疑度大小（HTTP 隧道封包时头部加得多或少完全是作者自己的随机意图，也就是说就算远程连接上的数据包总尺寸比本地连接上的数据包总尺寸大 1000 倍，都不能说它比两方面之比只大 1 倍的更具高的可疑度，因为大多少完全是随机的，不能去用可疑度量化），因此就不能用来求对象进程的可疑度。总之，但对大部分未采用加密和压缩的 HTTP 隧道来说，这个特征是非常显著的。

分析模块中暂时分了8个模块 Http_changecaseAnalyse();//大小写变换 Http_headchangeAnalyse();//Http协议头部利用空格字符与制表符进行隐蔽信道的构建 Http_headmaxerroAnalyse();//http协议搭配错误 Http_methodmaxerroAnalyse();//http方法统计 Http_autographAnalyse();//http协议签名统计 Http_headorderAnalyse();//http协议头部的顺序统计 Http_headAcceptAnalyse();//http协议的头部的Accept字段接受文件的类型统计 Http_AddheadAnalyse();//http协议头部信息的重新添加

在这每个模块中，分别对我们的数据进行判断处理，分析出在数据中是否会存在可疑的地方，然后给出报警信息，在大小写变换与空格符制表符调制信息这一类的隐蔽信道的构建过程的检测中，目前做了基于单个节点的统计（这里估计会有重复的信息报出，原因我已经给出（我是替换了数据包中所有的某一头部标志字段，所以会存在这样的情况）），在会话中，如果存在这样的信息，我们就给出预警信息，并且简单的给出相应的调制信息，在后面的针对协议头部顺序，重新添加头部信息这一类的报警模块，是针对会话来报警，即在会话结束后，我们再给出报警信息。详细的操作在代码中有相应的注释

本文来源：https://www.bwwdw.com/article/olh.html