《http隐蔽信道简单总结》由会员分享，可在线阅读，更多相关《http隐蔽信道简单总结（9页珍藏版）》请在金锄头文库上搜索。
1、【精品文档】如有侵权，请联系网站删除，仅供学习与交流http隐蔽信道简单总结.精品文档. 隐蔽通道Covert Channel, CC基于HTTP协议构造隐蔽信道（从数据包特征，协议头部和数据收发行为）HTTP 协议语法定义较为宽松，存在着很多冗余部分，可以用来嵌入隐蔽信息 不论是怎样的 HTTP 隧道软件,他都必须保证有两条 TCP 连接，且服务器端一般使用 80 或 8080 等具有迷惑性的端口（使用这种 web 服务端口只是增加其迷惑性，HTTP 隧道并不一定必须要使用这种端口，它可以使用任何一个可用的端口建立连接）。HTTP 隧道客户端和服务器端的配合，有如下两种目前已实际采用的方式简
2、单http模型1达更清楚，只示出了两台主机上的 HTTP 隧道软件担任自己各自的功能时的一种情况，当然反过来，A 也能扮演图中 B 的角色,即成为服务器，B 扮演图中 A 的角色,即成为客户端，效果一样。如图所示，客户端和服务器端各自与本地主机建立至少一条 TCP 连接。主机应用进程将原始数据发送到本机的 HTTP 隧道客户端或服务器端，经隧道软件用 HTTP 协议包装，然后发送到对方主机。对方主机收到数据后，拆封 HTTP 包，然后把原始数据转发给本地的相应进程代理模型A：基于协议的检测：（基于HTTP协议头部标识）协议头部的检测应该属于基于协议的检测（PROTOCOL-BASED DETE
3、CTION）范畴。但是目前有相当一部分基于协议的检测是探测某种协议的状态是否是处于约定的正常范围之内，如有异常状态发生就报警。这种检测协议状态的方法适用于有状态的协议，如 TCP，DHCP 等协议。对于无状态的 HTTP 协议则不能使用这种检测方法。那么，我们就需要从其他方面来考虑怎么检测 HTTP 隧道。在面对这个问题时我们都会想到从 HTTP 协议首部的异常来进行检测，其实针对这个异常，我们首先应明确什么是正常的状态或者说HTTP的头部：在特定用户和特定环境下，浏览器所体现出的 HTTP协议使用情况一般的存在的http的协议隐藏信息的存在点：1、重排序法：需要统计这些头部的各个字段的顺序（
4、这些host标记位应一致，可以根据五元组，在一个会话里面对协议头标的顺序进行统计（可以通过数组的方式来存储（动态分配数组）2、 大小写变换法：（需要分析协议头标名称中的大小写，正常情况协议头部信息的标识都不会异常的，一般都会符合正常通信的规则，例如Connection ：Keep-Alive -可以改为ConnECtion ：Keep-Alive 即可代表0111001111，或者是1000110000，这个我们是可以不用深究它这个具体是啥意思，只需要匹配出它这个协议的标识不正常即可）通过这些信息，我们可以进行估计这些信息所传送的信息的值，比如说上面所说的ConnECtion ：Keep-Al
5、ive 即可代表0111001111，也就是可以代表0x72即R或者是1000110000，但是这个没意思的一个值，所以很可能是代表R，所以我们可以做一个估计，一般估计的值应该是比较常见的东西，比如说字母或者是数字之类的，一般就是说常见的ASSIC码值（如果是调制出来的信息为09，AZ，az我们都可以提示，如果是其他信息，我们就可以不做处理或者是其他处理（根据相应情况提示加密之类的）需要的数据有：Http协议头部的各个字段（可以用一个数组保存这些首部名称，然后进行匹配这些信息）（头部名称具体的大小写匹配）的信息，大小写如下先转换为小写，然后匹配在这些数据中是否存在首部信息的完整信息，如果存在，
6、然后把没转换的来匹配（标准的http协议的协议头部）如果匹配命中，则没问题，如果匹配不成功，则说明可能存在这种大小写的调制信息的可能（这里可以取出各个首部名称出来，然后尝试调制这些信息）3、可选的头标/值/标志（最主要的是去判断Accept这个字段，在同一个host时候，统计这个Accept是否变化了，一般情况是不会发生变化的，这个我们也可以做一个初步的解析，根据我们所掌握的可能的调制的二进制数字，大概解析一下它这个解析的值的大概的意思，给用户一个提示作用，这个隐蔽信道可能是调制一种啥信息出去，这个不一定是正确，也就是给用户一个提示作用，让用户能够感觉到这个信息确实是在传送隐蔽信息）4、添加新
7、头标：这里最主要的识别出那些不是RFC上面的请求与响应字段，一般的http的请求字段有：Authorization，Date，From，If-Modified_Since，MIME-Version，PragmaReferer，User-Agent响应字段：Date，Location，MIME-Version，Pragma，Server，WWW-Authenticate对于如果是添加了其他头标，则比较可疑（备注：添加了新头标过后http还是能够正常请求处理的，如果是标准的http软件是不能够进行监听这些隐蔽信息，对于这个添加了新头标的，直接告警，因为正常的HTTP协议是不会搞出这样的不正常的头标
8、的（这个可以依据HTTP协议的规范来，没有的协议头部这个是不正常的，由于HTTP协议本身的特点，它对这个自定义的这些头部是不会干涉的，所以就会对这些自定义的这些信息放行通过），一些隐蔽信道就可以通过这样的一些的增加头标的方式来传送隐蔽信息，如果是没加密的信息直接把这个新头标的信息给出，如果是加密的乱码我们直接提示出这个东西是加密了的（这里就涉及到了加密与没加密的判断了）（针对添加了新头标的这种，我们需要做的就是判断，给RFC规定的http的协议类型做对比，如果是在http的协议报头出现了我们不能够识别的协议报头则可以报警处理，并且输出其中的信息，尝试解调出信息的内容）5、 利用连续的空白字符串
9、+制表符进行隐蔽消息的传送我们在用http的时候，对于其头部标识形如，在这些标识后面还有一个空格符，首部字段名: 空格 字段值 ，由于对于web浏览器看来，这样的一个或者多个空格它是不会有所影响的，这样就为隐蔽信道的实现提供了可能，这样我们需要检测其中的空格符+制表符的多少，正常情况下，这些是不会出现的，如果是异常则有可能在进行隐蔽信息的传输，具体传输如下所示，这里我们也可以调制出它所要表达的意思来，比如说我们要调制信息Hi,就可以用如下的方式来调制，用这些空格，制表符，与换行符来调制这些值下面给出几种涉及到http的协议头部异常的情况（区别上面所提到的直接看协议异常）：HTTP-Tunnel
10、Client.exe(特别关注)1、 请求方法和首部，首部和首部的搭配异常这种只需要的是匹配，比如说一个if（A & B）即可多数 HTTP 隧道在设计时只考虑使用 HTTP 协议封装数据，忽略了方法和首部，首部和首部的搭配。于是就会出现诸如 HEAD 方法的响应会带消息主体,If-Modified-Since 与 If-Not-Modified-Since 首部同时出现在一个报文头部等等非常荒谬的情况。当然这已经是比较极端的例子了。大多数情况下，这些在设计上没有考虑方法-首部，首部-首部搭配规范的 HTTP 隧道，会不知不觉的用一些很少出现的方法-首部或首部-首部的搭配。这里说很少出现，是相
11、对于“正常 HTTP 协议的使用情况”而言的，即某用户在使用浏览器的过程中，浏览器接收到的 HTTP报文中很少出现的方法-首部，或首部-首部搭配。那么哪些属于为数较多的搭配，哪些又是为数较少的搭配呢？下表是关于浏览器的 HTTP 协议首部-首部搭配的部分样本数据。如下所示统计信息：从表中我们可以看到，为数较多的匹配是首部 1 和同一行的首部 2 的出现次数相当的匹配。如 Server 和 Date，Accept 和 Connection，User-Agent 和 Accept 等匹配都属于为数较多的。从这些为数较多的匹配的出现次数上看，首部 1 和首部 2 几乎都是成对出现的。也就是说如果首部
12、 1 出现了，那么首部 2 就几乎没有不出现的可能性。反过来对于较少出现的匹配，如 Server 和 Vary 等，首部 1 的出现几乎不伴有首部 2 的出现。匹配出现的较多或较少是受到多方面因素制约（如大多数WEB 服务器遵守的 HTTP 协议规范，WEB 服务器自身的个性特点，用户喜好上的那些网站等等都会影响匹配的出现频度），因此在另一个环境中采集到的浏览器首部-首部匹配样本可能不会体现出表 5-1 的情况，而体现出样本所在的环境的情况。下图给出了报文中的首部的各个字段在请求，应答，与主体中出现与否对于设计上未考虑这些正常匹配的 HTTP 隧道来说，它们在封装数据时可能是随机的挑选某个方法
13、和某些首部，也可能是固定的就用某个方法和某些首部，还可能是在自己已选中的方法和首部中随便的挑选。这样，这些“胡乱”搭配的组合就不可能出现类似表 5-1 列出的那些匹配情况。这里关键在于“胡乱”搭配的组合体现 HTTP 隧道自身的特点，它完全不顾，也不可能顾及到实际环境中用户的行为特点。因此由用户实际行为产生的浏览器标准样本中的匹配情况就一定会和这些“胡乱”搭配的组合情况有很大的差距。根据“正常 HTTP 协议的使用情况”的定义，这个差距越大，就越是异常方法-首部，首部-首部匹配异常是针对大多数非专业的 HTTP 隧道而言的方法-首部匹配，首部-首部匹配可疑度计算的具体分析：（需要用到下图）2、
14、 某一种方法的高频出现（比如说post提交数据的方法（例如HTTP-TunnelNG 中，就是完全使用POST 方法打包和传输数据的），还比如说PUT，因为 PUT也可以带消息主体，而且 HTTP 隧道也可以把需要传输的数据放到首部的赋值里，这样一来不但会使非 POST，非 PUT 方法高频出现，也会引起首部赋值异常） 虽然如今 HTTP-TunnelClient.exe 在 HTTP 协议头部的构造方面也更加考究了，但在样本数据看来，POST 的使用还是相当频繁（浏览器 50 天的样本含有 301 个 POST，HTTP-TunnelClient.exe 3 天就 3234 个 POST）在
15、浏览网页时，我们有时会向服务器提交一些表单，或者在 bbs 论坛上发帖子。这些时候，浏览器会使用 HTTP 协议的 POST 方法来提交数据；但是，我们提交表单也好，还是发帖子也好，都不会经常连续不断的提交数据；因此在正常情况下，POST 方法不会经常连续出现。但是有些“模仿过分”的 HTTP 隧道，为了假装浏览器在提交数据，也使用 POST 方法（其实他完全可以不使用 POST 也照样传递数据，所以说它“模仿过分”）；但这些 HTTP 隧道经常有连续不断的数据要打包发送出去，这就造成 POST 方法的泛滥。优缺点：若是HTTP隧道有意的模仿了浏览器的常见方法-首部，首部-首部匹配，就会降低头
16、部分析的成功率。当然这也是必然的，因为我们检测头部的异常就是要看它距离浏览器的正常标准有多远，如果它也在有意的靠拢这个标准，且做的很考究，那检测成功率降低也是符合规律的。但我们不必担心的是，目前绝大多数 HTTP 隧道的头部做的并没有那样的考究，另一方面要做的那样考究就需要牺牲一部分隧道的效率，增加设计复杂度等等，这并不是 HTTP 隧道开发者所期望的。因此，一般的 HTTP 隧道都不会花力气仔细的模仿浏览器，所以采用这种统一检测匹配异常和高频异常的方法是很有实用价值的3、首部的赋值异常对于浏览器的方法-首部等匹配来说存在“对环境不敏感的匹配”，但这里谈的首部赋值大部分都是对环境敏感的。浏览器的标准样本采自不同用户和不同环境。不同用户会喜欢上不同的网站，不同的环境中安装了不同版本的操作系统和其他软件，这些都
