http隐蔽信道简单总结

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

隐蔽通道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协议的协议头部)如果匹配命中,则没问题,如果匹配不成功,则说明可能存在这种大小写的调制信息的可能(这里可以取出各个首部名称出来,然后尝试调制这些信息)

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,就可以用如下的方式来调制,用这些空格,制表符,与换行符来调制这些值

相关文档
最新文档