TCP旁路干扰的特征与识别

2014-09-23 • 技术文章评论

一年前,某家ISP与学校合作,推出了10元半年的宽带。速度确实快一些,但该宽带运营商却通过TCP旁路干扰的方式嵌入广告甚至是攻击脚本来牟利。这种劫持方法在很多小ISP那里很常见,那么这种劫持是如何实现的又该如何检测呢?

原理

旁路干扰的原理,简而言之,就是抢先应答。当我们和某地址建立TCP连接时,发出[SYN]顺带一个seq=x(随机数),对方应答一个[SYN,ACK]顺带seq=y(也是随机)和ack=x+1,你再回复一个[ACK]顺带seq=x+1和ack=y+1,这时三次握手完成,连接被成功建立。但是假如在路由路径的中间某点有一台旁路设备,它先于真实的目标地址收到响应,然后伪造一个应答,那么这个应答会在真实目标地址的应答之前返回给你,这时你就收到了伪造的数据然后丢弃了真实的数据。

通过抓包,可以发现,TCP旁路干扰的方式按标志位特点来看一般有以下几种:RST干扰(比如就是不想让你访问某个地址,发现你访问了,抢先应答一个[RST]来重置连接)、SYN/ACK干扰破坏或欺骗握手、FIN干扰。第一种只是想中断你的连接,后两种却可以用来加广告搞攻击。

SYN/ACK干扰过程的假握手前奏上面已经说过了,当你GET请求时,返回一个HTTP 30x将请求引向另一个地址,标志位一般会是[FIN,PSH,ACK]。这种做法有可能出于好的目的,也可能是坏的目的。好就是小区缓存,当我们下载某些资源时尤其是大的文件时,有小区缓存会加速我们的下载。当然小区缓存也有盲目性,我曾经发现被劫持的某视频文件的地址和网站指向的CDN在同一IP段,可能就在一个机房里,白缓存了一遍;再有就是缓存有时候仅仅根据URL做判断有可能已经是脏数据。坏就是插广告,比如跳转到一个包含真正目的地址的iframe,父框架放广告,或者劫持了页面JS加广告。

FIN干扰就是替换掉你要访问的页面,主要是返回[FIN,ACK]标志位HTTP 200的一个iframe。

危害

一般而言是遇到广告有些心烦,不过有些ISP做事情没有底线,除了插广告还做攻击。我就曾遇到运营商劫持返回的JS里直接就是攻击脚本而不是什么普通的广告,直接和黑产对接了。iframe算是比较笨的方法了,劫持JS文件效果更好,一来这些静态文件具有稳定性可以将恶意脚本追加其后神不知鬼不觉,二来不用浏览器地址栏地址发生变化。例如很多用户喜欢浏览器记住密码,但是假如JS被劫持,劫持者在尾部加入JS使页面加载完成后将用户名和密码从input的value取出并作为参数发送给某个指定URL,那么用户的密码就失窃了,想想还是蛮可怕的。再有就是劫持插入JS去劫持路由器,之后便进入了流量劫持的范畴,想怎么搞就可以怎么搞了。

识别

腾讯安全应急响应中心有一篇博客说可以通过TTL值判别是否受到了劫持干扰,但这种方法是不太靠谱的。现在的网络架构很复杂,由于一些负载均衡、防火墙、加速设备的存在,有可能让TTL变得很怪,靠TTL来判断非常不合理。

但是如果我们根据其原理综合标志位、RTT、TTL等因素来判断,准确性会有很大提高。首先看标志位,共有6位:SYN(Synchronization)、ACK(Acknowledgment)、FIN(Finish)、RST(Reset)、PSH(Push)、URG(Urgent)。[SYN]、[SYN,ACK]、[ACK]通常用来三次握手建立连接,[FIN,ACK]、[ACK]通常用来四次握手结束连接,[RST,ACK]、[RST]通常用来立即结束连接。有一些组合通常被用来做坏事,[SYN,FIN]这个非常矛盾的家伙有时被用来做扫描,还有[SYN,FIN,RST]、[SYN,FIN,PSH]、[SYN,FIN,RST,PSH]基本上是用来攻击的,仅包含[FIN]一般用于端口扫描,还有什么标志位都没有的非法包。我们上面就遇到的几种标志位并不算特殊,很容易理解劫持者的意图,再有就是TTL差过大有可能是因为包不是来自同一机器,还是不同包的的RTT也可以发现一些端倪。我们可以将几次和某IP连接的一些信息存到LRU缓存中,下次连接时比较一下,就可以比较准确地判断是否是遭到了劫持了。

此外,还有更直截了当的办法就是判断收到的两次同seq的应答,前者一般就是劫持包,后者才是真正的包。

防护现状

据我所知TCP劫持的检测主要还是在商业的应用上,如很多IDS/IPS具备此类功能。感觉个人级安全上这块目前是空白,像什么360、瑞星等等安全软件都不会去管TCP劫持的问题。我认为个人级安全软件还是应该加入这块内容,毕竟弹广告还是小事,但用来作攻击未尝不可。

参考文献与扩展阅读

http://wenku.baidu.com/view/755b399cf121dd36a32d82a6.html

http://www.symantec.com/connect/articles/abnormal-ip-packets