http隐蔽信道简单总结.docx

隐藏通道CovertChannel,CC基于协议构造隐藏信道（从数据包特征，协议头部和数据收发行为）协议语法定义较为宽松，存在着很多冗余部分，可以用来嵌入隐藏信息不论是怎样的隧道软件,他都必需保证有两条TCP连接，且服务器端一般运用80或8080等具有迷惑性的端口（运用这种Web服务端口只是增加其迷惑性，磁道并不确定必须要运用这种端口，它可以隧道客户端和服务器端的协运用任何一个可用的端口建立连接）。作，有如下两种目前已实际采纳的方式简洁模型1.1.1直接型模式8堪IC.rTE*il"r11"BXWK主机A主机B1达更清晰，只示出了两台主机上的隧道软件担当自己各自的功能都会想到从协议首部的异样来进行检测，其实针对这个异样，我们首先应明确什么是正常的状态或者说的头部：在特定用户和特定环境下，阅读器所体现出的协议运用状况般的存在的的协议隐藏信息的存在点:1、重排序法：须要统计这些头部的各个字段的侬次（这些host标记位应样，可以依据五元组，在个会话里面对协议头标的依次进行统计（可以通过数组的方式来存储（动态安排数组）3.3.1持序法HTrP协议中头标的顺序是无关'案要的，在不同的实现中，头标的默认展序也是不同的.因此.可通过改变头标联序的方法来编码陵做信息.图3.8是重排序法的一个例子：在第1个请求包中，头标Host在前ConnBtion在后（见图3.8中的虚线框部分），这代奏二进制信息0（见图3.8中的圆圆部分）；在第2个请求包中，头标COnneCtion在前Host在后，这代裳二进制信息1.GBT/BrTF/1.1Accpt:/Accept-1.anguage:n-bAccept-Encodingsg”Q,dtlacUsr-AgnttMozilla/4.0(coapatlblJMSIt.0Host:www.bbc.coaGKT/HTTP/1.1I第2个请求Accept:/,Accept-1.angua:n-gbAccept-Encoding:gziprdeflateUsrAgnt:Hoz111a4.0(eptlbl,HSIK.0JConneccion:Keep-Alxv*/y.当mW-y¾j*m'图3.U）HTTP头标“桂序3、可选的头标/值/标记(嵌主要的是去推断Accept这个字段，在同-个host时候，统计这个ACCePt是否变更了，一般状况是不会发生变更的，这个我们也可以做一个初步的解析，依据我们所智驭的可能的调制的二进制数字，也许解析一下它这个解析的值的也许的意思，给用户一个提示作用，这个除藏信道可能是调制一种啥信息出去，这个不确定是正确，也就是给用户个提示作用，让用户能够感觉到这个信息的确是在传送隐藏信息)3.3.3利用可选的头标/值/标志例如.在客户堆发给Web服务器的HrrP请求包的义部中，Accept关标可能会准确地定义客户战在看应中可以接受的文件类型,也可能只是使用通配制(/)来友示客户看允许服务器响应任意类型的文件.这个特征可被用来端码数据.图3.10就是一个可实现的网络嬖放通道的例子：着ACcPa头标中的值是通配符，则代表二进制信息0：若Accpct头标中的值是具体的文件类型，则代表二进制信息IGET/KTTP/1.1Accepts*Accept-1.anguage:n-gbAccept-Bncoding:gzip,deflateU9r-9nt:M。ZilIa/4.0(compatible;MSIE6.0)HostJConnection:Keep-AliveGRT/WrTP/1.1I第2个i，短Accept:JtextZxml?*jq5Accept-Canguageengb-Accept-Bncodjng:gzp,dflatUSer-Agent:H。ZilIa/4.0(copatibl*MSIE6.0)ffi3.12利用可选的头出值Hoetiww.bbc.co*Connection:Keep-Alivw4、添加新头标:这里最主要的识别出那些不是RFC上面的恳求与响应字段，般的的恳求字段有：Authorization,Date,From,If-Modified-Since,0x48(01001000)®.GE11SPpISPHT11>l.1CR1.F/Host:SPwwu.napier.ac.uk|SP|HT|SP|SP|(HT|SP|SP|SP|CR1.FConnectio<4SPdoseSPHT11HTSPHTSPUSPHT)CR1.F.USer-AgemlSPJMOZilh/5.0(SPJ(WjnNT)CR1.F0x69(01101001)©图314利用旌线的空白字符串在这条请求中,主机A使用Tab制表符HT表示二进制信息1,使用空格SP表示二进制信息0,从而形成了一条发给主机B的隐蔽消息.主机A和主机B都知道，族码到第二行和第三行的8个比特分别代表着不同的ASCIl字符，它们共同组成防延消息(即秘密栽荷).编码到第二行中的ASCn字符的十六进制但是0x48(010010),嫔码到第三行中的ASCD字符的十六进制值是0x69(01101l),合在起，用人们可诙情的形式拼出来就是单词“Hi”.这条请求在标准的Web服务器看来是有效的.没有错误的.但是注意第二行和第三行结尾的大量空白字符.这有些异常，人们可能会怀便这个特殊请求中的这些不可打印字符的意图.在上例中，HTTP头被看做裁体,被编码成空白字符串的ASCiI字符是我荷，这只是在HTTP中够谶信息的方式之一.同样的方法也适用于SMTP.SMTP即简单肥件传检协议，是一组用于在源地址和目的地址之间传送邮件的规则，由它控制邮件的中转方式.人们例读邮件时，对于由空格或Tab制表符组成的空白部分，通常是不太在意的.利用这一点，可以把需要期藏的字符串消息编码成一系列的空格和Tab指标符.由于消息已经隐找到邮件中成为邮件体的一部分了,所以可以像发送普通部件一样将其发送出去.接收端将邮件体中含有降藏信息的部分进行解码就可获取原始信息T.方法-首部匹配，忏部-汗部匹配可疑度计算的具体分析：（须要用到下图）?<5-lHTTPftiW匹M（浏览;8）n.«ii'i«IHSflI次数h部2h*2出及次数Server20518Date20382Acccpt-1.aDaiMiac23653If-Mod11cd-SicB302Accept246llConnCCIiOn24720Uscr-Aftait24655Accept24690Accq)t-Eiicodmft24633If-Nonc-Ntatch9919Refaer25182Cookie20292Server20518Vmy1345Bag13905Caitait-RthH986TrH11xtIu>codm795Aet201.ocation250Expire?114因为浏览器的样本是标准的每考杆木,所以我们将以浏览器样本中出现的匹配上逐一与某进程的样本对照.制一个方法竹部兀W和首部首部匹配项都包含有如衣ST列出的4个M性，故设；浏览器样本中.方法或首部1的出现次数为Cl浏览器样本中.方法对应的背部或竹部2出现次数为C,?某进程样本中.方法或苒部I的出现次数为最某进税样本中，方法对应的首部或泞部2出现次改为C：注意CIoC:不一定相等.4也不一定相等.以G和C：为例.它们代友的意义如词或JR样本中.当方法或许部1出现C“次时,方法3应的苜部或首部2,方法或首51同时住网HTTP报文头郃中出现了次.再以去5-1为例，Jt,l,1.ocation的CI-2S0,Expires的C：114.这次小当1.ocation出现（250次时.Expires与1.ocation在同,个协议头部中同时存作的次数是114次.那么在剩卜的136（250-114）个存在1.。CatIon的协议头部中.ExPIrCS没有出现.不管是浏览瑞的样本还是某进程的样本,它们的CJjcJCJje:都代入这个意义.在用浏览器样本中的匹配项去逐刘熙某进程的徉本的匹配网过程中会出现两情况：A.在某进程的杆本中找到了个匹配顶，这个匹配的方法或苒部I的名称.方法对应的首部或首部2的名称1.j浏览器样本中的当前匹配项的对鹿的名称均相等.B.没仃在某进程的样本中找到个匹配项满足这个匹配的方法或花郃I的名称，方法对应的苜部或首部2的名称，浏览器样本中的*1附匹配J或的名称均相等.司总的首部首部匹配可疑度.为什么我们不以某进程的样本上逐对照浏览器的几代项呢？这是因为一U.HTTP隧道的'部来用了一种固定不变的对环境不敏魅的方法首部或首都"都匹fld就很难测得它的可疑度,闪为这时它们的比率凡和凡'相力就很小/.几手无法区分。用浏览器去逐一的以配某进程的样木,可以避免这种情况发生，还可以对许个对象迸程燃大限段的求得。参照样本的差距，使得可故僮区分较为明心.W外还有一种可能性,就是浏览器参考样本中不作的匹配J趴架进程的样木中却存在，如若出现这种可能性,我们不必担心测不到可疑度，因为浏览器样本的匹配项数”是庞大的,几乎把所付正常的可能出现的四间都包含了进去:如果某进程的朽木出现了连浏览器样本中都不存在的匹配顶，那说明该迸程的HTTP协议头部儿手是完全“胡乱”搭收的：这样由广浏览器样本庞大，这些胡乱搭配的头部总有相当郃分会落入我In的可冷测范用，这就能求出可疑度了.从另方而说，我的的检测在能分册得出可疑进程的前提卜捷W有开俏的方法越好.从理论上讲,当HTTP隧道没有刻意使用对环境不喊科的方法首部.首部.首部匹配的时候,上向的芽法能够使HTrP隧道狭得较大的可疑度.做足如果HTrP隧道栗川r不敢感的方法首部，首部首部匹配而努力的去接近浏览器的标准兀配的话，我的所求的可疑度向不会明显的区别得出HTTP隧道.但是,我勺可以通过前两范的方法逮住这HHTTP隧道,并根据本章的方法分析该HTTP陞道是否在协议头郃的创建上别行浙心思，通过这种分析，可以更进步的了解款I11TP隧道的设计水平和复杂度.值得庆季的是.该深找使用的HTTP-TiumclCliciit.exe就是上述所说的“别仃一小心思”的HTTP隧道,我们可以从科他头部的方法首都，首郃首部分析来在什它在模仿正常HTrP协议使用情况上作了怎样的考究首先看着几组实验数据.如图最1:万圣百那可见Irw>ai32.8K438Mtudll32.«.X.0lH3'>ply*rx*-><T8OB2SX.Y«ld.«<e4.TlO3S'.»；««,x->iT9723MfTTF-TtmnanKMK-XT2236首都甘郡CI战口'.radll32n->38S651VRoaflX32.>3.05565114>*.txe->3.8t81tfS三-m11r*r三->3.JH%91W3w<«»>384109«VKm-TwlAaalw«.->3(hss三4ffi5-l方Ji-H*25-S511fl?这是以浏览器样本4为参照测得的个实验结果.图中可%imP-TunnelClient.exe的方法-首部,首部-首湍可疑度均和我他对以进程外f.卜浓列出了分别以3组不同的浏览器样本为参照梆本1,%5).测得的各对象进程的方法11郃和酋部-首部可疑度.检测）事先定义好一些认为可疑的数据式样（SlGNATURE或叫PATTERN）;然后在对数据流的检测中，将数据流中的相关数据与这些式样相匹配，假如匹配上了就认为该数据流是可疑的。例如，我们事先定义好的数据式样有“cate:"、“catd:"、“dele:"、“PWD"、44RETRw.“emde:”.wcmdnetstart”等,在检测时，报文主体数据区假如出现了以上的数据样式之那么就判定该数据流是存在隧道的。如这个例子，若“cate:“、“catd:"被匹配上则认为可能该报文的主体数据在恳求远程主机显示什么文件,而不是正常的网页恳求;若“delc:"、"emdc:"、ucmdnetstartw匹配上了则认为该数据包是担忧全的，他在操作文件系统或运行某程序，可能有隧道存在；若*4PWDm.mRETR”匹配上了则判定这个数据流可能暗含了FTP连接。（缺点：a.隧道封装的数据可以是任何数据，多样性极强。数据是纷繁困难的，各种图像，声音，文本等等类型的数据都可以打包到隧道。我们定义的那些式样，无外乎是从内容想去找到一个独特性，然后去推断它是不是唯道。可是曜道本身是一个具才迷惑性的工具，它没有必要告知你它打包的数据是那种类型的，更何况他还会谎报，比如把文本说成是声音是有可能的。这样，假如我们以这种检测内容的方法去匹配式样，就得对每一个报文进行一次这个处理。这种开销是巨大的。而且面对各种类型的数据，我们在匹配的过程当中会得到大地错误结论。我们可以想象，假如把一个图片的二进制数据当作字符数据来和字符式样比较，就方可能出现PWDw.uRETR”等匹配，可它根本就不是文本。再者，即便是文本，哪怕不是有关计算机科学方面的文本，也常常出现这些关键字或缩写，这大大降低了基于签名检测的精确性。M主体数据加密给基于签名检测致命的打击。基于签名的检测事实上就要对数据的内容进行监测。可是一旦数据被加密，这种方法将完全失效）4.3. 2.2基于釜名的检赛这种检测方法使用特征码数据库来匹配数宛包的内容，从而发现违背安全策略的行为.所谓的特征码，即一种代表恶意或可疑意图攻击的模式.该过程可以很简堆，如通过字符串匹配以寻找一个荷单的条目或指令，也可以很复杂如利用正规的数学表达式来表示安全状态的变化.检泅网络除敲通道所使用的特征码有两种不同的类型，一种用于检测已知器敢通道，另一种用于检杳数据38第四拿网络险被通道的检测与防o包是否确文是由采用特定协议实现方法的软件产生的并且该数据包没有被等改过图45举例说明了这一概会：这里的服务器使用的是APadle系统，而响应包中却出现了以小写字母开头的头标“IASHlKXHfiaT,由此可以断定这个响应包要么是伪造的，要么就是被II改过.HTTP/1.1200OKDate:Thu,30Mar200619:46:22GMT-Serverj>ace2(UniX)lAst-modifie-Mon,19Feb200109,41:36GMTApachc系玩只使用大写字母开头”的方法生成头标tEfig,'e5B5J3400"-Accept-Ranges:bytesContent-1.ength:233Keep-Alive:timeout-5,max*300Connection:Keep-AliveContent-Type:text/html图4.4基于特征码的除溺方法基于特征码的检测系统稍微灵敏一些，一旦协议的具体实现与“合法消息生成器”数据库中的某一条不相符.告警就会出现.相咫地处理性能比基于协议的检测系统要高一些，不过还不算太高.C：数据收发行为检测隧道可以分为非专业个人开发的和专业性开发的两种。-TunnelClient.exe屈于专业性开发的隧道，在反探测方面作了很多探究。而其他各种个人开发的隧道就并没有这么多的探究。它或者在协议头部信息上，或者在数据收发行为上都会出现不同程度的可测出的异样C这里，我们还是以阅读器的包收发行为作为衡域标准，把跟它的差异叫做异样。从收发行为上分析，未经改良的隧道会存在如卜两小节所述的两个特点1、未经改良的隧道为了缩短收发延时，会实行“即来即发”的方式接受和发送数据包，“即来即发”指的是在一条本地（远程）连接上一接受到一个数据包，就立刻用协议头打包（对于远程来的包，就立刻拆封还原数据），紧接着把这个封包（原数据）立刻又发送到远程主机（本地主机）。也就是说这一系列动作是连续发生的，中间没有其他诸如缓冲之类的行为参加。事实匕大部分隧道都会实行这种行为。特殊是在不清晰哪个进程运用隧道的时候，隧道软件为了尽可能实现其透亮性，保证进程和远程主机通信的流畅，都会实行这种“即来即发”的行为模式。从接受到一个数据包，到处理完后把这个数据包发送出去所经验的时间，对于未改双隧道而言，一般不会超过3秒，间或由于系统资源调度缘由会超过5秒，但可能性特别小。因此，当我们在3秒内检测隧道的收发数据包比率的话，理论上就会得到很接近1:1的比值（虽然按这种收发行为工作的隧道应当体现出收发数据包比为定值1：1,但实际中会因为偶发的异样缘由或其他缘由，如系统资源调度等，致使我们的样本采集会在一些收发包上出现较大误差，故这个比值不是定值1：1,而是接近1：1）。另外，由于阅读器不具有隧道的传输模式，故不会有这种收发行为出现。这里多次强调是未经改R的隧道才会有这个比例。经过改良的隧道如-TunnelClient.exe,比如内部运用了缓存技术，它的收发包比率就不会接近1：1,而会低于这个值。-TunnelClient.exe的开发者曾说，他的隧道并不是一接受到数据包就简洁的打包发送出去，而是要等到约定的缓冲填满之后才发送到服务器端,事实上他是专业的隧道供应商，采纳的是隧道中转模式供应服务。他们的破道服务器端常带负荷很大，假如在客户端采纳缓冲，等缓冲区填满了才发送，就能减小服务器端的开销。当然这一举动不只仅仅减小了服务器开俏，还变更了隧道原有的收发数据包比率，给检测增加了难度，无疑是一箭双雕（虽然这样减小了服务器负荷，但是这样会影响客户端的响应速度，影响用户的运用，所以事实上为了满意用户须要，级冲耽搁的时间不能太长，因此改良的隧道收发数据包比值也不会很小或很大）。后边的试验中，将探讨一F-TunnelClient.exe扰乱数据收发行为检测的状况。我们后边将探讨的检测方法并不是把样本和比值1：1比照，而是仍归和阅读器的比值比照来求差异。这样就要求隧道又要再一次消耗自己效率去仿照阅读器才能避过检测。目前，除很少部分隧道外，大部分都是个人为了某种意图而开发的,不会考虑打包的过程中诸如增加很多缓冲的状况，故都会很大程度匕落入上面所提到的收发行为之中去。卜一节探讨的检测方法，就是在这个行为模式的基础匕结合阅读器样本实现检测的1、本地连接上传输的数据尺寸总和小于远程连接上传输的数据尺寸总和的可能性大。本地连接就是健道进程和本地某进程的连接。远程连接就是隧道进程和远程隧道进程的连接。直观上讲，由于本地连接上传输的是原数据，远程连接上传输的是增加了协议头部的数据，所以远程连接上传输的数据比本地连接上传输的数据尺寸总和要大。对于很多未经改口的隧道来说，这的确是一个很明显的特征C但是对于经过加密或压缩后的数据,就不能体现这个特征了。是因为它间接的和加密或压缩等具体的数据处理方法相联系，失去了通用性，二是假如采纳本地和远程连接的数据包尺寸总和比较大小的方法来求可疑度，由于只彳:两种选择（不大就小），且不能通过两方面数据包尺寸总和之差距来衡砧可疑度大小（隧道封包时头部加得多或少完全是作者自己的随机意图，也就是说就算远程连接匕的数据包总尺寸比本地连接上的数据包总尺寸大100O倍，都不能说它比两方面之比只大1倍的更具高的可疑度，因为大多少完全是随机的，不能去用可疑度盘化），因此就不能用来求对象进程的可疑度。总之，但对大部分未采纳加密和压缩的隧道来说，这个特征是特别显著的。分析模块中短暂分了8个模块.ChangecaseAnalyseO；/大小写变换JieadchangeAnalyseO;/协议头部利用空格字符与制表符进行隐藏信道的构建_hCadmaxcrroAnalyseO;/协议搭配错误_methodmaxerroAnalyse();/方法统计_autographAnalyse();/协议签名统计,HeadorderAnalyseO;/协议头部的依次统计_hCadAcceptAnalyse();/协议的头部的Accept字段接受文件的类型统计,AddheadAnalyseO;/协议头部信息的重新添加在这每个模块中，分别对我们的数据进行推断处理，分析出在数据中是否会存在可疑的地方，然后给出报警信息，在大小写变换与空格符制表符调制信息这一类的隐藏信道的构建过程的检测中，目前做了基于单个节点的统计(这里估计会有重复的信息报出，缘由我已经给出(我是替换了数据包中全部的某一头部标记字段，所以会存在这样的状况)，在会话中，假如存在这样的信息，我们就给出预警信息，并且简洁的给出相应的调制信息，在后面的针对协议头部依次，垂新添加头部信息这类的报瞥模块，是针对会话来报警，即在会话结束后，我们再给出报警信息。具体的操作在代码中有相应的注稀