# 乌云归档：也谈链路劫持

Author: 乌云历史资料库 (@wooyun_archive)
Published: 2015-12-29T02:53:00Z
Canonical: https://wepostx.com/topics/1270

> 乌云历史资料归档
>
> **原始作者：** lk1ngaa7
> **原始编号：** superkieran-wooyundrops:971
> **原始发布时间：** 2015-12-29 10:53
> **声明：内容仅用于技术研究和个人使用，版权归 wooyun.org。**

---

# 0x00 前言

最近在处理了一些HTTP劫持的案例和拜读业内不少大牛的文章之后，觉得有必要把最近的一些关于劫持案例的分析和思考记录下来，以留作日后备忘。
首先是一例典型的旁路劫持案例：
劫持者应该是利用在运营商内部的便利条件，在网关路由器上添加嗅探程序，嗅探明文HTTP请求数据包，拿到要劫持的数据包之后，马上给请求者返回HTTP response（302 到其他 url），并且立即关闭当前HTTP 请求。劫持者 302 的 url 是原网站的一个计费请求，类似淘宝推广链接，但是比较让人郁闷的是，劫持者返回的数据包是两个 TCP 数据包，偶尔会出现 TCP 报乱序（劫持技术不过关），导致客户端无法识别，从而导致页面白屏，严重影响用户体验 ！

# 0x01 分析

下面介绍一下我是如何从数据包分析和定位劫持路由的：
case 背景：山西移动部分地区，访问国内顶级中文导航网站出现白屏现象。
页面请求后得到奇怪数据返回：

![原文图片](/media/2016/06/dbab0a58c3305a7a726e789c6310f5b3)

请求中 Connection 字段为 keep alive 且请求协议是 1.0 而返回的header 关闭了请求，返回一段奇怪的js，跳转到另外一个 url
接下来观察 TCP flow：
这次TCP 连接上有 3 个奇怪的现象，都可以证明这是一次处于链路中的劫持，之后如果遇到类似的情况也可以从这三个方面入手来处理：

- server 给 client 的 TCP 报的 TTL 不一致，且抖动很大。

- server 给 client 的 IP identification，出现不符合 RFC 标准的情况

# 0x02 TTL 不一致的情况：

![原文图片](/media/2016/06/df89f36c13f3daeaa4765f980545fd5c)

客户端接受的数据包TTL是 51 ，后面来自真实 server 的TTL 是 47，还有 1022 和 1024（本来应该在前面） 都是两个来自 劫持者的数据包，但是 fin 包在前，提前关闭连接，导致HTTP应用层拿不到正确的数据，导致浏览器白屏。

![原文图片](/media/2016/06/49a251f929a6afc971aa70be385ddaae)

这次 TCP 连接上的其他数据包，可以看到有 部分 数据包，被抛弃，而且被抛弃的数据包的 TTL 和 握手包的TTL 相等（一般 握手包 不会被劫持，说明被抛弃的包是来自 真实的服务器的）是 47 。

# 0x03 IP identification 异常现象：

RFC定义：

![原文图片](/media/2016/06/7c3a8a37fc14af5cc729e202d5c7ad9e)

所以对于给定地址和协议的 ip 包来说，它的identification应该是公差为 1 的单调递增数列：
但是在这次连接中，劫持者的 identification 等于被劫持的 identification：
劫持者：

![原文图片](/media/2016/06/90deb7a4cc6c97d67e80c0d2977686e1)

被劫持者：

![原文图片](/media/2016/06/96205d910cde13a58415ac1ad9719b68)

仔细看，可以发现 993 和 1022 这两个包的identification 是一样的，多次抓包也是这样，所以这里可以判断，链路上肯定出了问题。
从这以上两个特征，基本上可以得出结论：
劫持者提前给浏览器返回了响应，且关闭了 HTTP 连接。导致正确的 数据包没有被接受，使得浏览器发生了异常跳转。而用户页面出现白屏的情况是劫持失败，劫持者的数据包乱序（程序错误），导致应用层无法获得争取 HTTP 响应。
劫持过程应该类似于：

![原文图片](/media/2016/06/a996f14a97328f8f81dc45b0569c03d3)

结论已经获得，但是问题的解决就是要定位到相应的劫持路由，然后向有关部门反馈：
定位的方法我推荐几种：

- 如果出现一定数量的用户反馈，可以多联系几位用户（不同网路环境下，能复现劫持），抓包，然后获取 trace 截图，如果他们出现某几跳路由的重复，就可以缩小定位范围，或者直接定位路由IP。

- 根据劫持包的TTL反推，用 scapy 来构造自定义的，可以复现劫持的HTTP请求包，然后以 TTL 从 1 开始递增发包，出现劫持响应时，可以判断劫持者的位置。

# 0x04 参考文章：

- [http://drops.wooyun.org/tips/127](http://drops.wooyun.org/tips/127)

- [http://security.tencent.com/index.php/blog/msg/10](http://security.tencent.com/index.php/blog/msg/10)
谢谢这两篇文章的作者，指定迷津

## Replies