工作期间遇到一次由于HTTP和TCP层被劫持的问题。这是向相关负责人发送的通知邮件,可以给大家作为一个参考。已隐去部分商业相关信息。
现状
这个问题是由于暴力流量劫持导致的,我对这方面比较熟悉的原因比较特殊,一是我曾经在运营商工作过,主要工作内容中有一部分是负责路由交换设备和宽带接入;二是我曾在两家公司都负责网络加速设备的开发测试和支持工作,接触过的相关产品就更多一些。向这个问题,很明显就能看出来是怎么回事。
目前互联网状况堪忧。业内人士不想多提,业外人士孤陋寡闻,除了DNS劫持之外业外几乎对其他手段没什么概念。
计划
我曾在两年前想过写一篇关于互联网加速硬件与流量劫持相关的文章,但是苦于由于没有精力,就一直没有写。现今关于运营商流量劫持的问题愈演愈烈,不少朋友都遇到过流量被恶意劫持的问题。感觉也是到了该认真考虑这篇文章的时候了。
本篇文章只是处理一次此类问题时的邮件。估计在不久的将来我会正式写一篇关于此类问题的起源发展相关的文章。
正文原文
某公司网络,下载升级包出现问题
抓包分析如下:
在某公司网络环境下,尝试下载升级包,出现流量被302污染的情况,导致请求被劫持到网络上的某一台缓存服务器上,下载的更新包并非更新包。
细节如下:
某公司网络环境下抓包:
数据包:
解析:
分析:客户端PC机192.168.2.101向服务器发送请求,三次握手(8316,8317,8318)后,建立连接, 发起HTTP请求下载NBCShare_setup_3.9.exe (8321)。 之后网络上有未知设备伪装为服务器,强行插入此次TCP会话,向客户PC机回应HTTP 302跳转,劫持了此次请求。用户发起的向服务器的下载请求被劫持到:
http://36.110.79.137:80/AESd/DnTfCw.fCw0eDvjgEq__/update/NBCShare_setup_3.9.exe
之后此网络设备向客户PC机发出此连接终止FIN(8325),阻断真实的服务器与客户PC交互。 客户PC收到FIN请求后回应(8326,8327),真实的服务器由于收到非期望的连接中指指令和数据包乱序,报错后退出此次会话(8329,8330) 客户PC流量在被劫持后,自动跳转到未知的服务器(36.110.79.137),继续下载。下载的此文件具体是什么,安全性,来源,均无法确定。
正常网络环境下的数据包:
数据包:
解析:
分析: 浏览器发出Get请求后,服务器直接回应HTTP 200 OK,并开始回应下载。
问题原因分析: 目前根据以往经验,可以确认此未知服务器(36.110.79.137)是一台缓存服务器,此302跳转劫持以及url的写法,极有可能是锐捷公司贴牌生产的缓存服务器,或是鹏博士旗下二级运营商链路中的缓存服务器。这种缓存服务器一般以监听用户流量,并强行在其流量中插入tcp数据包,劫持http流量至自身内部服务器组,以达到节省带宽使用的目的。其缓存方式违背HTTP标准协议,缓存规则不确定,缓存文件可被其管理人员替换,经常导致网络问题。 (此服务器限制网络外部访问,不会在外部环境下生效)
目前由于此种缓存设备导致的经典问题有:
- 在线视频网站拖动视频进度条后,视频从头开始播放。
- 安卓手机在应用商店下载安装包,被劫持到被投毒的缓存服务器,导致手机中毒。
建议用户:
- 检查网络内部及网络出口是否有缓存设备;
- 检查网络出口是否有锐捷的加速服务器设备;
- 检查网络服务是否为鹏博士旗下的二级运营商(电信通、长城宽带、宽带通等)。
小结
以上就是当时发送给公司领导和客户的邮件了,当然这是我写的初稿,具体发送给领导和客户的邮件是由我的领导整理过的,语气用词口吻要比上文好一些,但具体事实没变。那个版本版权归公司所有,不能随意修改和发布。所以我发布的是我自己写的版本。
如果你能够看的懂这篇文章的话最好不过。如今的劫持早已开始使用除DNS劫持之外的技术了。
如果你看不懂的话,就当没读过这篇文章吧。
1 comment
Thiece
2016 年 5 月 10 日 在 上午 10:20 (UTC 8) Link to this comment
自己也是身在一家安全公司,上个礼拜还上演了一场内网劫持某设备所有登录请求,获取到账号密码