分析深圳电信的新型HTTP劫持方式

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

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

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

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

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

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

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

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

---

被劫持的现象

---

首先，我们看看现象：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd3I0MTA=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">

当我们打开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链路层劫持了。

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

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd3I0MTA=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">

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

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

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

先看看正常的百度响应。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd3I0MTA=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">

唔。人家的server但是BWS（BaiduWebServer）呢。

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

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd3I0MTA=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">

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

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

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

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

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

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

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

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

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd3I0MTA=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">

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

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd3I0MTA=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">

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

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

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

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

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

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd3I0MTA=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center">

由此证据链已经完整。我们能够得出一个结论：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业内的现象做分析。谢绝请喝，茶叶请寄信箱。