昨天深圳下了一天的暴雨,2014年的雨水真是够多的。

 

用户的资源就是金钱,怎的也要好好利用嘛不是?

 

ISP的劫持手段真是花样百出。从曾经的DNS(污染)劫持到后来的共享检測。无不通过劫持正常的请求来达到他们的目的。

 

之前分析过通过劫持HTTP会话,插入iframe来检測用户后端有无共享行为,但后来移动终端的发展导致ISP開始有所收敛,由于即使检測出来也不敢断用户的网了。

 

但是如今又出了新的花样……

 

近期,每当我打开baidu首页的时候,总是发现奇怪的现象,明明输入的仅仅是www.baidu.com。可是却莫名其妙的出现了跳转,最后发现实际訪问的URL居然带上了尾巴。

 

好吧。起初我以为我又被流氓软件盯上了,但左思右索使劲翻遍也没发现什么被弓虽女干的迹象。仅仅好打开虚拟机来试试。结果发现我干净的虚拟机也出现了一样的现象。

 

这时我才明确。又被电信劫持了,那么这次又是如何的劫持手段呢?


 被劫持的现象


首先,我们看看现象:

 

 

当我们打开www.baidu.com的时候。浏览器终于的目的URL却变成了http://www.baidu.com/?tn=90509114_hao_pg

 

这中间明显感受到了页面的跳转。那么我们看看浏览器上的后退button,就发现了端倪。

 

http://112.124.105.244/jmp?m=redirect&src=szdx-baidu

 

咦。这是什么地址,看起来就像劫持的玩意。再细致一看。szdx(深圳电信),真是自报家门,毫不忌讳啊!


 劫持的原理


那么电信是怎样劫持了我们正常的百度请求呢?

 

 

经过检查,DNS是正常的,没有问题,那就说明这是HTTP链路层劫持了。

 

果断抓包,进行一次被劫持的会话,非常快就有了。

 

 

咋一看,请求的serverIP没有错,似乎没什么问题,但细致一看问题就有了。

 

 

内容全然就不是一回事,这玩意怎么可能是百度返回的嘛。显然是被赤裸裸的劫持了。

 

继续深挖扩线,看看到底在哪被劫持了。

 

先看看正常的百度响应。

 

 

唔。人家的server但是BWS(BaiduWebServer)呢。

 

那么就说明,我的HTTP会话被劫持了。收到了伪造的响应,回头再从被劫持的TCP流中寻找痕迹。

 

 

没错,我们找到了这个相当关键的细节!

 

我们在收到伪造的响应后,又收到了一个被认定为“伪造的重响应”数据包,而这个数据包正是我们这次请求真正的响应。

 

但此时。这个数据包已经视为无效了,观察SEQ和ACK编号就可以发现其手段(TCP原理,请參考RFC#3708)。

 

为了证实这个是伪造的响应。我们知道一个人能够伪装成不论什么样子,可是其指纹可不是随便就能改变的。

 

HTTP工作在应用层,应用层就是一个人的外貌,想换成什么样子都行,可是IP层(网络层)所在的操作系统可就是指纹了。

 

我们先看看我这到正常百度server的IP包TTL值为54。这是一般不会改变的,即使路由不同,其波动也只是±1、2

 

 

然后再看看被劫持的响应IP包TTL值居然为252,这就证明了不仅被非法劫持了并且这黑手离我仅几步之遥!

 

科普:不同的操作系统环境TTL值通常是固定的一个数。常见的是16的倍数,然后每经过一个节点减1。

 

 

 

顺水推舟,揪出元凶。先看看我这到百度server经过了哪些网络节点。

 

 

嗯,然后我们ping一下百度server。确认其TTL为54,与上述一致。

 

 

 

然后我们ping一下3号节点,TTL值为253,没有问题。

 

 

 

接着我们ping下一个5号节点。TTL值为251,也没有问题。

 

那么TTL为252的4号节点,显然就是劫持我们的元凶了,但是人家早就不让ping了,呵呵。

 

依据电信的网络结构。2、3号节点算是DSLAM接入、汇聚层集,那么4号节点显然是在城际骨干网前面插入类IDS系统的节点了。

 

 

由此证据链已经完整。我们能够得出一个结论:HTTP劫持就是ISP所为。


 劫持的动机


事物的存在肯定有其必定性,既然如今不检測共享了,那么为什么要劫持咱们的百度请求呢?

 

业内人士都应该知道,百度和hao123这类站点都有联盟存在,联盟的作用就是推广。带来流量。

 

加尾巴的行为,就是在做这样的事情。

 

就深圳的居民用户数来说,按一天100W的保守訪问计数来说。如果100元/W訪问付费,那么一天下来。ISP就有了1W元的收入,那一个月就有30W的额外收入了。

 

假如通过这样的方式,劫持各种购物站点,增加自己的推广。按一天成交额100W,平均返利1%计算,这又是一天1W元的收入,那一个月又有30W的额外收入了。

 

所以这样的只只须要对HTTP请求的host參数判别进行劫持就能够坐着收钱的事。谁都何乐而不为呢?

 

记住上面仅仅是保守计算的样例而已,谁知道将来还有其它的什么东西?

 

至于这个行为是ISP的行为还能够理解,但假设是某些员工的个人行为私自牟利那我觉得这就玩大了,但不管是哪种,粗暴侵犯用户通信自由。都是违法行为。

 

建议出现这样的现象的用户。果断向ISP示威,必要时可找工信部。

 


 坚强的后盾


好像遗漏了一点,112.124.105.244这是何方神圣,为何能承载深圳电信数以万计的请求量?

 

inetnum: 112.124.0.0 - 112.124.255.255
netname: ALIBABA-CN-NET

 

这个IP来自杭州,查询IP信息发现。原来是阿里云的server。

 

加之这个server仅仅是跳转功能,用的是ATS(Apache Traffic Server)server,所以区区几百万的小流量还真不算什么。

 

为了尽可能的让用户感受不到被劫持,保证速度是关键,看得出人家选择阿里云也是用心良苦啊!


 向劫持说不


那么我们怎么防范劫持呢? 

 

非常遗憾。还真没办法预防。

 

唯一可行的预防方法就是尽量使用HTTPS协议訪问。

 

眼下。我们知道其劫持原理后知道仅仅能通过检測TTL的变化或HTML元素检查来判定。但这都不是一般用户能够解决的。

 

只是,依据眼下的情况。我们能够考虑在边界设备针对TTL为252且为TCP协议的包做DROP处理。切记不能REJECT。
(以普通居民用户的网络来说,TTL为252的TCP响应差点儿不可能存在,所以特异性还是比較突出的)

 

但治标不如治本,还是去投诉吧!


好吧,本期解读电信劫持方式就临时先到这儿了。本文不针是对某个ISP。只对ISP业内的现象做分析。谢绝请喝,茶叶请寄信箱。