0x00 前言

---

最近在處理了一些HTTP劫持的案例和拜讀業內不少大牛的文章之後，覺得有必要把最近的一些關於劫持案例的分析和思考記錄下來，以留作日後備忘。

首先是一例典型的旁路劫持案例：

劫持者應該是利用在運營商內部的便利條件，在閘道器路由器上新增嗅探程式，嗅探明文HTTP請求資料包，拿到要劫持的資料包之後，馬上給請求者返回HTTP response（302 到其他 url），並且立即關閉當前HTTP 請求。劫持者 302 的 url 是原網站的一個計費請求，類似淘寶推廣連結，但是比較讓人鬱悶的是，劫持者返回的資料包是兩個 TCP 資料包，偶爾會出現 TCP 報亂序（劫持技術不過關），導致客戶端無法識別，從而導致頁面白屏，嚴重影響使用者體驗 ！

0x01 分析

---

下面介紹一下我是如何從資料包分析和定位劫持路由的：

case 背景：山西移動部分地區，訪問國內頂級中文導航網站出現白屏現象。

頁面請求後得到奇怪資料返回：

請求中 Connection 欄位為 keep alive 且請求協議是 1.0 而返回的header 關閉了請求，返回一段奇怪的js，跳轉到另外一個 url

接下來觀察 TCP flow：

這次TCP 連線上有 3 個奇怪的現象，都可以證明這是一次處於鏈路中的劫持，之後如果遇到類似的情況也可以從這三個方面入手來處理：

1. server 給 client 的 TCP 報的 TTL 不一致，且抖動很大。

2. server 給 client 的 IP identification，出現不符合 RFC 標準的情況

0x02 TTL 不一致的情況：

---

客戶端接受的資料包TTL是 51 ，後面來自真實 server 的TTL 是 47，還有 1022 和 1024（本來應該在前面） 都是兩個來自 劫持者的資料包，但是 fin 包在前，提前關閉連線，導致HTTP應用層拿不到正確的資料，導致瀏覽器白屏。

這次 TCP 連線上的其他資料包，可以看到有 部分 資料包，被拋棄，而且被拋棄的資料包的 TTL 和 握手包的TTL 相等（一般 握手包 不會被劫持，說明被拋棄的包是來自 真實的伺服器的）是 47 。

0x03 IP identification 異常現象：

---

RFC定義：

所以對於給定地址和協議的 ip 包來說，它的identification應該是公差為 1 的單調遞增數列：

但是在這次連線中，劫持者的 identification 等於被劫持的 identification：

劫持者：

被劫持者：

仔細看，可以發現 993 和 1022 這兩個包的identification 是一樣的，多次抓包也是這樣，所以這裡可以判斷，鏈路上肯定出了問題。

從這以上兩個特徵，基本上可以得出結論：

劫持者提前給瀏覽器返回了響應，且關閉了 HTTP 連線。導致正確的 資料包沒有被接受，使得瀏覽器發生了異常跳轉。而使用者頁面出現白屏的情況是劫持失敗，劫持者的資料包亂序（程式錯誤），導致應用層無法獲得爭取 HTTP 響應。

劫持過程應該類似於：

結論已經獲得，但是問題的解決就是要定位到相應的劫持路由，然後向有關部門反饋：

定位的方法我推薦幾種：

1.  如果出現一定數量的使用者反饋，可以多聯絡幾位使用者（不同網路環境下，能復現劫持），抓包，然後獲取 trace 截圖，如果他們出現某幾跳路由的重複，就可以縮小定位範圍，或者直接定位路由IP。

2. 根據劫持包的TTL反推，用 scapy 來構造自定義的，可以復現劫持的HTTP請求包，然後以 TTL 從 1 開始遞增發包，出現劫持響應時，可以判斷劫持者的位置。

0x04 參考文章：

---

• /tips/?id=127
• http://security.tencent.com/index.php/blog/msg/10

謝謝這兩篇文章的作者，指定迷津