安全-分析深圳电信的新型HTTP劫持方式
ISP的劫持手段真是花样百出，从以前的DNS(污染)劫持到后来的共享检测，无不通过劫持正常的请求来达到他们的目的。
之前分析过通过劫持HTTP会话，插入iframe来检测用户后端有无共享行为，但后来移动终端的发展导致ISP开始有所收敛，因为即使检测出来也不敢断用户的网了。
可是现在又出了新的花样……
最近，每当我打开baidu首页的时候，总是发现奇怪的现象，明明输入的只是www.baidu.com，但是却莫名其妙的出现了跳转，最后发现实际访问的URL竟然带上了尾巴。
好吧，起初我以为我又被流氓软件盯上了，但左思右索使劲翻遍也没发现什么被弓虽女干的迹象，只好打开虚拟机来试试，结果发现我干净的虚拟机也出现了一样的现象。
这时我才明白，又被电信劫持了，那么这次又是怎样的劫持手段呢？
被劫持的现象
首先，我们看看现象：
当我们打开www.baidu.com的时候，浏览器最终的目的URL却变成了http://www.baidu.com/?tn=90509114_hao_pg
这中间明显感受到了页面的跳转，那么我们看看浏览器上的后退按钮，就发现了端倪。
http://112.124.105.244/jmp?m=redirect&src=szdx-baidu
咦，这是什么地址，看起来就像劫持的玩意，再仔细一看，szdx（深圳电信），真是自报家门，毫不忌讳啊！
劫持的原理
那么电信是如何劫持了我们正常的百度请求呢？
经过检查，DNS是正常的，没有问题，那就说明这是HTTP链路层劫持了。
果断抓包，进行一次被劫持的会话，很快就有了。
咋一看，请求的服务器IP没有错，似乎没什么问题，但仔细一看问题就有了。
内容完全就不是一回事，这玩意怎么可能是百度返回的嘛，显然是被赤裸裸的劫持了。
继续深挖扩线，看看究竟在哪被劫持了。
先看看正常的百度响应。
唔，人家的服务器可是BWS（BaiduWebServer）呢！
那么就说明，我的HTTP会话被劫持了，收到了伪造的响应，回头再从被劫持的TCP流中寻找痕迹。
没错，我们找到了这个相当关键的细节！
我们在收到伪造的响应后，又收到了一个被认定为“伪造的重响应”数据包，而这个数据包正是我们这次请求真正的响应。
但此时，这个数据包已经视为无效了，观察SEQ和ACK编号即可发现其手段（TCP原理，请参考RFC#3708）。
为了证实这个是伪造的响应，我们知道一个人可以伪装成任何样子，但是其指纹可不是随便就能改变的。
HTTP工作在应用层，应用层就是一个人的外貌，想换成什么样子都行，但是IP层（网络层）所在的操作系统可就是指纹了。
我们先看看我这到正常百度服务器的IP包TTL值为54，这是一般不会改变的，即使路由不同，其波动也不过±1、2
然后再看看被劫持的响应IP包TTL值竟然为252，这就证明了不仅被非法劫持了而且这黑手离我仅几步之遥！
科普：不同的操作系统环境TTL值一般是固定的一个数，常见的是16的倍数，然后每经过一个节点减1。
顺水推舟，揪出元凶。先看看我这到百度服务器经过了哪些网络节点。
嗯，然后我们ping一下百度服务器，确认其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信息发现，原来是阿里云的服务器。
加之这个服务器只是跳转功能，用的是ATS（Apache Traffic Server）服务器，所以区区几百万的小流量还真不算什么。
为了尽可能的让用户感受不到被劫持，保证速度是关键，看得出人家选择阿里云也是用心良苦啊！
向劫持说不
那么我们怎么防范劫持呢？
很遗憾，还真没办法预防。
唯一可行的预防方法就是尽量使用HTTPS协议访问。
目前，我们知道其劫持原理后知道只能通过检测TTL的变化或HTML元素检查来判定，但这都不是一般用户可以解决的。
不过，根据目前的情况，我们可以考虑在边界设备针对TTL为252且为TCP协议的包做DROP处理，切记不能REJECT。
（以普通居民用户的网络来说，TTL为252的TCP响应几乎不可能存在，所以特异性还是比较突出的）
但治标不如治本，还是去投诉吧！
