http隐蔽信道简单总结.docx
《http隐蔽信道简单总结.docx》由会员分享，可在线阅读，更多相关《http隐蔽信道简单总结.docx（20页珍藏版）》请在冰豆网上搜索。
http隐蔽信道简单总结
隐蔽通道CovertChannel,CC
基于HTTP协议构造隐蔽信道（从数据包特征，协议头部和数据收发行为）
HTTP协议语法定义较为宽松，存在着很多冗余部分，可以用来嵌入隐蔽信息
不论是怎样的HTTP隧道软件,他都必须保证有两条TCP连接，且服务器端一般使用80或8080等具有迷惑性的端口（使用这种web服务端口只是增加其迷惑性，HTTP隧道并不一定必须要使用这种端口，它可以使用任何一个可用的端口建立连接）。
HTTP隧道客户端和服务器端的配合，有如下两种目前已实际采用的方式
简单http模型
1达更清楚，只示出了两台主机上的HTTP隧道软件担任自己各自的功能时的一种情况，当然反过来，A也能扮演图中B的角色,即成为服务器，B扮演图中A的角色,即成为客户端，效果一样。
如图所示，客户端和服务器端各自与本地主机建立至少一条TCP连接。
主机应用进程将原始数据发送到本机的HTTP隧道客户端或服务器端，经隧道软件用HTTP协议包装，然后发送到对方主机。
对方主机收到数据后，拆封HTTP包，然后把原始数据转发给本地的相应进程
代理模型
A：
基于协议的检测：
（基于HTTP协议头部标识）
协议头部的检测应该属于基于协议的检测（PROTOCOL-BASEDDETECTION）范畴。
但是目前有相当一部分基于协议的检测是探测某种协议的状态是否是处于约定的正常范围之内，如有异常状态发生就报警。
这种检测协议状态的方法适用于有状态的协议，如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协议的协议头部）如果匹配命中，则没问题，如果匹配不成功，则说明可能存在这种大小写的调制信息的可能（这里可以取出各个首部名称出来，然后尝试调制这些信息）
3、可选的头标/值/标志（最主要的是去判断Accept这个字段，在同一个host时候，统计这个Accept是否变化了，一般情况是不会发生变化的，这个我们也可以做一个初步的解析，根据我们所掌握的可能的调制的二进制数字，大概解析一下它这个解析的值的大概的意思，给用户一个提示作用，这个隐蔽信道可能是调制一种啥信息出去，这个不一定是正确，也就是给用户一个提示作用，让用户能够感觉到这个信息确实是在传送隐蔽信息）
4、添加新头标：
这里最主要的识别出那些不是RFC上面的请求与响应字段，一般的http的请求字段有：
Authorization，Date，From，If-Modified_Since，MIME-Version，Pragma
Referer，User-Agent
响应字段：
Date，Location，MIME-Version，Pragma，Server，WWW-Authenticate
对于如果是添加了其他头标，则比较可疑（备注：
添加了新头标过后http还是能够正常请求处理的，如果是标准的http软件是不能够进行监听这些隐蔽信息，对于这个添加了新头标的，直接告警，因为正常的HTTP协议是不会搞出这样的不正常的头标的（这个可以依据HTTP协议的规范来，没有的协议头部这个是不正常的，由于HTTP协议本身的特点，它对这个自定义的这些头部是不会干涉的，所以就会对这些自定义的这些信息放行通过），一些隐蔽信道就可以通过这样的一些的增加头标的方式来传送隐蔽信息，如果是没加密的信息直接把这个新头标的信息给出，如果是加密的乱码我们直接提示出这个东西是加密了的（这里就涉及到了加密与没加密的判断了））
（针对添加了新头标的这种，我们需要做的就是判断，给RFC规定的http的协议类型做对比，如果是在http的协议报头出现了我们不能够识别的协议报头则可以报警处理，并且输出其中的信息，尝试解调出信息的内容）
5、利用连续的空白字符串+制表符进行隐蔽消息的传送
我们在用http的时候，对于其头部标识形如
，在这些标识后面还有一个空格符，首部字段名:
空格字段值，由于对于web浏览器看来，这样的一个或者多个空格它是不会有所影响的，这样就为隐蔽信道的实现提供了可能，这样我们需要检测其中的空格符+制表符的多少，正常情况下，这些是不会出现的，如果是异常则有可能在进行隐蔽信息的传输，具体传输如下所示，这里我们也可以调制出它所要表达的意思来，比如说我们要调制信息
Hi,就可以用如下的方式来调制，用这些空格，制表符，与换行符来调制这些值
下面给出几种涉及到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.exe3天就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,3399,400,401ccc...ccc某进程Content-Length值分布档案1,2,3399,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数据流的检测中，将数据流中的相关数据与这些式样相匹配，如果匹配上了就认为该数据流是可疑的。
例如，我们事先定义好的数据式样有“catc:
”﹑“catd:
”﹑“delc:
”﹑“PWD”﹑“RETR”﹑“cmdc:
”﹑“cmdnetstart”等。
在检测时，HTTP报文主体数据区如果出现了以上的数据样式之一，那么就判定该数据流是存在隧道的。
如这个例子，若“catc:
”﹑“catd:
”被匹配上则认为可能该HTTP报文的主体数据在请求远程主机显示什么文件，而不是正常的网页请求；若“delc:
”﹑“cmdc:
”﹑“cmdnetstart”匹配上了则认为该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隧道外，大部分都是个人为了某种意图而开发
升级会员 